Hi Everyone,

I'm really struggling with a site-to-site L2TP VPN that I hope someone can shed some light upon. The setup is as follows:

Head Office:
> Static WAN IP Address
> Mikrotik IP: 10.0.0.254/24
> L2TP IP: 10.0.10.254
> Static Route Created: 10.0.2.0/24 GW: 10.0.20.253

Remote Site:
> Dynamic IP 4G Connection that is connected on Port 2 of Mikrotik via 4G modem that issues a 192.168.1.0/24 IP via DHCP to the Mikrotik
> Mikrotik IP: 10.0.2.1/24
> L2TP IP: 10.0.20.253
> Static Route Created: 10.0.0.0/24 GW: 10.0.10.254

The LT2P VPN connection is successfully established and if I open a Terminal on either Mikrotik and ping a printer located on each side it replies without issue. Problem is, none of the LAN devices can see each other from either side nor can they ping each other. What have I setup incorrectly to prevent this?

Many thanks

Duke

If you can ping from a pc one side to a printer other side and vice versa, then routing is working.

Then problem is probably due to Windows firewall as they drop connections coming in from different subnet than LAN address by default

If you can ping from a pc one side to a printer other side and vice versa, then routing is working.

Then problem is probably due to Windows firewall as they drop connections coming in from different subnet than LAN address by default

Sorry, I think you've mis-read what I've said. If I open a Terminal window on each Mikrotik, I can ping printers on the other side of the VPN without issue.

It's when you try and ping those printers from a PC on the LAN at each end that the connection can't be made. Does that make sense?

1. IPSec traffic should not be masqueraded, replace your masquerade rule with this one (change eth according your needs):
/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" ipsec-policy=out,none out-interface=ether1

2. Allow IPSec traffic in forward chain (rule position in the list is important - should be above "drop everything"):
/ip firewall filter
add action=accept chain=forward comment="IPSec in policy accept" ipsec-policy=in,ipsec
add action=accept chain=forward comment="IPSec out policy accept" ipsec-policy=out,ipsec

Did you configure routes?

1. IPSec traffic should not be masqueraded, replace your masquerade rule with this one (change eth according your needs):
/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" ipsec-policy=out,none out-interface=ether1

2. Allow IPSec traffic in forward chain (rule position in the list is important - should be above default drop):
/ip firewall filter
add action=accept chain=forward comment="IPSec in policy accept" ipsec-policy=in,ipsec
add action=accept chain=forward comment="IPSec out policy accept" ipsec-policy=out,ipsec

Thanks angriukas, I'll have to test this out tomorrow. It's late here in Australia. Do I do this at both ends?

Thanks again...

Duke

Thanks angriukas, I'll have to test this out tomorrow. It's late here in Australia. Do I do this at both ends?

Thanks again...

Duke

Yes, both ends.

Did you configure routes?

IPSec is interface less. Policy plays the game.

Yes, both ends.

One final question, what do I do with my existing masquerade policy? Do I put your before mine, after mine or simply delete mine?

Thanks...

Did you configure routes?

IPSec is interface less. Policy plays the game.

Not a "pure" IPSec site to site VPN, it is a L2TP Site to Site VPN, so normal routing applies

Yes, both ends.

I set this up at both ends and still can't get it to work. I could still ping, but basically nothing changed. I have removed the changes to revert back to my original setup.

Any other suggestions?

thanks

Duke

Yes, both ends.

One final question, what do I do with my existing masquerade policy? Do I put your before mine, after mine or simply delete mine?

Thanks...

Answer: replace yours masq with new one or add "ipsec-policy=out,none" to the existing masq rule.

l2tp+ipsec are creating dynamic policies and dynamic routes. In case of successful VPN connection - you should see dynamic records in the ipsec policy list and in the route list.
If PH2 State = established and you cannot reach remote network - usually firewall blocks packets with "drop everything" rule which is last one in forward chain.

Also following approach is possible:

# Allow packets from remote site to LAN
/ip firewall filter
add action=accept chain=forward comment="remote -> local" src-address=192.168.2.0/24 dst-address=192.168.1.0/24

# Allow packets from LAN to remote site
/ip firewall nat
add action=accept chain=srcnat comment="local -> remote" src-address=192.168.1.0/24 dst-address=192.168.2.0/24

where
192.168.1.0/24 = local
192.168.2.0/24 = remote
Replaces addresses according your setup.
Mentioned approach do not require exclude ipsec packets from masq (because accept occurs before masq or before drop).
Firewall rule position is very important, in both chains place rule at the top.

You can trace issues by enabling logging (with some prefix) in "drop everything" or other rule. Prefix allows quickly find records in log window.
You should see in log window detailed info about packets (/system logging info - should be enabled).
Proper firewall rules have to be set on both routers.
Each setup is different, what I have wrote here do not means that this is the truth of the last instance

@angriukas, you keep giving correct advice but for a different scenario. As @CZFan has already written, the OP clearly says it is an L2TP over IPsec setup.

So @AwesomeDuke, if your original masquerade rule refers to out-interface-list=WAN or out-interface=the-wan-interface, you don't need to touch it; otherwise you have to add this match condition to it so that it would ignore packets leaving through the L2TP interface if you want the client addresses to reach the server. But even if the masquerade rule spans also the L2TP interfaces, it does not explain the problem. So if you cannot ping the devices connected to one Mikrotik from devices connected to the other Mikrotik, it must be a routing issue. It seems you've added some routes to the Tiks themselves, but if those Tiks are not default gateways for the devices connected to them, also routing on those devices has to be modified, or src-nat rules have to be added to the Tiks if routing at those connected devices cannot be touched.

Or, if you created your IPsec policies used to transport the L2TP manually, they may be too wide.

So all in all, too many questions. Post a diagram of your network and configuration exports of both Tiks, see anonymization hints in my automatic signature right below.

Thank you everyone for all your help and suggestions. I finally have gotten to the bottom of the issue. A bit of background:

The reason we started using this 4G connection at this location was because the ADSL had gone down and the Telco was looking at about a 1 week lead time to repair. Obviously this is unacceptable, but long story short, we had an IPSec VPN that was running over the ADSL connection to Head Office.

Because this was still running in the background trying to restore the connection, this was causing issues for the new L2TP connection for some reason. There must have been a conflict because of the same IP ranges or something, I'm not quite sure. What I did was simply disable the IPSec VPN settings at both ends and magically the L2TP started to work.I am sorry to you all for wasting your time, but as I said, I'm truly grateful for everyone's help.

Duke