Hi,

What I'm trying to achieve: selectively send traffic over the VPN (e.g. https://wtfismyip.com/). I've read and followed instructions from e.g. viewtopic.php?f=23&t=169273.

Problem: I'm having trouble with IPsec if I use mode-config connection-mark. Connections get marked correctly, but nothing goes through the VPN and instead uses the same route as usual.

The VPN connection is established correctly and works, because I see it in Active Peers and Installed SAs. Also, if I leave out connection-mark in mode-config (to send ALL traffic from src-address-list through the VPN), that works.

When I add connection-mark to config-mode, I see the dynamic srcnat rule in Firewall > NAT. Its counter always stays at zero, even though the counters in the Mangle rule goes up. I can even see the connection in Firewall > Connections.

How can I get the marked connections to hit the dynamic srcnat rule and go through the VPN? Thanks!


PS: I would've liked to try using routing-mark instead, but the IKE2 connection is dynamic and as such not selectable as a gateway in routes.
PPS: Yes, I have read https://help.mikrotik.com/docs/display/ ... n+RouterOS.

I never saw a certificate ditrction there: certificate=lets-encrypt-r3.der_0

Put the cerificate in the cerificate store and it will be found. If not found then router will complain.

Roting won't work how Mikrotik implemented it and only if the connection mark matches dynamic ones in NAT.

The behaviour you describe is weird, what is the RouterOS version you use?

Strictly speaking it is not an IPsec issue - the generated IPsec policy can only see packets whose headers match the policy, so it is the fact that the action=src-nat rule doesn't match on the connection marked traffic that breaks it, as the unchanged source address of the packets doesn't match the policy's src-address.

So place a rule chain=srcnat action=log connection-mark=vpn-uk as the first static one in that chain in /ip firewall nat, and see what it logs.

And post the complete configuration except the sensitive data (see my automatic signature below for a hint). The issue is often in the part of configuration you assume to be irrelevant.

Also, post the output of /ip firewall nat print chain=srcnat (edit the to-addresses of course).

Regarding use of routing-mark to mark traffic to be sent via an IPsec VPN, that's not possible as matching of packet headers to traffic selectors of IPsec policies takes place as the last step of packet processing, long after the routing takes place.

Put the cerificate in the cerificate store and it will be found. If not found then router will complain.

You are correct, I removed it from that config field and it was able to find it in the store and re-establish the connection. Unfortunately doesn't fix my srcnat issue, but thanks for making my config a little simpler and future proof!

The behaviour you describe is weird, what is the RouterOS version you use?

v6.49 stable

Strictly speaking it is not an IPsec issue - the generated IPsec policy can only see packets whose headers match the policy, so it is the fact that the action=src-nat rule doesn't match on the connection marked traffic that breaks it, as the unchanged source address of the packets doesn't match the policy's src-address.

I agree and suspect a simple config mistake on my part..

So place a rule chain=srcnat action=log connection-mark=vpn-uk as the first static one in that chain in /ip firewall nat, and see what it logs.

Hehe nice, this is something I had tried before posting. I put that rule at the top of the NAT, and its counter remained at 0. I had also added an action=log connection-mark=vpn-uk to the Filter Rules and that one has its counters increasing.

And post the complete configuration except the sensitive data (see my automatic signature below for a hint). The issue is often in the part of configuration you assume to be irrelevant.

So while I was writing this reply and before posting my complete config, I took a hundredth look at my firewall rules and discovered the problem. The vpn-uk mark rule was passthrough, and the connection mark was being overwritten later on (for QOS) by another rule. DOH! Strange, because I know at some point it wasn't passthrough, and therefore the mark could not have been overwritten, so I guess in trying many (many!!!) different things in trying to find a solution, I also fixed another error.

To fix the issue, I kept the passthrough and added connection-mark=no-mark the the offending rule.

BTW, what is the best practice? 1) rules are in increasing order of importance, and everything is passthrough VS 2) rules are in decreasing order of importance and not passthrough whenever they can be. I'm thinking there might be a marginal gain in perf with the second option, since less rules need to be checked.

Thank you taking the time, really appreciate it!

in my case i can't see ESP in the connection tracking , not sure why

Strange, because I know at some point it wasn't passthrough, and therefore the mark could not have been overwritten, so I guess in trying many (many!!!) different things in trying to find a solution, I also fixed another error.

A rule with passthrough=no, or any other rule providing a "final verdict", only terminates handling of the packet in the current chain of the firewall. So if the action=mark-connection rule for QoS was in a later chain than prerouting, e.g. in forward, it did overwrite the connection-mark even when the rule in prerouting had passthrough=no. But since in the forward chain, mangle takes place before filter, and you could still see the vpn-uk value to be in place as the packets were handled by filter, your QoS-related connection marking must have had taken place in postrouting.

BTW, what is the best practice?

1. rules are in increasing order of importance, and everything is passthrough VS
2. rules are in decreasing order of importance and not passthrough whenever they can be.

I'm thinking there might be a marginal gain in perf with the second option, since less rules need to be checked.

Correct, it is best to optimize the rules in order that each packet had to pass as few as possible of them. So rules that handle most of the traffic should be put first.

In the context of connection-marking, I usually to do the following:

chain=prerouting connection-mark=no-mark action=jump jump-target=connmark-pre
chain=prerouting connection-mark=cm1 action=mark-routing new-routing-mark=rm1 passthrough=no
...
chain=prerouting connection-mark=cmN action=mark-routing new-routing-mark=rmN

chain=connmark-pre ...some match conditions... action=mark-connection new-connection=mark=cm1 passthrough=yes
chain=connmark-pre connection-mark=no-mark ...some match conditions... action=mark-connection new-connection=mark=cm2 passthrough=yes
...
chain=connmark-pre connection-mark=no-mark ...some match conditions... action=mark-connection new-connection=mark=cmN passthrough=yes
chain=connmark-pre action=mark-connection new-connection-mark=use-main passthrough=yes

So only the initial packet of each connecton ever makes it to chain connmark-pre, hence the order of rules within that chain is not really significant for throughput, so you can arrange them in the "exception from exception" order even if the first rules handle the most rare connections.

In chain prerouting, arrange the action=mark-routing rules strictly by volume of traffic they handle, and don't hesitate to re-order them if their statistics shows that the volume is different from what you've initially expected. It may even make sense to put an action=accept connection-mark=use-main rule right next to the action=jump one if majority of traffic keeps using the main routing table.

in my case i can't see ESP in the connection tracking , not sure why

Two possible explanations come to my mind:

• there is NAT at at least one end and therefore the ESP gets encapsulated into UDP
• you use protocol=esp in the search condition whilst the RouterOS name is ipsec-esp.

fala puno

maybe is not good idea for me to jump here. Because you have replayed on my one. This router is behind NAT, and im using in only for VPN

same as here

maybe is not good idea for me to jump here. Because you have replayed on my one.

Well, the OP's issue has been resolved and I've commented on it too, so hopefully your piggy-back is not so disturbing.

This router is behind NAT, and im using in only for VPN

The ipsec-protocol as a parameter of policy can be ah or esp. The protocol as a parameter in /ip firewall can be ipsec-ah or ipsec-esp. As you use matching using regexp (~"esp"), you would see the connection in the firewall if it was there.

Since there is NAT, there is nothing to think about, but you can use /ip ipsec installed-sa print, you should see src-address=a.a.a.a:ppp, meaning that the ESP (which doesn notion of ports) is encapsulated into UDP. If it was bare ESP, the ":ppp" part would be missing in src-address and dst-address. The firewall doesn't look into UDP payload to find out whether it is not ESP by chance.

that makes lot of sense.

Thanks a lot