Community discussions

MikroTik App
 
SteveDE
just joined
Topic Author
Posts: 1
Joined: Wed Nov 16, 2022 6:15 pm

Killswitch for IPSec (here: NordVPN) on ROS7

Sun Nov 27, 2022 12:46 pm

Hello,

as stated above: I am looking for a killswitch to avoid data to be sent through the default GW, when IPsec-Tunnel is down.

After studying different approaches for the last two days, my best bet was to apply Sindys config (Hopefully I got Sindys approach right !?):
/interface bridge add name=BlackholeBridge protocol-mode=none
/routing table add name=BlackholeTab fib
/ip firewall mangle add chain=prerouting dst-address-list=<public IPs to be reached via IPSec> action=mark-routing new-routing-mark=BlackholeTab passthrough=yes
/ip route add gateway=BlackholeBridge routing-table=BlackholeTab
/routing rule add action=lookup routing-mark=BlackholeMark table=BlackholeTab
/routing rule add action=lookup table=main
As far as I understand, this approach will just send all traffic meant for <public IPs to be connected via IPSec> to the killswitch, but when IPSec-Tunnel is up, the traffic will be picked up, before being killed.

But: This seems not to work for me, since my setup does not apply IPSec-routing due to specific dst-addresses - I want to apply IPSec-routing for all destinations (0.0.0.0/0) when local source-IP is within a certain range. So here is my working IPSec-Config:
# Mark traffic that you want to route through VPN server
/ip firewall address-list add address=192.168.17.176/28 list=via_NordVPN
/ip firewall mangle add action=mark-connection chain=prerouting src-address-list=via_NordVPN new-connection-mark=via_NordVPN passthrough=yes comment="Mark NordVPN-Traffic"

# IPsec/IKEv2 configuration
/ip ipsec mode-config add name="NordVPN mode config" responder=no connection-mark=via_NordVPN
/ip ipsec policy group add name=NordVPN
/ip ipsec profile add name="NordVPN profile" dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha512
/ip ipsec peer add address=XXX exchange-mode=ike2 name="NordVPN server" profile="NordVPN profile"
/ip ipsec proposal add name="NordVPN proposal" pfs-group=none auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=0s
/ip ipsec identity add auth-method=eap certificate="NordVPN CA" eap-methods=eap-mschapv2 generate-policy=port-strict mode-config="NordVPN mode config" peer="NordVPN server" policy-template-group=NordVPN username=XXX password=XXX
/ip ipsec policy add dst-address=0.0.0.0/0 group=NordVPN proposal="NordVPN proposal" src-address=0.0.0.0/0 template=yes

# Exclude VPN traffic from fasttrack
/ip firewall filter add action=accept chain=forward connection-mark=via_NordVPN place-before=[find where action=fasttrack-connection] comment="Exclude NordVPN traffic from fasttrack"

# Reduce MSS
/ip firewall mangle add action=change-mss chain=forward new-mss=1360 passthrough=yes protocol=tcp connection-mark=via_NordVPN tcp-flags=syn tcp-mss=!0-1360 comment="Fragment NordVPN-TCP-Traffic to less than 1360 Bytes"

Some threads in this forum say: Just use Sindys approach and change the mangle-rule
dst-address-list=<public IPs to be connected via IPSec>
to
src-address-list=via_NordVPN
As far as I understand Sindys approach, this will not work: When using src-address instead of dst-address then >all< traffic originating from my local IP-List "via_NordVPN" will be killed.


So I ended up with another approach (Yes, I have spent lots of hours, reading this forum and other sources...):
Just excluding the local IP-List "via_NordVPN" from the standard masquerading-rule. When IPsec-Tunnel is up, scrnat will be applied by the automatic IPSec-Mode-Config-Rule. When IPSec-Tunnel is down, the traffic will leave my router w/o srcnat.
Well, this is not a "1st-class killswitch": Traffic will probably reach its public-IP-destination, but since it will arrive there w/o being nat-ed, there is no traceability to tell that the traffic was originated by my router and no connection will be established, since a request with a private src-IP cannot be routed back.


This "2nd class killswitch" works well for me at home - But now I want to apply this at a different location.
Here my setup is slightly different: Between Internet and MikroTik there is another router, which cannot be omitted, since its mandatory for VoIP.
My "2nd class killswitch" works well, as traffic arrives un-NAT-ed (with source-IP 192.168.17.176/28) through the Mikrotik-interface 192.168.0.2 at the foreign router (192.168.0.1).
But the foreign router applies the missing NAT!!! My "2nd class killswitch" will not work in this environment!!! All traffic will go the whole round-trip even w/o established IPSec-Tunnel!!!!


Now I am desperately looking for a filter-rule to block traffic originated from my local IP-List "via_NordVPN" when IPSec-Tunnel is down.
As mentioned above: For my understanding Sindys approach will only work, when IPSec-Tunnel is applied to specific public IPs (not to specific local IPs).
Still I think, my "2nd class killswitch"-approach can be helpful: It makes the traffic which is forwarded by my MikroTik-Router distinguishable since it is not src-NAT-ed:
  • Outgoing traffic with established IPSec-Tunnel when "2nd class killswitch" is applied
    in:bridge out:ether1, connection-mark:via_NordVPN connection-state:new,snat src-mac 00:e0:4c:30:9a:de, proto UDP, 192.168.17.176:60793->142.251.36.46:443, NAT (192.168.17.176:60793->10.6.0.1:60793)->142.251.36.46:443, len 107
  • Outgoing traffic without IPSec-Tunnel when "2nd class killswitch" is applied
    in:bridge out:ether1, connection-mark:via_NordVPN connection-state:new src-mac 00:e0:4c:30:9a:de, proto UDP, 192.168.17.176:52351->142.250.74.195:443, len 1278
Now I am looking for a filter-rule which just blocks un-NAT-ed traffic, but source-IP-rule=10.0.0.0/8 will not match, since this is not the real source, but the NAT-ed-source.
I also tried to drop all forwarded traffic, which originates from the local IP-List "via_NordVPN" and has connection-NAT-state=!srcnat - But this rule seems to drop traffic before any NAT-decision is made ... So NAT-ing cannot be applied at all, which results in blocking to whole internet-connectivity.
Does anybody (Sindy?) have an idea, how to filter this traffic by its NAT-ed source-IP? Or an Idea for a different killswitch-approach?




Thanks in advance ...

... Ruediger (from Germany - so don't mind any bad English ;-))

Who is online

Users browsing this forum: adimihaix, rplant and 74 guests