Community discussions

MikroTik App
 
User avatar
eworm
Forum Guru
Forum Guru
Topic Author
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

blackhole/unreachable with IPSec policies

Sat Jul 13, 2019 12:13 pm

Hello everybody,

with my current VPN provider I use l2tp/IPSec, which works with an interface. I add routing marks, then add a route for these marks to my interface. A second route makes sure no traffic is routed when the interface is down:
/ ip route add distance=1 gateway=l2tp-pia routing-mark=via-vpn
/ ip route add distance=10 routing-mark=via-vpn type=unreachable
Now migrating to NordVPN with just IPSec/IKEv2 verything works fine, including new connection-mark option for mode-config from 6.46beta9. I am missing one detail, though: If the peer is down all traffic is routed to my ISP without VPN. What's the best way to have the functionality of blackhole/unreachable route with IPSec policies?
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: blackhole/unreachable with IPSec policies

Sat Jul 13, 2019 12:46 pm

I am using a in rules that drops forwarded traffic that has the connection mark and goes out through the WAN. I am using the specific ports now instead of connection mark.

I am using this this for L2TP/IPSEC but maybe this can be used for IKEv2 to.

Sindy made a blackhole by using an extra bridge.

Then:
/ ip route add distance=1 connection-mark=via-vpn type=unreachable
Last edited by msatter on Sat Jul 13, 2019 12:52 pm, edited 1 time in total.
 
User avatar
eworm
Forum Guru
Forum Guru
Topic Author
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: blackhole/unreachable with IPSec policies

Sat Jul 13, 2019 12:50 pm

With l2tp this is quite easy as routing goes to different interfaces. With IPSec policies things work different.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: blackhole/unreachable with IPSec policies

Sat Jul 13, 2019 12:55 pm

You want to stop traffic what is not caught by IPSEC and so it is normal traffic.
 
User avatar
eworm
Forum Guru
Forum Guru
Topic Author
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: blackhole/unreachable with IPSec policies

Sat Jul 13, 2019 1:51 pm

Yes. But I can not decide by out interface as that does not differ with policies.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: blackhole/unreachable with IPSec policies

Sat Jul 13, 2019 2:09 pm

IKEv2 is not having it's own interface and encrypted traffic uses WAN. Traffic (not encrypted) marked for IKEv2 has so nothing lost in routing so when detected be indicated as unreachable.
Last edited by msatter on Sat Jul 13, 2019 2:13 pm, edited 1 time in total.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Sat Jul 13, 2019 2:10 pm

The extra bridge with no member ports and no IP address assigned is used as a gateway of routes to all destinations to which the traffic should only get via the IPsec SA.
The point is that IPsec policies' traffic selectors choose the packets for interception on their way to the interface, so any route which doesn't let them get out via an interface will also prevent them from being intercepted by the policy.
And although it normally doesn't make much sense to use a point-to-multipoint interface as a gateway, there are cases where it does, so it is a permitted configuration which is likely to stay.
 
User avatar
eworm
Forum Guru
Forum Guru
Topic Author
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: blackhole/unreachable with IPSec policies

Sun Jul 14, 2019 12:00 am

I added this rule as a workaround... It catches the packets if the dynamic rule by mode-config is not present.
/ip firewall nat add action=src-nat chain=srcnat connection-mark=via-vpn to-addresses=127.0.0.1
However it is kind of blackhole only, there's no way to make the client receive unreachable messages. Also packets are sent to the default gateway, with unroutable address 127.0.0.1. This may bring some undesired side effects.

I could think of double-NAT with a pair of ipip Interfaces... But that makes the configuration a lot more complicated compared with what I have now.

sindy, I did not get the idea of your thoughts. If I route the packets to a bridge with no ports and no addresses I have a blackhole. But there is no way for the packets to be encrypted and sent the right way, no? Can you explain in more detail and possibly with example configuration?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Sun Jul 14, 2019 9:06 am

sindy, I did not get the idea of your thoughts. If I route the packets to a bridge with no ports and no addresses I have a blackhole. But there is no way for the packets to be encrypted and sent the right way, no? Can you explain in more detail and possibly with example configuration?
The order of actions is
  1. use routing to find the outgoing interface
  2. execute the postrouting chain of the firewall (including srcnat)
  3. check a match to IPsec policy and send the packet via the policy's SA if it matches
  4. send the packet out the interface chosen in step 1 if it didn't match any IPsec policy
So the difference between a type=blackhole route and a bridge with no ports is that a blackhole route drops the packet already at step 1, whereas a "blackhole bridge" only drops it if it didn't match any IPsec policy.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: blackhole/unreachable with IPSec policies

Sun Jul 14, 2019 11:32 am

I added this rule as a workaround... It catches the packets if the dynamic rule by mode-config is not present.
/ip firewall nat add action=src-nat chain=srcnat connection-mark=via-vpn to-addresses=127.0.0.1
However it is kind of blackhole only, there's no way to make the client receive unreachable messages. Also packets are sent to the default gateway, with unroutable address 127.0.0.1. This may bring some undesired side effects.
Mine would be:
/ip firewall filter add action=reject chain=forward connection-mark=via-vpn out-interface-list=WAN reject-with=icmp-host-unreachable
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Sun Jul 14, 2019 10:23 pm

@msatter, /ip firewall filter rules act before before policy matching, so your rule will drop the packets also if the IPsec policy is active. You also cannot add an ipsec-policy=out,none condition into the /ip firewall filter rule for the purpose, because before the src-nat happens after filter rules have already acted, all transit traffic matches that condition so again everything would be dropped before it could get src-nated and subsequently matched by the policy.

@eworm's solution with an action=src-nat rule, which is shadowed by the dynamically added one while the IKEv2 connection is up, can be improved this way in terms that the packets not intercepted by the ipsec policy won't make it even to the default gateway, but I can see no advantage as compared to my "blackhole bridge" way, and I'm afraid that having /interface bridge filter rules defined has some impact even on operation of bridges to which those rules are unrelated.

However, I could not find any way how to provide the icmp feedback (administratively prohibited, unreachable etc.) except by using the ipip tunnel to self instead of the "blackhole bridge", and using policy routing to send anything that comes in via the "far" end of that tunnel to a marked route with type=unreachable or prohibit. The question is whether it is worth the effort - for me it wasn't, so I didn't test it and thus I may be missing some caveats. Plus when the VPN connection drops for a while and then re-establishes, silent drops don't break the established TCP sessions whereas icmp feedback packets likely would; this was another reason for me not to pay attention to the possibility to send them.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: blackhole/unreachable with IPSec policies

Sun Jul 14, 2019 10:53 pm

I do not agree because forwarded traffic is only dropped if it on his way to the WAN while it is tagged to go through the IKEv2 connection.

In the NAT itself the first split is made by only NAT traffic to the WAN the is not connection marked.

So if traffic is on it's way through Mangle and marked and the NAT IKEv2 is not already inserted or is removed it will not find NAT to the Wan. The filter rule is there to be absolute sure noting goes out the Wan that not meant to be and so being a back-stop.

If you don't use mode-config (source address/connection marking) traffic can escape because it is not marked or source bound. If possible the omitting the NAT to Wan is an option.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: blackhole/unreachable with IPSec policies

Sun Jul 14, 2019 11:16 pm

The next step is when it hit the IKEv2 Nat rule and the connection is not there anymore what happens then?
It will head for the WAN which is transfering anything not specific caught by other routing rules.

Outgoing encrypted traffic will fall dead because the receiving IKEv2 server is not there anymore.
Plain traffic that I see is that with other IPSEC connections, that I get traffic not for me but for the previous user of that dynamic IP address.
The VPN provider should block these cross overs, it is leaking traffic.

Statefull filtering will stop that but if you want you can see the content if you accept it. (think peer to peer sharing)
 
User avatar
eworm
Forum Guru
Forum Guru
Topic Author
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: blackhole/unreachable with IPSec policies

Mon Jul 15, 2019 12:46 am

The order of actions is
  1. use routing to find the outgoing interface
  2. execute the postrouting chain of the firewall (including srcnat)
  3. check a match to IPsec policy and send the packet via the policy's SA if it matches
  4. send the packet out the interface chosen in step 1 if it didn't match any IPsec policy
So the difference between a type=blackhole route and a bridge with no ports is that a blackhole route drops the packet already at step 1, whereas a "blackhole bridge" only drops it if it didn't match any IPsec policy.
Well, 1. is just routing to the default gateway, no? Then 2. does the src-nat with dynamic address from mode-config, 3. is ipsec encapsulation after firewall. At this point we do not have any way to manipulate the out interface. So how should 4. work? Oder did I misunderstood 1.?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Mon Jul 15, 2019 9:50 am

@msatter, I'll come back to your posts later, first the OP. But maybe the following is an answer to your posts too?

@eworm,
Oder did I misunderstood 1.?
Either you did, or I've misunderstood your goal.

My understanding of your goal is that you want to be sure that those pakets, which should be sent via the VPN, will under no circumstances get to the destination via any other path if the VPN connection fails. The static srcnat rule you've posted above supports that understanding.

Is my understanding correct? I'll only continue explaining if you confirm that.
 
User avatar
eworm
Forum Guru
Forum Guru
Topic Author
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: blackhole/unreachable with IPSec policies

Mon Jul 15, 2019 10:55 am

@eworm,
Oder did I misunderstood 1.?
Either you did, or I've misunderstood your goal.

My understanding of your goal is that you want to be sure that those pakets, which should be sent via the VPN, will under no circumstances get to the destination via any other path if the VPN connection fails. The static srcnat rule you've posted above supports that understanding.

Is my understanding correct? I'll only continue explaining if you confirm that.
Yes, correctly.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies  [SOLVED]

Mon Jul 15, 2019 1:05 pm

OK, so I continue.

What happens with a packet if it is not intercepted by an IPsec policy is determined before the match to IPsec policy's traffic selector is attempted. There is no L3 packet processing layer after the IPsec policy matching which could take any action if no policy matches the packet. All routing and all evaluation of routing-mark, connection-mark etc. takes place before IPsec policy matching as this diagram shows.

Vice versa, if the packet is not routed towards any interface because it matches a blackhole, prohibit or unreachable route, it can never be matched by any IPsec policy (nor even src-nated).

In case of IKEv2 with mode-config and the src-nat rule it creates dynamically, there is additionally the src-nat action in step 2 which is only taken if that IKEv2 connection is active.

But already this is a caveat: only the initial packet of each tracked connection is actually treated by the srcnat chain of /ip firewall nat, whereas the src-nat action on the subsequent outbound packets, as well as the "un-src-nat" action on the inbound packets of the same connection, is done by the connection tracking module alone. So all packets, which belong to connections which have been src-nated to the IP assigned by the VPN server by the dynamically added src-nat rule while the VPN was up, will continue to be src-nated by the connection tracking module even after the VPN connection breaks. But as no IPsec policy will matche them while the VPN will be down, they will be sent out the gateway interface chosen by routing, except that with a wrong source IP address. How far such packet can get depends on the anti-spoofing policies applied along the path, and there is unfortunately no guarantee that your ISP will drop them, so they may even make it to the destination - either with the source address being the one you got from the VPN server when the IKEv2 connection came up, or with your public IP if you don't have a public IP on the Mikrotik itself but on ISP's routing modem.

When your client host initiates a new connection while the VPN has already disconnected, the dynamically created src-nat rule is not present in the srcnat chain, so also in the postrouting chain, the initial packet is treated as any other one.

So:
  • to make sure that the packets can be matched by an IPsec policy, they must be routed out via some interface,
  • to make sure that they won't leak if they are not matched by an IPsec policy (because the VPN is down), they must be routed out via an interface which actually sends them nowhere.
These two requirements taken together mean that packets belonging to this category must have their own route in step 1 (with the blackhole bridge as a gateway interface), not the common default route which usually uses the WAN as its gateway.

But again, it is just one way how to do it. Your approach, with the "emergency" src-nat rule changing the source IP of those packets which otherwise the dynamically added src-nat rule would process, works as well, except that if used without additional measures, it only prevents the leaked packets from carrying your WAN IP, which may not be sufficient as said above - if your ISP box does NAT, it is likely not to care about the source IP of the packet you've sent to it, so the leaked packets will be sent to the original destination with your normal public IP. So to make that approach fulfil the real goal, you have to complement it with the bridge filter setup I've linked to above, which is the last place where you can stop packets with undesired src-address from being actually sent. However, there are complications associated to that step:
  • you cannot insert the bridge filter into the path if the WAN interface is an L3 tunnel (such as PPPoE),
  • if also the WAN interface address is dynamically assigned, the bridge filter rule must work with a subnet or more than one may be necessary to let through the traffic which needs to be let through and drop the leaks.
 
User avatar
eworm
Forum Guru
Forum Guru
Topic Author
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: blackhole/unreachable with IPSec policies

Mon Jul 15, 2019 3:38 pm

Ah, got it! :D :lol:

My false assumption was that I thought...
  • Routing with type=blackhole is the same as routing to an interface with no addresses. Of course it is not.
And even more important that I thought...
  • Routing decision is done earlier in flow for unencrypted packet. It is not, or better: Looks like routing decision is reconsidered after IPSec encapsulation.
So yes, this is the simplest and most straight forward solution. The important configuration bits look like this:
# create a bridge with no ports and no addresses
/interface bridge add name=blackhole

# route the vpn traffic to this interface
/ip route add distance=1 gateway=blackhole routing-mark=via-vpn
Well, that's it, no? Of course you need to add routing-mark (for route above) and connection-mark (for dynamic src-nat from mode-config) in firewall mangle.

BTW, previously I used an unreachable route. After sindy's comments I reconsidered and I am happy with blackhole now. Probably it's a good idea if connections do not break if vpn link is down for just a short moment.

sindy, I owe you a beer (or two or some more... ) Thanks a lot for help and detailed explanation!
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Mon Jul 15, 2019 4:14 pm

Looks like routing decision is reconsidered after IPSec encapsulation.
Well... the IPsec transport packet carrying the encrypted original packet is actually a brand new one locally originated by the Mikrotik, so it is not a reconsidered routing decision, it is merely an independent routing decision.

Well, that's it, no? Of course you need to add routing-mark (for route above) and connection-mark (for dynamic src-nat from mode-config) in firewall mangle.
Yes.

Probably it's a good idea if connections do not break if vpn link is down for just a short moment.
Unfortunately it is probably useless in your particular scenario because if I get the behaviour right, you are not guaranteed to get the same IP address after re-connection, no matter how long the disconnection took. In my scenarios where the VPN server is the same one all the time and each user gets the same address all the time it is another story.

I owe you a beer (or two or some more...)
Thanks, I'll let you know once I'll be roaming nearby :) But the probability seems to be low for next few months.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Mon Jul 15, 2019 4:23 pm

@msatter, did my detailed post #17 explain what I had in mind when saying that your rule suggested in post #10 will drop the packets regardless whether they would be finally intercepted by an IPsec policy? I still have a feeling that the mutual misunderstanding may come from the fact that you use a different overall concept which I didn't get, and that rule is just a part of it.
 
User avatar
eworm
Forum Guru
Forum Guru
Topic Author
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: blackhole/unreachable with IPSec policies

Mon Jul 15, 2019 5:35 pm

@msatter, did my detailed post #17 explain what I had in mind when saying that your rule suggested in post #10 will drop the packets regardless whether they would be finally intercepted by an IPsec policy? I still have a feeling that the mutual misunderstanding may come from the fact that you use a different overall concept which I didn't get, and that rule is just a part of it.
He is using L2TP/IPSEC and has an interface. :wink:
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Mon Jul 15, 2019 5:58 pm

He is using L2TP/IPSEC and has an interface. :wink:
Nope, he has a very clever arrangement where one machine provides an IKEv2 connection and another machine chooses which traffic will use the VPN and which will use the direct WAN, which he uses to beat the trouble to do that on a single machine (as you cannot tell the policy what to intercept and what to ignore using any other means than src-address whilst the src-address keeps changing).
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: blackhole/unreachable with IPSec policies

Mon Jul 15, 2019 7:39 pm

I have to have a good look at it when I have access to Winbox and my RouterOS in front of me. Seeing what is catching the first and tailing packets. So I have to come back on this.

I am using L2TP/IPSEC on the inner box and the outer (GW) is transparant for that. IKEv2 is routed on the inner bock and is then fasttracked. The outer box does the IKEv2 stuff which can't be fasttracked.

The advantages is more speed due to double processing power and lower temperatures in the inner box. I don't have a 4011 which can archive even higher encrypted transfer rates.
 
icsterm
Frequent Visitor
Frequent Visitor
Posts: 58
Joined: Sun Mar 11, 2018 11:11 pm

Re: blackhole/unreachable with IPSec policies

Fri Jan 03, 2020 3:47 pm

Can someone post the config with both srcnat and mangle mark-route commands for the bridge blackhole scenario?
I've successfully implemented the src-nat to 127.0.0.1, which drops packets once the dynamic mode-config src-nat rule dissapears once the vpn is down, but if I try using src-nat to let's say 192.168.255.255, I can't make it work. The mangle to catch this traffic originating from the new source "192.168.255.255" doesn't work because the src-nat takes place in the postrouting chain and no further routing manipulation can be done there.
I've created:

-blackhole bridge with no ip addresses
- 0.0.0.0/0 route with blackhole bridge as gateway and routing mark 'blackhole'
- mangle rule for source '192.168.255.255' and new routing mark 'blackhole'.

No packets are catched by moving the mangle rule in all chains.

The src-nat does it's job after the VPN is down, can be seen in the fw connections:
srcnat.JPG

My ISP does NAT and that makes my packets escape on the internet because they don't have source ip filters on their router.

Isn't there any way to drop packets in the ipsec policy roules if the peer is 'dead' ? That would be so much easier.
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Fri Jan 03, 2020 4:14 pm

Can someone post the config with both srcnat and mangle mark-route commands for the bridge blackhole scenario?
...
I've created:

- blackhole bridge with no ip addresses
- 0.0.0.0/0 route with blackhole bridge as gateway and routing mark 'blackhole'
- mangle rule for source '192.168.255.255' and new routing mark 'blackhole'.

No packets are catched by moving the mangle rule in all chains.

Isn't there any way to drop packets in the ipsec policy roules if the peer is 'dead' ? That would be so much easier.
I'm not sure I understand you properly. The very idea of a blackhole bridge is that if the IPsec peer is dead, the packets are sent to the blackhole bridge.

The IPsec traffic selectors themselves ignore any routing marks; the way how connection-mark is used to affect whether a packet will be sent via IPsec or not is by means of the src-nat, changing the source address of packets bearing the right connection-mark to the one matched by the IPsec policy's traffic selector.

So the mangle rule assigning the routing-mark activating the blackhole route must match on the connection-mark if you use it the above way, or it must match on the actual src-address, i.e. the one before the src-nat.
 
icsterm
Frequent Visitor
Frequent Visitor
Posts: 58
Joined: Sun Mar 11, 2018 11:11 pm

Re: blackhole/unreachable with IPSec policies

Fri Jan 03, 2020 5:37 pm

So the mangle rule assigning the routing-mark activating the blackhole route must match on the connection-mark if you use it the above way, or it must match on the actual src-address, i.e. the one before the src-nat.
Damn, my issue is that I also have a separate PPTP tunnel, and I wanted once the IKEv2 tunnel goes down, not ALL traffic be sent to blackhole bridge, but all except the traffic to the PPTP tunnel.
Some adjustments to my NAT rules and a separate connection-mark for the PPTP traffic should fix it.

Thanks for taking your time answering.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Fri Jan 03, 2020 6:10 pm

my issue is that I also have a separate PPTP tunnel, and I wanted once the IKEv2 tunnel goes down, not ALL traffic be sent to blackhole bridge, but all except the traffic to the PPTP tunnel.
Some adjustments to my NAT rules and a separate connection-mark for the PPTP traffic should fix it.
I don't think it actually changes much if you use mode-config configured with an address-list and/or connection-mark.

Whatever is routed to the PPTP tunnel will be routed through it even if a less specific route for the same traffic exists via another gateway, because more specific route (with longer destination prefix) always wins (within the same routing table). IPsec policy eventually intercepts the traffic after the regular routing has been done, so it doesn't matter whether the regular route points to the PPTP or to the blackhole bridge.

Since you need the src-nat handling to make the traffic visible to the IPsec traffic selector, you just add the static src-nat rule for the PPTP if you need one, and let the mode-config install the dynamic src-nat rule to the beginning of the chain when the peer goes up. So while the peer is up, the static NAT rule for the PPTP is shadowed by the dynamic one making the traffic visible for IPsec traffic selector.

If you actually had in mind to exclude the PPTP traffic from IPsec handling even if the IPsec peer is up, it is even simpler as you've suggested - a different connection-mark for PPTP traffic will make it invisible for the dynamic src-nat rule.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: blackhole/unreachable with IPSec policies

Wed Apr 22, 2020 11:10 am

I am revisiting this tread again while busy to create a Kill-Switch for IKEv2. Till now I blackholed traffic by using a src-nat to 127.0.0.1 and noticed a few day ago that the traffic was reaching the next router in my network. I put a rule in that router in RAW to drop any traffic coming from 127.0.0.1 and that did the job.
But then that second router has the same rule in NAT but luckily despite that there a lot of 127.0.0.1 out there it does not com far.

I have now also put the solution by Sindy to see if that is better. Using a Bridge with no ports and a blackhole (not unreachable) in Route. So now Torch the Bridge Black hole if there is traffic coming in.....should I see traffic if the IKEv2 connections are down? I deactivated temporary the src-nat to 127.0.0.1 then.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Wed Apr 22, 2020 8:32 pm

The route must be a normal one, with gateway=br-blackhole, not with type=blackhole, as using the latter would blackhole the packets before the IPsec policy is even matched.
But you won't see any traffic if sniffing on the bridge while the IPsec policy is inactive or non-existent, because before sending an IP packet over a point-to-multipoint interface, the IP stack needs to determine a MAC address of a router, but there is none reachable via that interface. You could use a point-to-point tunnel interface like a GRE one instead of the br-blackhole, whose remote end would be "nowhere", and with keepaliving disabled so it would appear to be always up. Point-to-point interfaces don't need to resolve a MAC address, so you should be able to sniff the traffic on it.
 
msatter
Forum Guru
Forum Guru
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: blackhole/unreachable with IPSec policies

Fri Apr 24, 2020 5:31 pm

Thanks Sindy and I have tried it but not traffic was seen on that GRE interface. Despite the traffic is routing marked it, it did not appear. The only way is to use dst-nat and then the traffic is seen with torch and then I can blacklist it in route then. Works great. This is ideal when the IKEv2 is out for a longer time.

The src-nat to 127.0.0.1 is still needed in the period on startup of IKEv2 and in the time the traffic, is still being connection marked in Mangle. I am using a scheduled script that removes the lines and reinsert them when the IKEv2 connections are changing.
The number of leaked traffic through src-nat 127.0.0.1 is kept to a minimum this way.
 
jdub88
Frequent Visitor
Frequent Visitor
Posts: 54
Joined: Fri Sep 25, 2020 1:35 pm

Re: blackhole/unreachable with IPSec policies

Fri Sep 25, 2020 1:52 pm

Hi All,

I am new to Mikrotik and I've enjoyed playing with my new hAP! I've got my VPN all running, and following various threads I've fixed what appears to be a pretty common performance problem, solved by the fasttrack issue.

Anyway, I have been trying to solve my goal of VPN-only routing via blackholing but at the moment, if I drop my VPN peer, traffic is allowed out.

I have added the blackhole bridge interface and set the route as detailed by eworm but I am a little confused by this comment:
Of course you need to add routing-mark (for route above) and connection-mark (for dynamic src-nat from mode-config) in firewall mangle.
Would anyone be so kind as to share sample configuration to solve this particular part please? I am running RouterOS 6.47.4

Thanks!
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Tue Sep 29, 2020 8:55 pm

Depending on what techniques you have chosen to let the NAT rule dynamically added by IPsec mode-config match the traffic to be sent via the tunnel (connection-mark or src-address-list), you have to use the same criteria (connection-mark or src-address-list) to assign a routing-mark, using a mangle rule, so that the routing table with the route containing the br-blackhole as a gateway route would be chosen for these packets. Without that, the default route in the main routing table is used for them, so if they don't get grabbed by the IPsec policy because the IPsec connection is down, they are sent via the default gateway (which is usually the WAN one).

So it would look like
/ip route add routing-mark=via-VPN-only gateway=br-blackhole

/ip firewall mangle add action=mark-routing src-address-list=via-VPN new-routing-mark=via-VPN-only
or, if you use connection-mark,
/ip firewall mangle add action=mark-routing connection-mark=via-VPN in-interface-list=!WAN new-routing-mark=via-VPN-only
 
jdub88
Frequent Visitor
Frequent Visitor
Posts: 54
Joined: Fri Sep 25, 2020 1:35 pm

Re: blackhole/unreachable with IPSec policies

Sat Oct 03, 2020 7:57 pm

Thankyou Sindy for taking the time to explain, that's much clearer now :)
 
mag1024
just joined
Posts: 5
Joined: Fri May 28, 2021 11:11 pm

Re: blackhole/unreachable with IPSec policies

Mon Apr 11, 2022 6:57 am

I found this recipe to be very helpful -- thank you guys! -- and have been using it successfully for a while now.
Recently, I upgraded to v7 and the routing setup seems quite different, and it no longer seems possible to create routes based on connection marks.
I'm guessing the routing tables are supposed to be the solution here, but I can't figure out a setup that works -- any ideas of what the equivalent setup in v7 would look like?
Thanks in advance!
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: blackhole/unreachable with IPSec policies

Mon Apr 11, 2022 9:24 am

It was never possible to use connection marks in routes (to compose routing tables), these were always routing marks. A "routing mark" and a "routing table name" are more or less the same thing, the nuance is that a routing rule (not route) can match on one routing-mark value (assigned by a mangle rule) and assign another one, which may be the reason why two distinctive terms have been introduced. But it is just my speculation, as a mangle rule can also match on one routing-mark value and assign another one, but both the input (match) parameter and the output (set) parameter are named routing-mark, except that the output one is prefixed with new- for distinction.

Several things related to routing marks and routing table names differ in RouterOS 7 as compared to RouterOS 6:
  • the name of the parameter on /ip/route rows (i.e. routes) is now routing-table rather than routing-mark
  • in order to avoid hard to spot errors caused by typos, the names of routing tables must be added explicitly before you can use them in routes, routing rules and mangle rules:
    routing/table/add name=via-VPN-only fib
    (this is not my speculation, Mikrotik has published it as the official reason)
  • the list of routing rules has moved from ip route rule to routing/rule

Who is online

Users browsing this forum: Amazon [Bot], bertus, kiloon and 104 guests