PCC, VPN and routing rules (yes, again!)

RouterOS General
1

Hi,
I have load balancing configuration with PCC and L2TP server which sounds like “a classic issue with firewall mangling”, but actually that part is working fine. VPN client can reach internet and also internal hosts so this looks OK.

But I have some hosts on intranet that must use WAN1 gateway if link is working and only switch to WAN2 when WAN1 is down. I control that with routing rules. But when a host matches a routing rule, it becomes inaccessible for a VPN client. Please help understand why is that and how to fix it.

Relevant configuration parts are below.
In the configuration below, 192.168.100.10 must use WAN1 when WAN1 is available.
As soon as routing rule becomes active, VPN client with IP address 10.23.0.100 cannot get to intranet host with IP address 192.168.100.10.

Thanks,
Ivars

[admin@gw] > /export terse

apr/27/2023 20:46:42 by RouterOS 7.8

/ip ipsec profile add dh-group=modp4096,modp2048,modp1024 enc-algorithm=aes-256,aes-128 name=l2tp_profile
/ip ipsec proposal add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-256-gcm,aes-192-cbc,aes-192-gcm,aes-128-cbc,aes-128-gcm name=l2tp

/ip pool add comment=“L2TP pool for VPN clients” name=l2tp_pool ranges=10.23.0.2-10.23.0.100

/routing table add fib name=to_WAN1
/routing table add fib name=to_WAN2
/interface l2tp-server server set authentication=mschap2 default-profile=l2tp_profile enabled=yes use-ipsec=required

/ip address add address=WAN1_gw/24 interface=ether1 network=WAN1_net
/ip address add address=192.168.100.1/24 interface=ether6 network=192.168.100.0
/ip address add address=WAN2_gw/24 interface=ether2 network=WAN2_net

/ip firewall filter add action=accept chain=input port=1723 protocol=tcp
/ip firewall filter add action=accept chain=input comment=“Allow VPN” protocol=gre
/ip firewall filter add action=accept chain=input comment=“L2TP UDP” dst-port=1701,500,4500 in-interface=ether1 protocol=udp
/ip firewall filter add action=accept chain=input comment=“L2TP IPSec” in-interface=ether1 protocol=ipsec-esp
/ip firewall mangle add action=accept chain=prerouting dst-address=WAN1_net/24 in-interface=ether6
/ip firewall mangle add action=accept chain=prerouting dst-address=WAN2_net/24 in-interface=ether6
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=ether1 new-connection-mark=WAN1_link passthrough=yes
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=ether2 new-connection-mark=WAN2_link passthrough=yes
/ip firewall mangle add action=mark-routing chain=prerouting connection-mark=WAN1_link in-interface=ether6 new-routing-mark=to_WAN1 passthrough=yes
/ip firewall mangle add action=mark-routing chain=prerouting connection-mark=WAN2_link in-interface=ether6 new-routing-mark=to_WAN2 passthrough=yes
/ip firewall mangle add action=mark-routing chain=output connection-mark=WAN1_link new-routing-mark=to_WAN1 passthrough=yes
/ip firewall mangle add action=mark-routing chain=output connection-mark=WAN2_link new-routing-mark=to_WAN2 passthrough=yes
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=ether6 new-connection-mark=to_WAN1 passthrough=yes per-connection-classifier=both-addresses:5/0
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=ether6 new-connection-mark=to_WAN2 passthrough=yes per-connection-classifier=both-addresses:5/1
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=ether6 new-connection-mark=to_WAN2 passthrough=yes per-connection-classifier=both-addresses:5/2
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=ether6 new-connection-mark=to_WAN2 passthrough=yes per-connection-classifier=both-addresses:5/3
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=ether6 new-connection-mark=to_WAN2 passthrough=yes per-connection-classifier=both-addresses:5/4
/ip firewall nat add action=masquerade chain=srcnat out-interface=ether1
/ip firewall nat add action=masquerade chain=srcnat out-interface=ether2
/ip route add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=WAN1_gw pref-src=“” routing-table=main suppress-hw-offload=no
/ip route add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=WAN2_gw pref-src=“” routing-table=main suppress-hw-offload=no
/ip route add dst-address=1.1.1.1 gateway=WAN1_gw scope=10
/ip route add dst-address=8.8.8.8 gateway=WAN1_gw scope=10
/ip route add dst-address=8.8.4.4 gateway=WAN2_gw scope=10
/ip route add dst-address=9.9.9.9 gateway=WAN2_gw scope=10
/ip route add check-gateway=ping dst-address=10.10.10.1 gateway=1.1.1.1 scope=10 target-scope=11
/ip route add check-gateway=ping dst-address=10.10.10.1 gateway=8.8.8.8 scope=10 target-scope=11
/ip route add check-gateway=ping dst-address=10.20.20.2 gateway=8.8.4.4 scope=10 target-scope=11
/ip route add check-gateway=ping dst-address=10.20.20.2 gateway=9.9.9.9 scope=10 target-scope=11
/ip route add distance=1 gateway=10.10.10.1 routing-table=to_WAN1 target-scope=12
/ip route add distance=2 gateway=10.20.20.2 routing-table=to_WAN1 target-scope=12
/ip route add distance=1 gateway=10.20.20.2 routing-table=to_WAN2 target-scope=12
/ip route add distance=2 gateway=10.10.10.1 routing-table=to_WAN2 target-scope=12
/ppp secret add name=support profile=l2tp_profile
/routing rule add action=lookup disabled=no src-address=192.168.100.10 table=to_WAN1

2

I assume that VPN clients are not in the table “to_WAN1”, so it is obvious that any packet going from 192.168.100.10 will not be ever forwarded to any VPN client.

3

Do I need another routing table that will handle VPN client routing to intranet?

I tried to mark packets with
/ip firewall mangle add action=mark-routing chain=prerouting connection-mark=WAN1_link src-address=10.23.0.0/24 new-routing-mark=to_WAN1 passthrough=yes

But that did not work and is apparently wrong idea.

4

hello ivarrs

But when a host matches a routing rule, it becomes inaccessible for a VPN client. Please help understand why is that and how to fix it.

from your description,
maybe your routing tables were okay - but you need to know which wan interface your remote vpn client connected to, as well.

you can’t just move your server routing - the fail over mechanism - without thinking how will remote vpn client and your servers can reach each other after the fail over happened.

hope this helps. and good luck :+1:t2:

5

Thanks for helping me.
I am not so worried what is going to happen with VPN clients if interface through which they connect, will fail.
Router is not redundant and VPN failover is not the goal.
But under normal conditions VPN clients should be able to talk to all intranet hosts regardless to which routing table these hosts are assigned.
I tried to explain what I attempted above, but so far no success.

6

When you say hosts, need wan1 regardless (no pcc) how many? A whole subnet?
Do you mean users
OR
servers ?

Do not understand which direction you are talking about with regards to VPN??
Do you mean the users who need to go out wan1 are also going out a VPN, ???
OR
Do you mean that the hosts are servers which remote vpn clients must reach???

(if so where are vpn hosts coming from ? Type of VPN ?)

7

I added another routing rule on top of others and solved the issue.

/routing rule add action=lookup comment=“L2TP clients which otherwise can’t see hosts in lower routes” disabled=no dst-address=10.23.0.0/24 table=main