Re: Unusual VPN Issue - Can Ping But Nothing Else

cody.rowland · ‎06-30-2004

I'm experiencing an unusual VPN issue that I'm hoping someone can help me with. I've configured several router-to-PIX tunnels with a new configuration we have to use to meet a clients demands and some of the tunnels are working while others are not. The unusual piece of the puzzle is that in every case the tunnel comes up but in a few instances, all I can do is ping through tunnel and nothing else (i.e. RDP). In every case, each site is configured in exactly the same way so I'm perplexed as to why this is happening in some places and not the others. After doing a little research here on the forums, it sounds like MTU settings might be the culprit or perhaps IP unreachables.

I'll post part of my configs in a moment but before I do, I wanted to point out that on the router side of the tunnel we're using a "hide" address to PAT all VPN traffic before it's encrypted. I wanted to point that out because the configuration is a bit different than most.

Here is a modified router config for one of the locations that's having issues:

ip subnet-zero

!

no ip domain-lookup

!

crypto isakmp policy 10

hash md5

authentication pre-share

crypto isakmp key REMOVED address REMOVED

!

crypto ipsec transform-set auth1 esp-des esp-md5-hmac

!

crypto map nyvpn 9 ipsec-isakmp

set peer REMOVED

set transform-set auth1

match address 102

crypto map nyvpn 10 ipsec-isakmp

set peer REMOVED

set transform-set auth1

match address 100

crypto map nyvpn 11 ipsec-isakmp

set peer REMOVED

set transform-set auth1

match address 101

!

call rsvp-sync

!

interface Loopback0

ip address 125.14.x.x.255.255

ip directed-broadcast

ip nat outside

!

interface FastEthernet0/0

ip address REMOVED

ip nat outside

speed 100

full-duplex

crypto map nyvpn

!

interface FastEthernet0/1

ip address 10.10.4.1 255.255.252.0

ip nat inside

speed 100

full-duplex

!

ip nat inside source route-map vpnnat interface Loopback0 overload

ip nat inside source route-map vpnnonat interface FastEthernet0/0 overload

ip classless

ip route 0.0.0.0 0.0.0.0 REMOVED

no ip http server

!

access-list 100 permit ip host 125.14.4.66 10.27.8.0 0.0.0.255

access-list 101 permit ip host 125.14.4.66 10.0.4.0 0.0.3.255

access-list 102 permit ip host 125.14.4.66 126.14.0.0 0.0.255.255

access-list 120 deny ip host 125.14.4.66 126.14.0.0 0.0.255.255

access-list 120 deny ip host 125.14.4.66 10.27.8.0 0.0.0.255

access-list 120 deny ip host 125.14.4.66 10.0.4.0 0.0.3.255

access-list 120 permit ip 10.10.4.0 0.0.3.255 any

access-list 130 permit ip 10.10.4.0 0.0.3.255 126.14.0.0 0.0.255.255

access-list 130 permit ip 10.10.4.0 0.0.3.255 10.27.8.0 0.0.0.255

access-list 130 permit ip 10.10.4.0 0.0.3.255 10.0.4.0 0.0.3.255

access-list 130 deny ip any any

route-map vpnnonat permit 10

match ip address 120

!

route-map vpnnat permit 10

match ip address 130

!

I hesitate to post the PIX configuration because it's quite large and I don't want to take the time to edit it all down!

Any help would be appreciated!

cody.rowland · ‎06-30-2004

I should have probably mentioned that on the PIX I'm using the "sysopt connection permit-ipsec" command so I don't believe it's an ACL issue on that side.

steven.wilson · ‎07-01-2004

I had a similar problem to the one that you described. I solved it with the command "IP MTU 1500" on the outside interface of the router.

Cheers,

Steve

bob · ‎07-01-2004

Sir, i just had this problem all of 5 minutes ago... I could ping and the IT dept celebrated (our first VPN) Then we tried to test software everything failed... we were all like what the heck... Then it hits me... ROUTES!

Try adding a route on one of the client machines to point to the box you configured for the vpn ;) i just had to do it.

cody.rowland · ‎07-01-2004

Thank you for the reply but in this particular instance there's no reason to add routes because the clients are using the inside IP address of the router as a default gateway.

I'll try adding the ip mtu 1500 setting tonight to see if that makes a difference. I'm still not quite sure why it would work in some locations and not others!

steven.wilson · ‎07-02-2004

Please read through the article listed below. It may explain why you need the IP MTU command.

http://www.cisco.com/warp/public/105/56.html

Cheers,

Steve

pkapoor · ‎07-06-2004

Cody,

What you are saying in a nutshell is that the tunnel comes up and you can ping but other traffic fails.

Try "crypto ipsec df-bit clear" on the router in global configuration mode and test.

watson.daniel · ‎11-24-2004

I had a similar problem after I swapped out a Sonicwall for an 837 running 12.2(13ZH4) with a VPN tunnels to one other 837 (also running 12.2 13ZH4) and another sonicwall. The sonicwall site never had a problem but the remote site with the 837 could not then access the terminal server but could rdp (sometimes) to the F&P server and map drives/ping etc. Very confusing as we could see established connections using netstat -a and there protocol errors on the event log of the Term server.

At another customer we had a similar prob a month ago but a revuild of the client pc fixed it then. Thanks to the previous post the command: crypto ipsec df-bit clear , has resolved the issue entirely and will prob now become a standard in our configs.

pkapoor · ‎11-24-2004

The command basically allows the router to clear the DF in the packet so that it may fragment it. A number of applications set this DF bit because they do not want the packet fragmented (thinking that the receiving side will not receive the packets in the way they are expected/expecting to receive). However, if the router fragments the packets, it also reassembles them. That way the receiving host is transparent to this fragmentation.

The other way to overcome this issue is to make sure that MTU on the sending host is low enough to accomodate the overhead added to the packet as it traverses the network. Most of the time IPSec overhead is not considered (which can go up as much as 60 bytes).

Another way to ensure that you do not run into MTU issues is to make sure that PMTUD works between the sending host and the receiving host. This basically requires ICMP unreachables to be permitted between the endpoints.

NOTE:

If there is execssive fragmentation required, then clearing the DF bit on the router will compromise performance. If you notice that clearing DF bit, the router's performance has slowed down, undo the command and try to identify where the packets are being fragmented. You may also allow for PMTUD or set the MTU value on the sending host to a lower value. A Windows utility that helps you configure this on a host is Dr. TCP (although I would recommend it as the last option).

TIP:

If you see that the tunnel is passing some traffic and not others (or passing some traffic intermittently), then most likely you have some form of MTU-related issue. Try clearing the DF bit.