L2TP client don't get a network settings from VPN server correctly - routing doesn't work.

Hello all,

I’m evaluating a RouterOS currently on virtual machine to estimate some functions that need to me - if all will be good, planning to buy Mikrotik Wi-Fi router. One of features which I’m interested in is L2TP client, so first of all I’ve tried to configure it on my test environment (one “client PC” under Windows and RouterOS host which serves as a router). Although client configured and connection established (was able to traceroute remote gateway on remote VPN), I saw that l2tp interface got wrong network settings from DHCP server - see configuration commands and info below:

Meanwhile according to SoftEther server logs (it’s used as L2TP server) - DHCP supplies all correct network settings including network, gateway etc:

2015-08-20 08:51:35.343 L2TP PPP Session [xxx.xxx.xxx.xxx:48390]: Trying to request an IP address from the DHCP server.
2015-08-20 08:51:35.484 [HUB "VPN01"] Session "SID-LOCALBRIDGE-1": The DHCP server of host "00-AC-CA-F7-19-BC" (10.7.0.1) on this session allocated, for host "SID-xxxxx-[L2TP]-10" on another session "CA-82-6F-00-9A-3E", the new IP address 10.7.0.100.
2015-08-20 08:51:35.484 L2TP PPP Session [xxx.xxx.xxx.xxx:48390]: An IP address is assigned. IP Address of Client: 10.7.0.100, Subnet Mask: 255.255.255.0, Default Gateway: 10.7.0.1, Domain Name: "ll-local", DNS Server 1: 8.8.8.8, DNS Server 2: 0.0.0.0, WINS Server 1: 0.0.0.0, WINS Server 2: 0.0.0.0, IP Address of DHCP Server: 10.7.0.1, Lease Lifetime: 43200 seconds
2015-08-20 08:51:35.484 L2TP PPP Session [xxx.xxx.xxx.xxx:48390]: The IP address and other network information parameters are set successfully. IP Address of Client: 10.7.0.100, Subnet Mask: 255.255.255.0, Default Gateway: 10.7.0.1, DNS Server 1: 8.8.8.8, DNS Server 2: 0.0.0.0, WINS Server 1: 0.0.0.0, WINS Server 2: 0.0.0.0

So could you please explain, what I’m doing wrong?

Best regards,
Konstantin

Could anybody help? In addition - with this settings I able only to ping gateway from the VPN network (10.7.0.1), other hosts which should be accessible through NAT configured on remote side, isn’t accessible.

Anybody here from Mikrotik staff? Still waiting for answer…

This is user forum. When you need answer from mikrotik staff, ask them directly and let us know.

Send an email to support@mikrotik.com

I think it’s a bit early to be screaming for Mikrotik Support.

What methods have you used to debug this issue? Do you have packet Captures?

What aren’t you able to access on the remote side? Do you have a diagram?

I’m back - so let’s describe again. I’ve installed RouterOS on virtual machine to test functionality which is interested to me, L2TP client. So the diagram is the following:

  1. On the client side we have a virtual machine with 2 network interfaces, first is for “LAN” (isn’t needed on preliminary testing) second is for “WAN” (plugged to NAT and have an internet connection).
  2. On the server side we have a VPS in hosting provider data center which is runing under Ubuntu server and have a SoftEther VPN server configured on it. It have a L2TP server function enabled and I haven’t any problems to connect to it using built-in WIndows L2TP client, all functioning as it should including remote gateway accessibility etc.

So I’ve configured RouterOS L2TP client with the following commands:

/interface l2tp-client add name=l2tp-test connect-to=y.y.y.y user=xxxx password=xxxxx profile=default
/interface l2tp-client enable

After that connection is established and I can see it also in SoftEther server logs. Moreover, when I’m trying to ping IP address which was assigned to RouterOS client from VPN server side I see that ICMP packets is arriving RouterOS side according to packet sniffering logs. But connection doesn’t work as it should (for example I can’t ping remote gateway address) - I guess because after connection established, interface got wrong network settings:

[admin@MikroTik] > /ip address print detail
Flags: X - disabled, I - invalid, D - dynamic
 0   address=192.168.0.1/24 network=192.168.0.0 interface=ether1 actual-interface=ether1

 1 D address=10.0.3.15/24 network=10.0.3.0 interface=ether2 actual-interface=ether2

 2 D address=10.7.0.100/32 network=1.0.0.1 interface=l2tp-test actual-interface=l2tp-test

So could you explain please what I’m doing wrong here?

Best regards,

Konstantin

Moreover, when I’m trying to ping IP address which was assigned to RouterOS client from VPN server side I see that ICMP packets is arriving RouterOS side according to packet sniffering logs. But connection doesn’t work as it should (for example I can’t ping remote gateway address) - I guess because after connection established, interface got wrong network settings:

Please could you grab a packet capture?

What packets you need exactly - I mean which session need to be captured? As I’ve written above, connection established successfully and ICMP packets is arriving on RouterOS side while I’m trying to ping it’s assigned IP from VPN server side.

Best regards,

Konstantin

When you ping from the VPN server, do you get a response?

Id like to see a packet capture of attempting to ping a remote address

Situation is the following: when I’m trying to ping from the VPN server, ICMP request packets is arriving at RouterOS side according to packet capture log, but no ICMP response packets generated on l2tp-test interface because as I’ve written above it got wrong network settings. Here is packet log:

[admin@MikroTik] > /tool sniffer packet print
 #    TIME IN.. SRC-ADDRESS                                 DST-ADDRESS                                 IP-..  SIZE CPU
 0   9.371 l2.. 10.7.0.1                                    10.7.0.100                                  icmp     84   0
 1   10.37 l2.. 10.7.0.1                                    10.7.0.100                                  icmp     84   0
 2   11.37 l2.. 10.7.0.1                                    10.7.0.100                                  icmp     84   0
[admin@MikroTik] >

10.7.0.100 here is address assigned to l2tp-test interface, 10.7.0.1 is remote VPN gateway.

Best regards,

Konstantin

Which interface did you run the sniffer on? Please could you provide a proper .pcap ?

I did capture on l2tp-test interface - here is a .pcap file:
http://rghost.net/8Dq2HWFW2
Best regards,

Konstantin

I’m afraid that file host site is a bit confusing as there’s about 2000 download links, and most of them probably lead to some kind of Malware. Is there somewhere else you can host the file, like Dropbox or Google Drive?

Ok - here it is: https://drive.google.com/file/d/0Byvx0_28qNWhb3Z3bGRRRFhYNUE/view?usp=sharing

Best regards,

Konstantin

Thanks. It could be getting dropped by a firewall, or maybe it’s going out the wrong interface due to the incorrect network field. What happens if you run the sniffer on all interfaces? Do you see replies going out?

That’s I’ve talked about already - the remote VPN gateway is unreachable due to incorrect network settings which l2tp-test interface got after connection (look at the network field for l2tp-test interface):

[admin@MikroTik] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         INTERFACE
 0   192.168.0.1/24     192.168.0.0     ether1
 1 D 10.0.3.15/24       10.0.3.0        ether2
 2 D 10.7.0.100/32      1.0.0.1         l2tp-test

I’ve understood it’s already, my question was - why L2TP interface getting wrong network settings during connection and how to fix it? As I’ve written before - Windows client is works good, no any problems.

Best regards,

Konstantin

Before we can attempt to fix it, we need to know what’s causing the issue, and what affect it has. This generally requires packet captures and some detailed diagnosis. Unfortunately this can be time consuming.

If you know a better way, please go ahead and let us know how you fix it.

Ok, here is the capture for all interfaces with filtering set to address=10.7.0.0/24: https://drive.google.com/file/d/0Byvx0_28qNWhUmdpdmdXWmJ5Wms/view?usp=sharing
And in addition here is sniffer log for this session:

[admin@MikroTik] > /tool sniffer packet print detail
 0 time=37.756 num=1 direction=rx interface=l2tp-test src-address=10.7.0.1 dst-address=10.7.0.100 protocol=ip
   ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=1811 fragment-offset=0
   ttl=64

 1 time=37.756 num=2 direction=tx interface=ether2 src-address=10.7.0.100 dst-address=10.7.0.1 protocol=ip
   ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=54076 fragment-offset=0
   ttl=64

 2 time=38.764 num=3 direction=rx interface=l2tp-test src-address=10.7.0.1 dst-address=10.7.0.100 protocol=ip
   ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=1999 fragment-offset=0
   ttl=64

 3 time=38.764 num=4 direction=tx interface=ether2 src-address=10.7.0.100 dst-address=10.7.0.1 protocol=ip
   ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=54077 fragment-offset=0
   ttl=64

 4 time=39.77 num=5 direction=rx interface=l2tp-test src-address=10.7.0.1 dst-address=10.7.0.100 protocol=ip
   ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=2210 fragment-offset=0
   ttl=64

 5 time=39.77 num=6 direction=tx interface=ether2 src-address=10.7.0.100 dst-address=10.7.0.1 protocol=ip
   ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=54078 fragment-offset=0
   ttl=64

 6 time=40.71 num=7 direction=tx interface=l2tp-test src-address=10.7.0.100:5678 (discovery)
   dst-address=255.255.255.255:5678 (discovery) protocol=ip ip-protocol=udp size=112 cpu=0 ip-packet-size=112
   ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=64

Best regards,

Konstantin

Ok, the #1 packet in the sniffer log shows the packet is leaving the Ether2 interface, which is bad news.

Please could you post the output from-

/ ip route print