09-28-2010 04:03 PM
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...
09-28-2010 05:29 PM
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
09-28-2010 07:12 PM
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
09-28-2010 07:38 PM
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
09-28-2010 07:45 PM
I did use -f. The commands used were:
ping -f -l 1500 www.google.com
ping -f -l 1400 www.google.com
09-28-2010 07:52 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide