Strange ping behaviour with MikroTik CRS125 over L2TP/IPSEC VPN

RouterOS General
1

Hello All,

I have a strange problem that I hope you may be able to help with!

I have a bench test scenario where I have two remote networks being connected to a central network by a L2TP/IPSec VPN through an ISP router. I have 3 MikroTik CRS125-24G-1S-RM switches, one acting as VPN server and the other two as VPN clients as shown in the diagram below:

[attachment=0]Ping issues over VPN.png[/attachment]

ether23 of MikroTik VPN client A is connected to Client A and ether23 of MikroTik VPN client B is connected to Client B respectively.

ether22 of MikroTik VPN client A is connected to one of the LAN ports on ISP Router A and ether22 of MikroTik VPN client B is connected to one of the LAN ports on ISP Router B.

The ISP routers are connected to the VPN server by a standard Ethernet switch. The ISP routers have been set to allow passthrough of an L2TP/IPsec traffic and port forward to the VPN clients.

ether2 of the VPN server is connected to this standard Ethernet switch and ether3 connected to Client C.

**Now the issue: **
I am able to ping between clients A & C, B & C and ping the interfaces on the MikroTiks ok through the VPN tunnels, however I am not able to successfully ping the LAN interface of ISP Router in each of the two remote networks, that is the 192.168.2.1 and 192.168.4.1 addresses from Client C.

A ping request from Client C to the 192.168.x.2 IP address of the MikroTiks on the LAN hosted by either of the two ISP routers is successful.
However, a ping request from Client C to the LAN IP addresses (192.168.x.1) of either of the two ISP routers fails?!

Looking into the issue with Wireshark, the ping request is being successfully sent over the tunnel from Client C, decrypted by each VPN client and forwarded onto the ISP router, as I can see that the ping reply sent by each ISP router is being received at ether2 of the VPN server, but is not being seen on ether3 where Client C is connected.

Strangely, a ping request sent from the VPN server to each of the ISP router LAN interfaces is successful but for some reason it looks like this traffic is not being presented to ether3. Looking at the ARP table for the VPN server, the entry for client C is present and valid showing the correct MAC address, IP address and port (ether3) for Client 3.

I’m stumped why the VPN server is dropping the ping response packet and not switching the ping response from the ISP Router LAN interfaces from ether2 to ether3 when the VPN server knows where to forward it to, but does this ok for a ping request from Client C to the 192.168.x.2 interfaces on MikroTik VPN clients.

Anyone got any ideas?
Ping issues over VPN.png

2

It’s a wild guess without details on the routing tables and NAT/firewall rules but I think you’ll find that the router at the sites A and B will not be able to find a route back to the Mikrotik clients to enter the tunnel as it will show up as orginiating from 192.168.6.x. Then using its default route it will try to route it accross the WAN side to the Mikrotik acting as a server where it’ll get dropped by the routing engine due to mismatching response address.

Try either to:
a) masquerade the traffic leaving the 192.168.x.x/24 interfaces on the Mikrotik VPN clients;
b) add a static route to 192.168.6.0/24 on both ISP routers pointing back to the Mikrotik to that it can pick up that traffic again and route it back through the VPN tunnels.

The default route thing may be the reason that a reply from the to the VPN server’s ping request actually finds its way back, but this again is a wild guess.

3

A bit offtopic but which program do you use to draw these nice diagrams ?

4

magchiel - your wild guess was correct! It was indeed the fact that the ISP Routers had no route back to the MikroTik VPN clients to send the ping response back through the tunnel and so were sending the ping response through their WAN interfaces and getting dropped at the other end! Unfortunately, only one of the ISP routers (these are “home grade” ISP routers/modems rather than anything prosumer or business grade) can be configured with static routes, ISP A router, and so configuring this static route allowed successful pings to its LAN interface :smiley:.

Unfortunately, ISP B Router does not have the facility to configure static routes :frowning:.

However, although I was able to ping ISP Router A’s LAN address, I wasn’t able to access the web interface of the ISP Router A :frowning:. I am thinking that there is a security function of the ISP router that denies access from clients whose host address is from a different subnet (e.g. only allow web access to hosts on the same subnet as router).

So this now led me down the masquerade/NAT’ting path. If the packet looked like it came from the same subnet of the ISP Router then there should be no issues - solution: source address NAT!

So I create a NAT rule in MikroTik VPN Client A:

/ip firewall nat
add action=src-nat chain=srcnat src-address=192.168.6.5 to-addresses=192.168.2.7

192.168.2.7 being an address not assigned to any host.

This does not produce the desired effect though - I still cannot access the Web interface of ISP A router but ping to ISP A router LAN address also stops working!

As there is no static route configuration possible on ISP B Router, I also try the similar config on MikroTik VPN Client B to hopefully see if I can get around the route problem (ISP B Router would think request is coming from host on same subnet with source NAT).

add action=src-nat chain=srcnat src-address=192.168.6.5 to-addresses=192.168.4.7 but this too doesn’t provide any success in ping or accessing the web interface of ISP B Router.

Is the syntax of the source NAT statement correct?

Thankyou!

doush - It was drawn with Microsoft Visio with shapes from the detailed network design stencil.

5

Basically you’re now saying ‘the returnaddress of all traffic originating from 192.168.6.5 is 192.168.2.7’, which will never arrive.

If you want to use srcnat, use the router-facing IP of the MT. Compared to src-nat, masquerading will be a bit more flexible should the router-facing IP address be subject to change. Try on of the following options:

/ip firewall nat
# using srcnat
add chain=srcnat out-interface=ether22 src-address=192.168.6.5 dst-address=192.168.2.1 action=src-nat to-address=192.168.2.2

# using masquerade
add chain=srcnat out-interface=ether22 src-address=192.168.6.5 dst-address=192.168.2.1 action=masquerade

These are very strict rules 1:1 rules. You could relax them a little bit by modifying or leaving out the src-address to enable access for the 10.87.2.0/24 subnet or the dst-address to allow access to other hosts in the 192.168.2.0/24 subnet.