Public IP assignment via L2TP

Greetings.

I am doing a little experiment assigning public IP adresses to remote Tiks via L2TP. The L2TP server is a CHR running version 7.7 in our data center and the clients are also running 7.7.

The problem:
Requests entering on the L2TP client interface is leaving through the clients WAN (ETH1), when it should leave via the L2TP interface. I checked this behavior using the packet sniffer tool. I believe this can be controlled with a couple of mangle rules. I have tried, but it is not working the way I expect it to. What am I doing wrong?

/ip/firewall/mangle/print
chain=prerouting action=mark-connection new-connection-mark=from-wan-vpn passthrough=yes connection-mark=no-mark in-interface=l2tp-out-wan log=no log-prefix="" 
chain=prerouting action=mark-routing new-routing-mark=WAN-VPN passthrough=no connection-mark=from-wan-vpn in-interface=l2tp-out-wan log=no log-prefix=""



/routing/rule/print 
Flags: X - disabled, I - inactive



/ip route/print where routing-table=WAN-VPN 
Flags: A - ACTIVE; s, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#    DST-ADDRESS  GATEWAY     DISTANCE
0 As 0.0.0.0/0    10.18.34.1         1

Don’t forget to adjust both end point interface MTU down to compensate for L2TP overhead. Best MTU is WAN link MTU less L2TP overhead.

Thank you, I will remember to compensate for that.

Thank you, I will remember to compensate for that.

I believe that’s not the root cause of this issue though.

L2TP adds remote side to the local Layer 2 broadcast domain. Typically local and remote are using same IP subnet but if different both subnets are still locally connected.

Firewall rules and routing tables don’t apply as both are Layer 3 functions. Bringing L2TP link up is same as connecting cable between two switches.

Correction: Bringing L2TP link up as member interface in a software bridge interface is same as connecting cable between two switches.

That is incorrect. The L2 part of L2TP refers to transporting PPP frames, the PPP session then transports IP packets and optionally ethernet using BCP if the PPP profile is so configured.

The later L2TPv3 can transport other L2 frames in addition to PPP. RouterOS 7 has added support for this but there is no documentation.

@tdw, thank you.

Adding L2TP link to a Linux bridge does what I described but omitting the bridge is critical error. Wikipedia says PPP is a typical payload but any Layer 2 packet works making software switches possible.

If you are not using multiple routing tables on the client side then try the following.

On the l2tp client tick add default route.

The client should now have a default routes pointing to the l2tp and the ethernet1 interface.

Add a static route for your management space and make the gateway the same as the default route for the ethernet interface.

Then remove the default route for the ethernet interface.

This way you do not need to use mangle routes.

If any traffic comes in on the public interface it will leave via that interface with the default route all other management traffic will leave via the ether 1

Do you want all traffic to go through the L2TP VPN? Or just some?

Having done this, both all traffic and ‘some’ traffic, I first place I would look is the routing distance set on the routes.

For ‘all’ traffic, set a static route to the CHR to use the Ether1 gateway and remove the Ether1 0.0.0.0/0 route.