Packet loss when connected to L2TP/IPsec VPn
-
Had a working remote access vpn setup on an edge router lite, but this weekend we changed our main ISP from Comcast to ATT. The only change made to the working config was the outside-address setting which now points to the new ATT ip everything else is exactly the same.
Today users where reporting that the VPN was really slow, windows shares wouldn't open for them and web browsing was also not working. When I remoted into one of the machines, it was indeed barely working when connected to the vpn, the remote session was having lots of trouble being open.
I set up the vpn on a test vm and starting pinging the file share:
Ping
Ping statistics for 10.10.10.1: Packets: Sent = 195, Received = 109, Lost = 86 (44% loss), Approximate round trip times in milli-seconds: Minimum = 87ms, Maximum = 238ms, Average = 103ms
Tracert
Tracing route to 10.10.10.1 over a maximum of 30 hops: 1 * 98 ms 102 ms 10.255.255.0 2 96 ms * * 10.10.10.1 3 93 ms 96 ms * 10.10.10.1 4 * * 106 ms 10.10.10.1
Any idea what could be causing this issue? Also seems strange the tracert reaches the server 3 times for some reason.
Could this be the provider? this only started after the change to ATT, with comcast everything was working properly.
-
@Romo said in Packet loss when connected to L2TP/IPsec VPn:
Also seems strange the tracert reaches the server 3 times for some reason.
that is super weird
-
@Romo said in Packet loss when connected to L2TP/IPsec VPn:
Also seems strange the tracert reaches the server 3 times for some reason.
Maybe some kind of routing issue?
-
Also, could this be an MTU settings issue? I know they're rare... but that was the first thing that popped into my mind.
-
We had a similar problem with one of our warehouse locations after switching to AT&T Business Fiber. IPsec site to site VPN to our head office would randomly stop passing traffic, traffic outside the tunnel was fine. For us, the issue was fixed by disabling ESP ALG on the AT&T gateway.
-
That is weird. Have you disabled and re-enabled the tunnel?
-
This is remote access not site to site by the way. I have indeed restarted the vpn and packet loss still is there.
-
@dafyre said in Packet loss when connected to L2TP/IPsec VPn:
Also, could this be an MTU settings issue? I know they're rare... but that was the first thing that popped into my mind.
Was inded thinking about playing with the MTU, just now sure why it wouldn't on ATT. It is currently set for 1492
-
@Romo said in Packet loss when connected to L2TP/IPsec VPn:
@dafyre said in Packet loss when connected to L2TP/IPsec VPn:
Also, could this be an MTU settings issue? I know they're rare... but that was the first thing that popped into my mind.
Was inded thinking about playing with the MTU, just now sure why it wouldn't on ATT. It is currently set for 1492
UVerse? Then your service is PPPoE. You likely need to lower the MTU to account for it.
Also If UVerse, you are screwed in your router options.
-
I'm assuming that the performance outside the VPN connection is fine, right?
-
@JaredBusch said in Packet loss when connected to L2TP/IPsec VPn:
@Romo said in Packet loss when connected to L2TP/IPsec VPn:
@dafyre said in Packet loss when connected to L2TP/IPsec VPn:
Also, could this be an MTU settings issue? I know they're rare... but that was the first thing that popped into my mind.
Was inded thinking about playing with the MTU, just now sure why it wouldn't on ATT. It is currently set for 1492
UVerse? Then your service is PPPoE. You likely need to lower the MTU to account for it.
Also If UVerse, you are screwed in your router options.
I haven't dealt with PPPoE since I stopped using DSL 12 years ago.
-
@wrx7m said in Packet loss when connected to L2TP/IPsec VPn:
@JaredBusch said in Packet loss when connected to L2TP/IPsec VPn:
@Romo said in Packet loss when connected to L2TP/IPsec VPn:
@dafyre said in Packet loss when connected to L2TP/IPsec VPn:
Also, could this be an MTU settings issue? I know they're rare... but that was the first thing that popped into my mind.
Was inded thinking about playing with the MTU, just now sure why it wouldn't on ATT. It is currently set for 1492
UVerse? Then your service is PPPoE. You likely need to lower the MTU to account for it.
Also If UVerse, you are screwed in your router options.
I haven't dealt with PPPoE since I stopped using DSL 12 years ago.
U-Verse is just DSL2 or some variant there of.
-
@JaredBusch said in Packet loss when connected to L2TP/IPsec VPn:
@Romo said in Packet loss when connected to L2TP/IPsec VPn:
@dafyre said in Packet loss when connected to L2TP/IPsec VPn:
Also, could this be an MTU settings issue? I know they're rare... but that was the first thing that popped into my mind.
Was inded thinking about playing with the MTU, just now sure why it wouldn't on ATT. It is currently set for 1492
UVerse? Then your service is PPPoE. You likely need to lower the MTU to account for it.
Also If UVerse, you are screwed in your router options.
How low should I go, or is it just a matter of testing? Currently at 1400, web browsing is still not working properly.
Tracing route to 10.10.10.1 over a maximum of 30 hops: 1 * 105 ms 102 ms 10.255.255.0 2 118 ms 104 ms 102 ms 10.10.10.1 Trace complete. PS C:\WINDOWS\system32> tracert 10.10.10.1 Tracing route to 10.10.10.1 over a maximum of 30 hops: 1 106 ms 106 ms * 10.255.255.0 2 116 ms * * 10.10.10.1 3 103 ms 109 ms 121 ms 10.10.10.1
-
@Romo I do not recall what the TCP overhead is on PPPoE without looking it up.
-
@JaredBusch said in Packet loss when connected to L2TP/IPsec VPn:
@Romo said in Packet loss when connected to L2TP/IPsec VPn:
@dafyre said in Packet loss when connected to L2TP/IPsec VPn:
Also, could this be an MTU settings issue? I know they're rare... but that was the first thing that popped into my mind.
Was inded thinking about playing with the MTU, just now sure why it wouldn't on ATT. It is currently set for 1492
UVerse? Then your service is PPPoE. You likely need to lower the MTU to account for it.
Also If UVerse, you are screwed in your router options.
Not Uverse, it's their enterprise leased line.
-
Been playing for the value for a while and still no luck. I am still seeing packet loss.
Edge router logs have been showing:
May 7 18:00:48 office pppd[24483]: pppd 2.4.7 started by root, uid 0 May 7 18:00:48 office pppd[24483]: Connect: ppp0 <--> May 7 18:00:48 office pppd[24483]: Overriding mtu 1500 to 1474 May 7 18:00:48 office pppd[24483]: Overriding mru 1500 to mtu value 1474 May 7 18:00:50 office pppd[24483]: Unsupported protocol 'IPv6 Control Protocol' (0x8057) received May 7 18:00:50 office pppd[24483]: Unsupported protocol 'Compression Control Protocol' (0x80fd) received May 7 18:00:51 office pppd[24483]: Cannot determine ethernet address for proxy ARP May 7 18:00:51 office pppd[24483]: local IP address 10.255.255.0 May 7 18:00:51 office pppd[24483]: remote IP address 192.168.4.10 May 7 18:03:45 office pppd[24483]: Overriding mtu 1500 to 1474 May 7 18:03:45 office pppd[24483]: Overriding mru 1500 to mtu value 1474
Any other ideas?
-
@Romo said in Packet loss when connected to L2TP/IPsec VPn:
Been playing for the value for a while and still no luck. I am still seeing packet loss.
Based on what @scottalanmiller said, I would not expect MTU to be involved.
-
Ok even weirder behavior now, currently I am getting steady pings for a very short period of time and then the connections just seems to die.
MTU is currently set to 1472
Pinging 10.10.10.1 with 32 bytes of data: Reply from 10.10.10.1: bytes=32 time=87ms TTL=127 Reply from 10.10.10.1: bytes=32 time=89ms TTL=127 Reply from 10.10.10.1: bytes=32 time=87ms TTL=127 Reply from 10.10.10.1: bytes=32 time=89ms TTL=127 Reply from 10.10.10.1: bytes=32 time=90ms TTL=127 Reply from 10.10.10.1: bytes=32 time=88ms TTL=127 Reply from 10.10.10.1: bytes=32 time=87ms TTL=127 Reply from 10.10.10.1: bytes=32 time=88ms TTL=127 Reply from 10.10.10.1: bytes=32 time=93ms TTL=127 Reply from 10.10.10.1: bytes=32 time=93ms TTL=127 Reply from 10.10.10.1: bytes=32 time=94ms TTL=127 Reply from 10.10.10.1: bytes=32 time=91ms TTL=127 Reply from 10.10.10.1: bytes=32 time=88ms TTL=127 Reply from 10.10.10.1: bytes=32 time=87ms TTL=127 Reply from 10.10.10.1: bytes=32 time=93ms TTL=127 Reply from 10.10.10.1: bytes=32 time=95ms TTL=127 Reply from 10.10.10.1: bytes=32 time=91ms TTL=127 Reply from 10.10.10.1: bytes=32 time=90ms TTL=127 Reply from 10.10.10.1: bytes=32 time=101ms TTL=127 Reply from 10.10.10.1: bytes=32 time=89ms TTL=127 Reply from 10.10.10.1: bytes=32 time=88ms TTL=127 Reply from 10.10.10.1: bytes=32 time=88ms TTL=127 Reply from 10.10.10.1: bytes=32 time=89ms TTL=127 Reply from 10.10.10.1: bytes=32 time=106ms TTL=127 Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out.
During that initial time, when the connection has just established web browsing also works close to normal speeds I would say. Really strange behavior.
-
I never have a problem with my VPN on my iPhone.
May 7 19:42:34 bna-jared xl2tpd[4722]: Connection established to 172.58.142.195, 50961. Local: 48550, Remote: 4 (ref=0/0). LNS session is 'default' May 7 19:42:34 bna-jared xl2tpd[4722]: Call established with 172.58.142.195, Local: 3582, Remote: 2938, Serial: 1 May 7 19:42:34 bna-jared pppd[8432]: pppd 2.4.7 started by root, uid 0 May 7 19:42:34 bna-jared pppd[8432]: Connect: ppp0 <--> May 7 19:42:34 bna-jared pppd[8432]: Overriding mtu 1500 to 1492 May 7 19:42:34 bna-jared pppd[8432]: Overriding mru 1500 to mtu value 1492 May 7 19:42:34 bna-jared pppd[8432]: Overriding mtu 1500 to 1492 May 7 19:42:35 bna-jared pppd[8432]: Warning - secret file /etc/ppp/chap-secrets has world and/or group access May 7 19:42:35 bna-jared pppd[8432]: Unsupported protocol 'IPv6 Control Protocol' (0x8057) received May 7 19:42:35 bna-jared pppd[8432]: local IP address 10.255.255.0 May 7 19:42:35 bna-jared pppd[8432]: remote IP address 10.254.203.2 May 7 19:43:05 bna-jared pppd[8432]: Connection terminated: no multilink. May 7 19:43:05 bna-jared pppd[8432]: Modem hangup
Here is my config.
set vpn l2tp remote-access authentication local-users username jbusch password 'SmegOff' set vpn l2tp remote-access authentication mode local set vpn l2tp remote-access authentication require mschap-v2 set vpn l2tp remote-access client-ip-pool start 10.254.203.2 set vpn l2tp remote-access client-ip-pool stop 10.254.203.10 set vpn l2tp remote-access dhcp-interface eth0 set vpn l2tp remote-access dns-servers server-1 8.8.8.8 set vpn l2tp remote-access dns-servers server-2 8.8.4.4 set vpn l2tp remote-access idle 1800 set vpn l2tp remote-access ipsec-settings authentication mode pre-shared-secret set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret SmegOff set vpn l2tp remote-access ipsec-settings ike-lifetime 3600 set vpn l2tp remote-access ipsec-settings lifetime 3600 set vpn l2tp remote-access mtu 1492
The IP range is not used elsewhere in my router at all.
-
This was working properly until we switched to ATT. It is still properly reaching the router and also authenticating correctly to the radius server. It's just after connecting it completely craps out.