Community discussions

MikroTik App
 
DL7JP
just joined
Topic Author
Posts: 24
Joined: Sat Oct 19, 2013 4:14 pm

Routing marks / mangle

Wed Jan 27, 2021 1:44 am

Dear all,

I am trying to migrate our VPN-Server to v7 since wireguard is the best thing since sliced bread :-), but I am stuck with mangle/routing. The situation is this: The VPN-router has two interfaces with public IPs, one is exclusively for incoming VPN connections (“DFN” below, IP 1.2.3.4), the other is the default gateway to the Internet.

So, the router has to respond to incoming VPN connections via the same interface and forward other traffic via the default gateway. This did the trick in ROS 6:

/ip firewall mangle
add action=mark-routing chain=output new-routing-mark=viaDFN passthrough=yes src-address=1.2.3.4
add action=mark-routing chain=prerouting in-interface=DFN new-routing-mark=viaDFN passthrough=yes

/ip route add gateway=1.2.3.1 routing-mark=viaDFN

Now I am stuck migrate this to v7 – frankly, I fail to understand https://help.mikrotik.com/docs/display/ ... g+Examples. Can some kind soul give me a hint how to solve this? I already fail with adding the new routing mark…

Tnx, Joachim.
 
Sob
Forum Guru
Forum Guru
Posts: 6517
Joined: Mon Apr 20, 2009 9:11 pm

Re: Routing marks / mangle

Wed Jan 27, 2021 2:13 am

Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
DL7JP
just joined
Topic Author
Posts: 24
Joined: Sat Oct 19, 2013 4:14 pm

Re: Routing marks / mangle

Wed Jan 27, 2021 7:15 pm

Thanks a bunch! I am getting closer :-) ... here's the configuration now:
/routing table add name=viaDFN fib
/ip firewall mangle
add action=mark-routing chain=output new-routing-mark=viaDFN passthrough=yes src-address=1.2.3.4
add action=mark-routing chain=prerouting in-interface=DFN new-routing-mark=viaDFN passthrough=yes 
ip/route/add dst-address=0.0.0.0/0 gateway=1.2.3.1 routing-table=viaDFN
It works as intended for all incoming VPN connections of SSTP, L2TP, but not for the wiregard tunnel: While SSTP and L2TP traffic goes via the "normal" default route for 0.0.0.0/0 (set by a dhcp-client), traffic from the wireguard tunnel goes out via 1.2.3.4.
/ip/route/print 
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC, d - DHCP, y - COPY; + - ECMP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
  #        DST-ADDRESS      GATEWAY        D
     DAd+  0.0.0.0/0        4.5.6.1   1
  0   As+  0.0.0.0/0        1.2.3.1
     DAc   10.43.231.0/24   wireguard1     0
     DAc   4.5.6.7/24  bridge-local   0
     DAc   1.2.3.4/24  DFN            0
Any ideas?

It seems like the packet coming from wireguard are also marked viaDFN. I tried to mark the packets at the wireguard interface and the private IP range of wiregard with routing mark "main", but this does not seem to have an effect.
 
Sob
Forum Guru
Forum Guru
Posts: 6517
Joined: Mon Apr 20, 2009 9:11 pm

Re: Routing marks / mangle

Wed Jan 27, 2021 9:26 pm

I missed it in original post, but even v6 config wasn't correct. The mangle rule in prerouting is useless, all work is done by the one in output.

If you'd want to use "send it back to where it came from" approach, which would be useful if VPN server was accessible using both WANs, you'd use rule in prerouting to set connection mark (not routing mark) and then the rule in output would use this mark as condition, instead of src-address.

If VPN uses only the dedicated WAN, it's possible to avoid mangle rules completely and use routing rule. In v6 it would be:
/ip route rule
add src-address=1.2.3.4/32 action=lookup-only-in-table table=viaDFN
In v7 it was moved to /routing/rule and I didn't test it myself yet, but it should have same parameters.

As for WG, I seem to be a little lost in description.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
DL7JP
just joined
Topic Author
Posts: 24
Joined: Sat Oct 19, 2013 4:14 pm

Re: Routing marks / mangle

Wed Jan 27, 2021 10:54 pm

> I missed it in original post, but even v6 config wasn't correct. The mangle rule in prerouting is useless, all work is done by the one in output.

Thanks for the hint.

> As for WG, I seem to be a little lost in description.

The situation is this: The router has two Ethernet interfaces with public IPs, 1.2.3.4/24 (fixed) and 4.5.6.7/24 (via dhcp, varying IP). 1.2.3.4 is supposed to serve only incoming VPN connections (L2TP, SSTP and wireguard). VPN interfaces in the router have private IP ranges, and all traffic coming out of the VPN tunnels should be NATed via 4.5.6.7.

I think I managed to achieve this in v7 for the traffic coming via L2TP and SSTP tunnels, but not for wireguard: It seems that the mangle rules did not only mark the wireguard UDP packets arriving at DFN, but also the traffic coming from the wireguard interface in the router (packets in the tunnel). However, I am not really sure: I recently tried to reboot the router, but it did not come back. I will go into the office tomorrow, reset it and start from scratch with the routing rule you suggest.
 
Sob
Forum Guru
Forum Guru
Posts: 6517
Joined: Mon Apr 20, 2009 9:11 pm

Re: Routing marks / mangle

Thu Jan 28, 2021 12:57 am

I don't have any explanation why WG should differ from others. But if you suspect that marks may be inherited from tunnel traffic (outside) by tunneled traffic (inside), you can easily test it. Just add logging rule (action=log) in any chain, with any condition you need to check.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
DL7JP
just joined
Topic Author
Posts: 24
Joined: Sat Oct 19, 2013 4:14 pm

Re: Routing marks / mangle

Thu Jan 28, 2021 7:53 pm

The router is up again, it seems it did not like being powered both by a power supply and PoE...

I configured the router again, what you suggested worked, thanks a lot!
Here's the code for others with similar problems:
/routing table add name=viaDFN fib
/ip route add dst-address=0.0.0.0/0 gateway=1.2.3.4 routing-table=viaDFN
/routing rule add src-address=1.2.3.4/32 action=lookup-only-in-table table=viaDFN 
So replies to packets arriving at 1.2.3.4 are sent via the same interface and not via the default route in the main routing table.

I still struggling a bit with wireguard, it seems like I can have only one peer on each wireguard interface. Maybe that's worth another thread...
 
bergonz
just joined
Posts: 12
Joined: Fri Oct 16, 2015 3:01 pm

Re: Routing marks / mangle

Wed Feb 10, 2021 7:11 pm

I am not able to ping in a specific routing table, using 7.1beta2 in a chateau. Example:
/int bri add name=prova1
/ip addr add address=169.254.1.1/24 interface=prova1 
/routing/table/add name=prova1 fib
/ip/route/add dst-address=0.0.0.0/0 gateway=169.254.1.2@main routing-table=prova1

ping 8.8.8.8 routing-table=prova1

input does not match any value of routing-table
Looks like there's something wrong with the ping command:
ping 8.8.8.8 routing-table=main  

input does not match any value of routing-table
A workaround is to use an additional IP address as a source, adding a /routing/rule for that source, action=lookup-only-table and the intended table.

Regards,
Bergonz

Who is online

Users browsing this forum: No registered users and 7 guests