VPN full (non-split) tunnel - can ping but not connect

Unanswered Question
Sep 28th, 2010

We've got a 3005 VPN concentrator and have successfully been using it for years for a bunch of split tunnels, both LAN-to-LAN and remote user.  Now I have need of a non-split tunnel for a remote user, so I set up a new group that is the same as our existing group except that under "Client

Config" it is set to "Tunnel Everything" instead of "Only tunnel networks in the list".

I then set up a new user that is set to use this new group.

When I log in with this new group/user, I can still access the internal network at the site of the concentrator, but I can't

reach the outside world. Well, interestingly, I can ping the outside world but I can't do

anything more.

% ping www.google.com

PING www.l.google.com (74.125.19.104): 56 data bytes

64 bytes from 74.125.19.104: icmp_seq=0 ttl=55 time=1142.598 ms

64 bytes from 74.125.19.104: icmp_seq=1 ttl=55 time=1573.098 ms

% telnet www.google.com 80
Trying 74.125.19.104...
telnet: connect to address 74.125.19.104: Operation timed out

To try and resolve this problem, I've tried a bunch of things, none of which have worked:

I thought maybe it was a problem with both groups using the same address pool, so I set up

a new pool just for this new group.

Although I didn't see any incoming packets being blocked, just in case, I allowed everything to

these addresses in our router:

! Permit incoming packets to non-split tunnel pool

permit ip any host xxx.51.157.100

permit ip any host xxx.51.157.101

No dice. I also thought perhaps the incoming packets to these addresses don't know where

they need to go (even though the fact that pings work would seem to say this isn't the

problem), so I set up static routes:

! Full (non-split) tunnel pool addresses route to VPN Concentrator

ip route xxx.51.157.100 255.255.255.255 xxx.51.157.25 155

ip route xxx.51.157.101 255.255.255.255 xxx.51.157.25 155

Finally, I thought maybe packet fragmentation could be at fault, so I set the maximum packet

size on the router to 1400:

ip tcp mss 1400

Oh, I should also include related logging. When I try connecting through the non-split
tunnel, the VPN Concentrator logs messages like the following:

1520959 09/28/2010 14:11:32.900 SEV=6 IPSEC/42 RPT=13179 76.88.62.180
Replay window failure (rcv'd 403, current 403) - discarding packet!

1520960 09/28/2010 14:11:32.910 SEV=6 IPSEC/42 RPT=13180 76.88.62.180
Replay window failure (rcv'd 405, current 405) - discarding packet!

1520961 09/28/2010 14:11:34.800 SEV=6 IPSEC/42 RPT=13181 76.88.62.180
Replay window failure (rcv'd 446, current 446) - discarding packet!

I also tried changing the behavior of the various filters from "Drop" to "Drop and Log' but that
didn't seem to result in any extra logging. I suspect those filters are not actually being used.
This was under
Configuration | Policy Management | Traffic Management | Filters

I've thought maybe I need to change some of the policy in

Configuration | Policy Management | Traffic Management | Rules

such as changing some from "Forward" to "Apply IPSec" though I'm weary of changing any global settings that might break the 99% of traffic (in split tunnels) that's working fine.

I don't have any firewalls enabled in the concentrator.

I'd welcome any ideas.  Thanks...

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
manish arora Tue, 09/28/2010 - 17:29

Use extended Ping command on the client to verify the MSS for the packets just to be sure for packet size :-

Ping google.com -f -l 1500

then

ping google.com -f -l 1400

-f = set donot fragment bit

-l = size of the packet.

Thanks

Manish

tokyojimu858 Tue, 09/28/2010 - 19:12

Both commands (corrected) seem to operate the same, flooding the screen with dots.

With -l 1500:

--- www.l.google.com ping statistics ---

17924 packets transmitted, 15704 packets received, +308 duplicates, 12% packet loss

round-trip min/avg/max/stddev = 40.958/863.590/2019.521/238.113 ms

With -l 1400:
--- www.l.google.com ping statistics ---
10131 packets transmitted, 8171 packets received, +257 duplicates, 19% packet loss
round-trip min/avg/max/stddev = 210.899/821.421/1877.746/217.075 ms
manish arora Tue, 09/28/2010 - 19:38

well , I think you missed  "-f " to set up the donot fragment bit , If you have set up DF ( do not fragment ), then your traffic isn't getting getting into the ipsec tunnel , i mean to say with 1500 mtu DF on it doesn't go through the tunnel.

Try setting the MTU on the client for 1280 or even lower just to make sure.

Thanks

Manish

manish arora Tue, 09/28/2010 - 19:52

Well, if you are getting replys from DF bit set 1500 on an IPsec connection that means some thing is "fooked" . Please check the logs on the client to see if you are even getting rules set up on the clients for complete tunnelling. You can use "Shrewsoft RAClient -- open source" , it comes with a trace utility where you can see what all traffic will go into the tunnel.

Hope it helps

manish

Actions

This Discussion