L2TP server subnet mask problem
marcdeblanck
Newbie ✭
At our office we use an external DHCP server that has a subnet mask: 255.255.240.0 and all works fine!
But at a customer site we use the internal DHCP server witch also has an subnet mask: 255.255.240.0
the L2TP VPN connection works but only within the subnet mask 255.255.255.0
I can ping / connect to every machine in the 255.255.255.0 range but none of the ip's outside that range
example if my vpn ip is 192.168.0.93
i can ping 192.168.0.1
but I can not ping 192.168.1.1 even if the internal DHCP Server subnet mask is set to 255.255.240.0
any idea?
Kind Regards
Marc
Category: Entry Level Firewalls
0
Answers
Hello @marcdeblanck,
I hope you are safe and well!
Can you please help me with the below:
Thank You
Knowledge Management Senior Analyst at SonicWall.
Yes, I have one other idea. The subnet mask used on the destination servers matters also. If they are using 255.255.240.0 (aka /20), then you would expect it to work if the L2TP clients has the same mask. But if the servers use a narrower subnet mask 255.255.255.0 (aka /24), then their traffic going back to the client would be sent to its default GW, which then would have to route back to the firewall for the destination network which contains the client IP.
you are correct but that is not the case here
okay, i'll see if i can set this up today or tommorow (i restricted to work only 2 day a week for now)
because that would be the case if the customer work internally aswell
Below the capture of a ping that works (strange thing is i can't see a ping captured to the not working ip: 192.0.1.21)
*Packet number: 50*
Header Values:
Bytes captured: 66, Actual Bytes on the wire: 66
Packet Info(Time:04/21/2020 02:16:24.032):
in:--, out:X0*, Forwarded, 2:2) VPN policy: WAN GroupVPN
Ethernet Header
Ether Type: IP(0x800), Src=[18:b1:69:cc:ec:68], Dst=[a8:20:66:45:c6:82]
IP Packet Header
IP Type: TCP(0x6), Src=[192.0.0.218], Dst=[192.0.0.21]
TCP Packet Header
TCP Flags = [ACK,], Src=[49658], Dst=[5900], Checksum=0x6fb1
Application Header
Not Known
Value:[0]
Hex and ASCII dump of the packet:
a8206645 c68218b1 69ccec68 08004500 00340000 40004006 *. fE....i..h..E..4..@.@.*
b9d4c000 00dac000 0015c1fa 170c0189 7df38fa1 101f8010 *................}.......*
0f556fb1 00000101 080a356f 98200d73 a380 *.Uo.......5o. .s.. *
*Packet number: 51*
Header Values:
Bytes captured: 180, Actual Bytes on the wire: 180
Packet Info(Time:04/21/2020 02:16:24.032):
in:X0*(interface), out:--, Consumed, Module Id:20, 1:2) VPN policy: WAN GroupVPN
Ethernet Header
Ether Type: IP(0x800), Src=[a8:20:66:45:c6:82], Dst=[18:b1:69:cc:ec:68]
IP Packet Header
IP Type: TCP(0x6), Src=[192.0.0.21], Dst=[192.0.0.218]
TCP Packet Header
TCP Flags = [ACK,PSH,], Src=[5900], Dst=[49658], Checksum=0x9c5f
Application Header
Not Known
Value:[0]
Hex and ASCII dump of the packet:
18b169cc ec68a820 6645c682 08004502 00a60000 40004006 *..i..h. fE....E.....@.@.*
b960c000 0015c000 00da170c c1fa8fa1 101f0189 7df38018 *.`..................}...*
08009c5f 00000101 080a0d73 a391356f 98200070 f2433226 *..._.......s..5o. .p.C2&*
3924cff8 dedeacc2 e34043d9 3c1a8c61 c93df6f8 06151008 *9$.......@C.<..a.=......*
20327dcc eccf6b32 2f7b0c5b 65854fe9 3276e840 68894ad0 * 2}...k2/{.[e.O.2v.@h.J.*
2c016032 87bc4682 14cd9db7 1c4704ef 905f3794 44240663 *,.`2..F......G..._7.D$.c*
2016f50f d88054e8 7079c110 e06589ec 5347d398 75e37981 * .....T.py...e..SG..u.y.*
ef39adc4 7d81ad2a 61a4469a *.9..}..*a.F. *
Hello @marcdeblanck ,
Thank you for running the test, can you please follow : https://www.sonicwall.com/de-de/support/knowledge-base/l2tp-ipsec-vpn-connects-but-no-access-to-remote-lan-network-on-mac-os-x/190222144555437/ and let me know if this helps.
Knowledge Management Senior Analyst at SonicWall.
Hey KaranM, following the setting did not change anything to the vpn connection but the line at the bottom does help
netstat -nr shows
192.0.0 ppp0 USc ppp0
192.0.0.1 192.0.0.223 UH ppp0
adding
sudo route add -net 192.0.0.0/23 -interface ppp0
solves the problem and netstat -nr shows
192.0.0 ppp0 USc ppp0
192.0.0/23 ppp0 USc ppp0
192.0.0.1 192.0.0.223 UH ppp0
note the subnet-mask is 255.255.254.0 (/23)
ping results from my Mac gives good result
marcdebl@theKid ~ % ping 192.0.0.21
PING 192.0.0.21 (192.0.0.21): 56 data bytes
64 bytes from 192.0.0.21: icmp_seq=0 ttl=64 time=249.834 ms
64 bytes from 192.0.0.21: icmp_seq=1 ttl=64 time=35.143 ms
^C
--- 192.0.0.21 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 35.143/142.488/249.834/107.346 ms
marcdebl@theKid ~ % ping 192.0.1.22
PING 192.0.1.22 (192.0.1.22): 56 data bytes
64 bytes from 192.0.1.22: icmp_seq=0 ttl=64 time=40.238 ms
64 bytes from 192.0.1.22: icmp_seq=1 ttl=64 time=50.407 ms
64 bytes from 192.0.1.22: icmp_seq=2 ttl=64 time=28.655 ms
^C
--- 192.0.1.22 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.655/39.767/50.407/8.886 ms
although that running the command did solve the problem when I disconnect and reconnect I have to reply that command
I can not ask that from the customer to do this every time, right!
when I connect to our own office that uses 172.27.0.0/20 with an external DHCP server (running on a macOS) and run the netstat -nr I get
172.27 ppp0 USc ppp0
172.28.0.254 172.27.3.248 UH ppp0
and then I can connect to all ip's in the /20 range
it looks like the internal DHCP server return the wrong subnet-mask as the netstat -nr returns
192.0.0 ppp0 USc ppp0
192.0.0.1 192.0.0.213 UH ppp0