grblades
asked on
Problem sending traffic over GRE/VPN tunnel
Router A with ADSL interface is configured to use GRE over IPSEC to talk to co-lo and runs OSPF routing.
Router B is in co-lo and is the VPN endpont.
Router C sits between the servers and Router B and acts as a single default gateway for the servers. There is also a PIX but that is not relevant for this problem.
Previously a standard VPN between router A and the PIX was being used without problems. But now it has been switched to the VPN between router A and router B together with GRE in order that the routing protocol can also be used.
The problem is that data transfer over the link stalls or does not connect. It appears to be a MTU issue.
The configs are shown below. The ADSL MTU has always been 1452 so when setting the MTU for the GRE tunnel I calculated 1452 - 60 (IPSEC) - 24 (GRE) = 1368
On the router internal interfaces I have also set the MSS to 1328 and I would have thought this would overcome any problems.
Router A
mmi polling-interval 60
mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip source-route
ip cef
!
no ip bootp server
ip ssh time-out 60
ip ssh authentication-retries 2
ip ips po max-events 100
no ftp-server write-enable
!
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key ***** address x.x.126.68 no-xauth
!
!
crypto ipsec transform-set strong esp-3des esp-md5-hmac
mode transport
!
crypto ipsec profile strong
set transform-set strong
!
!
crypto map SDM_CMAP_1 1 ipsec-isakmp
set peer x.x.126.68
set transform-set strong
match address 100
!
interface Tunnel0
description $FW_INSIDE$
ip address 192.168.202.1 255.255.255.0
ip mtu 1368
tunnel source Dialer0
tunnel destination x.x.126.68
tunnel path-mtu-discovery
crypto map SDM_CMAP_1
!
interface FastEthernet0/0
ip address 192.168.2.1 255.255.255.0
ip nat inside
ip tcp adjust-mss 1328
duplex auto
speed auto
no cdp enable
no mop enabled
!
interface Dialer0
description $FW_OUTSIDE$
ip address x.x.22.2 255.255.0.0
ip mtu 1452
ip nat outside
encapsulation ppp
dialer pool 1
dialer-group 1
! passwords deleted
crypto map SDM_CMAP_1
!
router ospf 100
log-adjacency-changes
network 192.168.2.0 0.0.0.255 area 0
network 192.168.202.0 0.0.0.255 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip http server
ip http secure-server
ip nat pool ttt 192.168.2.1 192.168.2.255 netmask 255.255.255.0
ip nat inside source route-map nonat interface Dialer0 overload
!
!
access-list 100 remark SDM_ACL Category=4
access-list 100 permit gre host 80.177.22.2 host 82.110.126.68
access-list 112 deny gre host 80.177.22.2 host 82.110.126.68
access-list 112 deny ip 192.168.2.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 112 permit ip 192.168.2.0 0.0.0.255 any
dialer-list 1 protocol ip permit
no cdp run
!
route-map nonat permit 10
match ip address 112
!
!
control-plane
Router B is in co-lo and is the VPN endpont.
Router C sits between the servers and Router B and acts as a single default gateway for the servers. There is also a PIX but that is not relevant for this problem.
Previously a standard VPN between router A and the PIX was being used without problems. But now it has been switched to the VPN between router A and router B together with GRE in order that the routing protocol can also be used.
The problem is that data transfer over the link stalls or does not connect. It appears to be a MTU issue.
The configs are shown below. The ADSL MTU has always been 1452 so when setting the MTU for the GRE tunnel I calculated 1452 - 60 (IPSEC) - 24 (GRE) = 1368
On the router internal interfaces I have also set the MSS to 1328 and I would have thought this would overcome any problems.
Router A
mmi polling-interval 60
mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip source-route
ip cef
!
no ip bootp server
ip ssh time-out 60
ip ssh authentication-retries 2
ip ips po max-events 100
no ftp-server write-enable
!
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key ***** address x.x.126.68 no-xauth
!
!
crypto ipsec transform-set strong esp-3des esp-md5-hmac
mode transport
!
crypto ipsec profile strong
set transform-set strong
!
!
crypto map SDM_CMAP_1 1 ipsec-isakmp
set peer x.x.126.68
set transform-set strong
match address 100
!
interface Tunnel0
description $FW_INSIDE$
ip address 192.168.202.1 255.255.255.0
ip mtu 1368
tunnel source Dialer0
tunnel destination x.x.126.68
tunnel path-mtu-discovery
crypto map SDM_CMAP_1
!
interface FastEthernet0/0
ip address 192.168.2.1 255.255.255.0
ip nat inside
ip tcp adjust-mss 1328
duplex auto
speed auto
no cdp enable
no mop enabled
!
interface Dialer0
description $FW_OUTSIDE$
ip address x.x.22.2 255.255.0.0
ip mtu 1452
ip nat outside
encapsulation ppp
dialer pool 1
dialer-group 1
! passwords deleted
crypto map SDM_CMAP_1
!
router ospf 100
log-adjacency-changes
network 192.168.2.0 0.0.0.255 area 0
network 192.168.202.0 0.0.0.255 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip http server
ip http secure-server
ip nat pool ttt 192.168.2.1 192.168.2.255 netmask 255.255.255.0
ip nat inside source route-map nonat interface Dialer0 overload
!
!
access-list 100 remark SDM_ACL Category=4
access-list 100 permit gre host 80.177.22.2 host 82.110.126.68
access-list 112 deny gre host 80.177.22.2 host 82.110.126.68
access-list 112 deny ip 192.168.2.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 112 permit ip 192.168.2.0 0.0.0.255 any
dialer-list 1 protocol ip permit
no cdp run
!
route-map nonat permit 10
match ip address 112
!
!
control-plane
ASKER
Router C
version 12.3
service config
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname xlator
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip subnet-zero
!
ip cef
ip audit notify log
ip audit po max-events 100
ip ssh break-string
no ftp-server write-enable
no scripting tcl init
no scripting tcl encdir
!
no crypto isakmp enable
!
interface Ethernet0
ip address 192.168.0.1 255.255.255.0
half-duplex
!
interface FastEthernet0
ip address 192.168.1.1 255.255.255.0
speed auto
!
router ospf 100
log-adjacency-changes
network 192.168.0.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.1.2
no ip http server
no ip http secure-server
!
control-plane
version 12.3
service config
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname xlator
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip subnet-zero
!
ip cef
ip audit notify log
ip audit po max-events 100
ip ssh break-string
no ftp-server write-enable
no scripting tcl init
no scripting tcl encdir
!
no crypto isakmp enable
!
interface Ethernet0
ip address 192.168.0.1 255.255.255.0
half-duplex
!
interface FastEthernet0
ip address 192.168.1.1 255.255.255.0
speed auto
!
router ospf 100
log-adjacency-changes
network 192.168.0.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.1.2
no ip http server
no ip http secure-server
!
control-plane
Router C
>ip route 0.0.0.0 0.0.0.0 192.168.1.2
Can I assume that this default points to the PIX FW?
Can I assume that OSPF is working and all routers learn all networks via the proper interface?
Have you considered enabling OSPF on the PIX, too instead of using a static on the router?
Have you ruled out duplex mismatches on all router interfaces?
Have you checked all interfaces for error counts?
>ip route 0.0.0.0 0.0.0.0 192.168.1.2
Can I assume that this default points to the PIX FW?
Can I assume that OSPF is working and all routers learn all networks via the proper interface?
Have you considered enabling OSPF on the PIX, too instead of using a static on the router?
Have you ruled out duplex mismatches on all router interfaces?
Have you checked all interfaces for error counts?
ASKER
The default route does point to the PIX. OSPF is working fine and all the routes are present on all routers.
OSPF is working on the PIX.
I dont believe there are any duplex mismatches but I will check.
Pings can be sent across the VPN with no packet loss and I can telnet to the mail server SMTP port etc... The problem comes when trying a remote desktop connection where it starts to connect and then either comes up with an error or works briefly but then stalls.
OSPF is working on the PIX.
I dont believe there are any duplex mismatches but I will check.
Pings can be sent across the VPN with no packet loss and I can telnet to the mail server SMTP port etc... The problem comes when trying a remote desktop connection where it starts to connect and then either comes up with an error or works briefly but then stalls.
you're right, it does sound exactly like a MTU problem if we rule out the duplex mismatch/port errors
Have you tried reducing the MTU on the server itself instead of just on the tunnel?
Have you tried reducing the MTU on the server itself instead of just on the tunnel?
ASKER
No I haven't as I dont have access to the server myself and the server concerned is an exchange server which receives email directly from the Internet through the PIX. If I change the MTU I could be just shifting the problem elsewhere as ICMP is blocked through the PIX.
I have sent instructions to the client to use the 'ping -f -l' command to discover the maximum ping packet size that can be sent through with the DF bit set. I can then calculate the MTU and if it happens to be lower than the configured value I can fix this. At least then I will know the MTU is set correctly.
I have sent instructions to the client to use the 'ping -f -l' command to discover the maximum ping packet size that can be sent through with the DF bit set. I can then calculate the MTU and if it happens to be lower than the configured value I can fix this. At least then I will know the MTU is set correctly.
ASKER
Well the biggest ping data packet that would go over the link was 1258 bytes which makes the MTU 1286. I'll change the MTU and MSS settings accordingly when I get home and then see if that helps.
ASKER
I set the MTU to 1286 and the MSS to 1246 but it still does not work.
Now the max ICMP data size I can send over the link is 1176 bytes. Why has it gone down?
I have applied the MTU to the tunnel so unless I have miscalculated something it should not have any effect especailly as large of this.
Now the max ICMP data size I can send over the link is 1176 bytes. Why has it gone down?
I have applied the MTU to the tunnel so unless I have miscalculated something it should not have any effect especailly as large of this.
ASKER
Is the TTL what you would expect?
>ping 192.168.0.4 -f -l 1176
Pinging 192.168.0.4 with 1176 bytes of data:
Reply from 192.168.0.4: bytes=1176 time=75ms TTL=125
Reply from 192.168.0.4: bytes=1176 time=75ms TTL=125
Reply from 192.168.0.4: bytes=1176 time=74ms TTL=125
Reply from 192.168.0.4: bytes=1176 time=74ms TTL=125
Ping statistics for 192.168.0.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 74ms, Maximum = 75ms, Average = 74ms
>ping 192.168.0.4 -f -l 1177
Pinging 192.168.0.4 with 1177 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.0.4:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
>ping 192.168.0.4 -f -l 1176
Pinging 192.168.0.4 with 1176 bytes of data:
Reply from 192.168.0.4: bytes=1176 time=75ms TTL=125
Reply from 192.168.0.4: bytes=1176 time=75ms TTL=125
Reply from 192.168.0.4: bytes=1176 time=74ms TTL=125
Reply from 192.168.0.4: bytes=1176 time=74ms TTL=125
Ping statistics for 192.168.0.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 74ms, Maximum = 75ms, Average = 74ms
>ping 192.168.0.4 -f -l 1177
Pinging 192.168.0.4 with 1177 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.0.4:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
ASKER
>ping 192.168.0.4 -f -l 1259
Pinging 192.168.0.4 with 1259 bytes of data:
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.0.4:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
>ping 192.168.0.4 -f -l 1258
Pinging 192.168.0.4 with 1258 bytes of data:
Request timed out.
Pinging 192.168.0.4 with 1259 bytes of data:
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.0.4:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
>ping 192.168.0.4 -f -l 1258
Pinging 192.168.0.4 with 1258 bytes of data:
Request timed out.
ASKER
I have made the following changes:-
Set the VPN to transport mode at the co-lo end.
Disbled path-mtu-discovery on the tunnel
Reset the MTU to 1392 which is what it should be for GRE over VPN in tunnel mode with the reduced ADSL MTU.
Outlook now works but it and file transfers are a lot slower than a normal VPN and remote desktop connection is virtually unusable.
If I enable 'tunnel path-mtu-discovery' on the tunnel at each end then outlook etc... stops working.
Any ideas?
Set the VPN to transport mode at the co-lo end.
Disbled path-mtu-discovery on the tunnel
Reset the MTU to 1392 which is what it should be for GRE over VPN in tunnel mode with the reduced ADSL MTU.
Outlook now works but it and file transfers are a lot slower than a normal VPN and remote desktop connection is virtually unusable.
If I enable 'tunnel path-mtu-discovery' on the tunnel at each end then outlook etc... stops working.
Any ideas?
Try resetting the MaxMTU on your workstation to 1300
ASKER
For the purpose of testing only?
There are far too many workstations for this to be an option as a permanent solution.
There are far too many workstations for this to be an option as a permanent solution.
Yes, for testing only. At least we can pin down the issue and then try to find a workable solution..
Have you tried removing this entry from the LAN interface. Just leave it default and only adjust the tunnel mtu.
ip tcp adjust-mss 1328
Have you tried removing this entry from the LAN interface. Just leave it default and only adjust the tunnel mtu.
ip tcp adjust-mss 1328
ASKER
As all traffic from the remote sites is eventually going to go via the VPN to the co-lo I pursuaded then to go without routing as the remote sites wont really need it so GRE can be avoided.
I have come across another problem though which I cannot understand. Perhaps you could have a look for me
https://www.experts-exchange.com/questions/21483833/Cisco-router-router-vpn-and-sending-all-internet-traffic-over-VPN.html
I have come across another problem though which I cannot understand. Perhaps you could have a look for me
https://www.experts-exchange.com/questions/21483833/Cisco-router-router-vpn-and-sending-all-internet-traffic-over-VPN.html
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
aaa new-model
!
aaa session-id common
ip subnet-zero
ip cef
!
ip ips po max-events 100
no ftp-server write-enable
!
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key ****** address x.x.22.2 no-xauth
!
!
crypto ipsec transform-set strong esp-3des esp-md5-hmac
!
crypto ipsec profile strong
set transform-set strong
!
!
crypto map sharnbrook 1 ipsec-isakmp
set peer x.x.22.2
set transform-set strong
match address 102
!
interface Tunnel2
ip address 192.168.202.254 255.255.255.0
no ip proxy-arp
ip mtu 1368
tunnel source FastEthernet0/0
tunnel destination x.x.22.2
crypto map sharnbrook
!
interface FastEthernet0/0
ip address x.x.126.68 255.255.255.192
duplex auto
speed auto
crypto map sharnbrook
!
interface FastEthernet0/1
ip address 192.168.1.254 255.255.255.0
ip tcp adjust-mss 1328
duplex auto
speed auto
!
router ospf 100
log-adjacency-changes
passive-interface FastEthernet0/0
network 192.168.1.0 0.0.0.255 area 0
network 192.168.202.0 0.0.0.255 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 x.x.126.65 100
!
ip http server
no ip http secure-server
!
!
access-list 102 remark sharnbrook
access-list 102 permit gre host x.x.126.68 host x.x.22.2
!
control-plane