Newsgroup: it.comp.reti.cisco
Titolo: La vpn con problemi di MTU su hdsl (scusate se è un po lungo)

Ciao a tutti,ho due lan collegate a internet tramite hdsl e 2 cisco 1750
ios 12.1(1)XL. Premetto che sulla eth di entrambi i router ho bisogno di
un ip privato,visto che in cascata ci ho messo 2 macchine linux che fanno
da firewall e nat tramite una route statica,e questo funziona benissimo.
Per creare una vpn tra i 2 router,visto che l'ip sella seriale è oscurato
da telecom,ho creato una loopback con un'ip pubblico e ho assegnato
'crypto map mymap local-address loopback0'.
Tutto bene,la vpn pinga, e fino a quando non c'è bisogno di
frammentazione,va tutto perfettamente,se invece faccio un ping 'grande'
tipo un ping -l 50000,la vpn non va,mentre un ping -l  20000 funziona
(tutti e due credo siano frammentati).Questo di fatto non mi permette di
fare niente con la vpn,tranne che trastullarmi con i ping :)
Impostando tramite Dr.TCP l'MTU di un client a 1400 al posto dei soliti
1500,la vpn su quel client funziona sempre,help,non capisco il motivo,l'unica
cosa strana è che ho notato che l'mtu della seriale e della ethernet del
router sono a 1500,mentre quello della loopback è a 1514,e non c'è verso
di settarlo a 1500 con 'ip MTU 1500',accetta il comando ma l'mtu rimane
1514.
Qualcuno sa aiutarmi,anche postandomi una configurazione VPN funzionante
su hdsl con ip privati sulle eth?

Ciao,
questo post mi fa ricordare di qualche problema avuto nella
configurazione di una VPN tra una rete connessa a internet
tramite ADSL (router 827) e una rete tramite HDSL (2610).
Sul 2610 tra l'altro erano gia' implementate e funzionanti due
VPN tra altre sedi, sempre su HDSL, e non riuscivo a capire
perche' l'unica cosa che funzionasse tra la rete con l'827 e
le altre fosse il ping...
La cosa si e' risolta, confrontando le configurazioni sui router
funzionanti e non, aggiungendo:
no ip route-cache
no ip mroute-cache
nella config dell'interfaccia sulla quale e' applicata la crypto map.
Spero ti sia d'aiuto
Cristiano
"Mauro" <ma...@localhost.localdomain> ha scritto nel messaggio
news:20010610.233715...@localhost.localdomain...


Avevo letto anche io qualcosa a proposito sul 
cisco.com
 ma non mi ha risolto
il problema...
Mauro
"Cristiano Tonezzer" <tonezzer@_NOSPAM_algorab.com> wrote in message
news:i%iV6.29775$Vk3.3...@news2.tin.it...



Dunque ....
La lopback interface e' una interfaccia virtuale, quindi su di essa non ha
significato la MTU. Per spedire il pacchetto la loopback fa riferimento ad
una interfaccia fisica che ha una sua mtu size fissata.
Se setti la mtu del client a 1400 tutto funziona perche' probabilmente il
pacchetto piu' l'header IPSec rimane sotto i 1500 bytes e quindi il
pacchetto non deve essere frammentato.
The MTU for the most common encapsulation of IP over an Ethernet
transmission link (
http://www.faqs.org/rfcs/rfc894.html
) is 1500 bytes. By
convention the MTU includes the entire IP datagram, including all IP
headers, but excludes link encapsulation headers. The extra link-level
headers for the RFC 894 encapsulation comprise 18 bytes, for a maximum
Ethernet frame size of 1518 bytes.
IPSec can make fragmentation problems worse, because it lengthens each IP
packet by one, or possibly two, IP headers. These added headers vary in
length by choice of IPSec protocols, but empirically they do not exceed 80
bytes per packet. For the most common encapsulation of IP over Ethernet, the
standard MTU is 1500 bytes. But if an application emitted a 1500-byte packet
that needed to travel though an IPSec tunnel, the added IPSec headers would
require fragmentation of each packet. A good technique (the best technique,
really) of avoiding fragmentation with IPSec is reducing the interface MTU
that applications and the IP protocol stack see on both ends of the TCP
connection. If the applications and the IP protocol stack think the
interface MTU is 1420 bytes or less, they will not emit packets that need to
be fragmented after IPSec encapsulation for transport through
Ethernet-size-capable routers and links.
Ciao.
Gabriele.

Il problema esatto è che quando mando tramite la vpn un pacchetto da
1500byte con il flag DF attivo,l'ipsec lo incapsula e poi lo scarta perchè
non riesce ad uscire visto che le interfacce hanno mtu 1500,e il pacchetto
,da 1580 byte (la firma dell'ipsec credo sia di 80byte) non puo' essere
frammentato.
Ora mi chiedo,ma perchè il pacchetto incapsulato,eredita il df da quello da
incapsulare? Se il pacchetto incapsulato passa frammentato dalla vpn e poi
viene riassemblato dall'altra parte,ritorna come in origine,che senso ha
ereditare il df?
Ma questo problema non si riscontra su tutte le vpn?
Ho provato a variare l'mtu delle interfacce ,ma oltre il 1500 non si va...
Posto la configurazione sperando che a qualcuno possa servire (visto i post
sull'hdsl) e che qualcuno mi sappia aiutare,non posso modificare l'mtu di
tutti i client delle vpn,è impensabile...
!IOS version 12.1(1)XC
service timestamps debug uptime
service timestamps log datetime localtime
service password-encryption
logging buffered 4096 debugging
!
hostname router1
ip domain-name 
domain.it
ip subnet-zero
no ip source-route
!
enable secret xxx
!AAA
aaa new-model
username cmauro password 0 xxx
username max password 0 xxx
!SSH
ip ssh time-out 30
ip ssh authentication-retries 1
!
no ip http server
no ip finger
!--------------------------------VPN-----------------------------------
!
! Internet Key Exchange (IKE)
!
crypto isakmp enable
crypto isakmp identity address
!
crypto isakmp policy 1
 encryption 3des
 hash md5
 authentication pre-share
 group 2
 lifetime 86400
crypto isakmp key kiave address 1.2.3.4
!
! IPSec
!
crypto ipsec transform-set cm-transformset-1 ah-md5-hmac esp-3des
!
crypto map NO-Net local-address loopback 0
crypto map NO-Net 1 ipsec-isakmp
 match address 101
 set peer 1.2.3.4
 set transform-set cm-transformset-1
 set security-association lifetime seconds 3600
 set security-association lifetime kilobytes 4608000
!
!------------------------------------------------------------------------
!
interface loopback0
 ip mtu 1514 !Di + non mi fa mettere
 ip address 1.1.1.1 255.255.255.255
 crypto map NO-Net
 no shutdown
!
interface Serial0
 ip mtu 1500 !Di + non mi fa mettere
 bandwidth 2048
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 no ip mroute-cache
 no shutdown
!
interface Serial0.1 point-to-point
 ip mtu 1500 !Di + non mi fa mettere
 bandwidth 2048
 ip address 62.86.1.1 255.255.255.252
 no ip directed-broadcast
 ip nat outside
 frame-relay interface-dlci 111 IETF
 no shutdown
!
interface FastEthernet0
 ip mtu 1500 !Di + non mi fa mettere
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 no ip directed-broadcast
 no ip mroute-cache
 no shutdown
!
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0.1
ip route 10.0.0.0 255.0.0.0 loopback0
!
!access list per snmp
access-list 1 permit host 192.168.0.2
!access list per no nat over vpn
access-list 100 deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255
!access list per nat
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
!access list per vpn
access-list 101 permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255
!
ip nat inside source list 100 interface loopback 0 overload
!
snmp-server engineID local 00000009020000049A65FEA0
snmp-server community public RO 1
!
banner motd ^CC
        Ciao a tutti
^C
!
line con 0
 password xxx
 transport input none
line aux 0
 password xxx
line vty 0 4
!
end