Link to home
Start Free TrialLog in
Avatar of grblades
grbladesFlag for United Kingdom of Great Britain and Northern Ireland

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
Avatar of grblades
grblades
Flag of United Kingdom of Great Britain and Northern Ireland image

ASKER

Router B
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
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
Avatar of Les Moore
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?

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.
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?
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.
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.
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.
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 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.
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?
Try resetting the MaxMTU on your workstation to 1300

For the purpose of testing only?

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
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
ASKER CERTIFIED SOLUTION
Avatar of RomMod
RomMod

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial