Hi everyone. This is my first post on the forum. I am really new to mikrotik. I am using pfsense on most of my projects.
I bought an hEX RB750Gr3 to experiment on one of my projects. I need it to have two wan interfaces one for Internet access and one for vpn access as a server.
The easiest vpn server I managed to create was openvpn server and its working fine. After I setup the Openvpn server and made it work I plugged the second wan interface with a greater distance so I can use it only for vpn access.
And thats where I am stuck. I can’t make a wan connection with greater distance than the primary to reply on vpn client. The port 1194 is filtered till I change the distance of the secondary wan (make it lower than the primary)
I have searched everywhere but I can’t find a solution.
Is this setup possible on mikrotik routeros??? I have done on pfsense a lot of times but can’t even get close on routerOS.
Sure it is possible, and the method is the same like the one you are used to from a naked Linux. The approach is called “policy routing”. To make sure that all outgoing packets belonging to a given connection use the same WAN interface through which the initial incoming packet of that connection came in from any remote address, you need to use connection tracking. See the concept here (start reading that post from the last paragraph which explains the relationship); to use it to deal with packets sent by the Tik itself, two points are important:
the translation of connection-mark to routing-mark has to be done in chain=output of /ip firewall mangle rather than in chain=prerouting,
the source address of the packet to be sent is chosen according to the out-interface selected by routing which takes place before the mangle rules in output chain are used. If a mangle rule in output chain assigns a routing-mark to an output packet, the packet is routed one more time, but its source address is not re-selected in this “routing adjustment” step. So you have to use an action=srcnat (or action=masquerade) rule on the WAN chosen by the marked route to align the packet’s source address with the address assigned to the WAN. Maybe setting pref-src on the marked route has the same effect but I’ve never tried.
Thank you very much for the lightning fast response!!!
I have tried “policy routing” but I was missing the information about the packets coming from the mikrotik itself and the chain that should be used for marking.
I 'll give it a try as soon as possibly. Thanks again!
I have read your post from the other thread and created some mangle rules. Now I think I am marking new connections and I am adding routing marks on the output chain as you said ( I can see it in log). The problem is that in the log (output-chain routing mark addition) I can see that the out-interface is the default.
From your example I have added:
add chain=prerouting connection-state=established,related connection-mark=no-mark action=accept
add chain=prerouting connection-state=established,related in-interface=secondary_WAN action=accept # I can’t understand why is this rule used, it’s the same with the above
add chain=output connection-mark=Cmark action=mark-routing new-routing-mark=Rmark passthrough=yes
add chain=prerouting connection-state=new in-interface=secondary_WAN action=mark-connection new-connection-mark=Cmark passthrough=yes
Are my rules ok?
I think my problem is in this section:
I am sure a have misunderstood. I would be grateful if you could give me an example for this action=srcnat (or action=masquerade) rule I have to use
I’d expect that’s exactly what I was talking about in the part about which you’ve written below that you hadn’t understood it. When a locally orignated packet is sent, the routing chooses the route using always the routing table main, which determines the out-interface. So at this step, the out-interface is always the same for all locally-originated packets sent towards the same remote address. Only after this step, if an action=mark-routing rule in chain=output of /ip firewall mangleeventually assigns a routing-mark, the route selection process is repeated one more time (on the packet flow diagram, this phase is called “routing adjustment”). But at the moment when the mangle output rule is matched and assigns the routing-mark, the out-interface is still the one chosen by the first pass through routing, hence that one is logged.
The first and second rules are not the same. The first one accepts mid-connection packets belonging to connections which didn’t get any connection-mark when established, regardless the packet direction; the second one accepts only download (WAN->LAN) mid-connection packets belonging to marked connections. This rule implements one of the possible ways to resolve the issue that the routes to connected subnets (LAN) are not present in other routing tables than main, so if they got marked with some routing-mark, they would get sent out the WAN again. In your particular application scenario, this rule is pointless, because the VPN server is the Mikrotik itself, so the packets belonging to the marked connections never need to be forwarded to LAN and packets for own addresses aren’t handled by any routing table.
Except for the presence of the pointless one, yes. The only remark is that I prefer the rules belonging to the same chain to be grouped together for better readability - RouterOS only cares for the rule order within each chain, but reading more complex configurations where rules in different chains of the same table are interleaved is complicated.
The rule is simple: /ip firewall nat
add chain=srcnat out-interface=WAN2 action=masquerade
It seems useless because the only packets sent out via WAN2 are those sent by the Mikrotik itself, but it is necessary for the reason explained above - the routing initially wants to send them via WAN1, but then the output mangle forces it to use the WAN2, but the source address has already been chosen, so it needs to be changed “manually”, using this rule, which is possible thanks to the fact that the NAT handling follows after the “routing adjustment”, as seen from the packet flow diagram too.
You are right as I can see from the Packet Flow Chains. If I understand correctly after the output chain the routing adjustment takes place and corrects the out-interface (according to the initiative marked connection and route maybe?). Then we go to postrouting chain. So I added a mangle postrouting rule which logs packets with the routing mark I have added so I can check if the out-interface is changed after the routing adjustment, but I am still getting the same results.
I though there is only one order (not per chain) that’s why I used this order. I reordered them.
I have created this NAT masquerade rule before I posted my previous post and it didn’t work, that why I asked for a hint/example on the rule.
By default I had a default masquerade rule that was using out-interface-list: WAN and when I disabled this rule I had no internet connection from the LAN. So I changed the default masquerade rule to out-interface:WAN1 instead of out-interface-list: WAN and internet connectivity was back again. Then I added your NAT masquerade rule but I didn’t see any traffic on this masquerade rule and OVPN port wasn’t responding from WAN2.
I didn’t see any traffic even when I disabled the default rule and left only with your rule.
How does masquerade works if I have two rules and the routing mark isn’t used anywhere in this rules (or any other distinction rules) ?
Show me the config export (see my signature, you likely don’t want to publish your public addresses). There must be a typo somewhere - the chain translating the connection mark to output interface must be broken. Your method of checking is correct, by the time the packet traverses mangle postrouting, the out-interface must already be updated.
fasttracking only handles forwarded packets so it is unrelated.
The missing link in the chain (in-interface → connection-mark → routing-mark for output packets → route via ppp-out1) is the default route in the routing table R_WAN1:
(since it is a PPP interface, the interface name can be used as gateway, hence there is no need to find the remote-address and update the route using an on-up script in /ppp profile).
That was the missing part. I could see the ppp-out1 route on winbox but it is created dynamically even after I delete it, so I didn’t think I had to create a new route.
My second mistake was that it was appearing blue on the list and I didn’t knew that this means inactive. The basic part that I was missing is that in order to have two active routes before adding mangle rules you have to mark the gateway with a routing mark, otherwise only one gateway can be active. I am missing the very basics…
If also find a way to mark the ppp-out1 route although it is dynamic:
Hello,
I am new to mikrotik atleast in mangle and marking. I am currently in the same situation. I need wan 1 for internet connectivity from lan and wan 2 for connecting vpn from outside. Don’t need load balancing but need redundancy if possible. Please could your post your configuration for me so than I can use it as reference to configure the same.
I was hoping to avoid mangling by using Route Rules instead.
However this seems to be one case where mangling is required.
The Op wants to use WAN1 for all users internet access, those behind the router AND all clients coming in on WAN2 via VPN.
Therefore if one use route rules to direct vpn client internet traffic to WAN1, then the return internet traffic will not go out WAN2 back to the clients but will attempt to go out WAN1 as per the route rule.
Hence we need two way control of such traffic and mangling is the only way to do this.
In RouterOS, there are three possible ways to assign a routing-mark value (which almost always means the same as a routing table name):
using VRF (so the routing-mark is assigned to the packet due to the fact that the packet has entered via an interface that is a member of that VRF)
using /ip route rule rows, which can only match on in-interface, src-address, dst-address, and an already assigned routing-mark
using /ip firewall mangle rows, which can match on all the packet fields and meta-fields like other firewall rules.
So as soon as you need to evaluate more than just very basic criteria in order to assign the proper routing-mark value, you have to use the mangle rules.