unable to establish ipsec tunnels behind mikrotik

RouterOS General
1

Hey all,

Hoping someone can point out what i’m missing here.

Currently i am unable to establish IPSec based tunnels behind mikrotik (VoWiFi and work VPN)

I’ve searched around, and tried to work through this, but I’m just making a mess of my configuration..
When logging the packets, the Calls on Port 500 go out, but nothing comes back on 4500 like what i’d normally expect to see.

Fasttrack is disabled on my Routerboard (Requirement for the load balancing) so i know that’s not interfering.

I’ve tried disabling the secondary connection and thus turning off load balancing but that doesn’t seem bring any improvements.


# oct/28/2019 23:33:18 by RouterOS 6.45.6
# software id = 9MZQ-B22L
#
# model = RouterBOARD 3011UiAS
# serial number = 761706BDF96F
/ip firewall address-list
add address=10.3.56.0/22 list="Local Network Ranges"
add address=10.3.100.0/24 list="Local Network Ranges"
add address=10.80.57.0/24 list="Local Network Ranges"
add address=10.15.57.0/24 list="Local Network Ranges"
add address=192.168.20.0/24 list="Local Network Ranges"
add address=192.168.21.0/24 list="Local Network Ranges"
add list=ForceRouteSparkDST
add list=ForceRouteVFDST
add list=ForceRouteSparkSRC
add list=ForceRouteVFSRC
add address=10.3.56.31 list=ForceRouteSparkSRC
add address=10.3.56.30 list=ForceRouteVFSRC
add address=10.3.56.32 list=ForceRouteSparkSRC
/ip firewall connection tracking
set enabled=yes
/ip firewall filter
add action=accept chain=input protocol=ipsec-ah
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input comment="allow IPsec NAT" dst-port=4500 protocol=udp
add action=accept chain=input comment="allow IKE" dst-port=500 protocol=udp
add action=accept chain=input dst-port=8291 protocol=tcp
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
add action=accept chain=input comment="DEFAULT: Accept established, related, and untracked traffic." connection-state=established,related,untracked
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=Spark
add action=drop chain=forward comment="Drop all from VF WAN that's not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=VF
add action=drop chain=forward comment="Guest network Isolation" in-interface=GUEST-Bridge out-interface=bridge
add action=drop chain=forward in-interface=GUEST-Bridge out-interface=HAB-Bridge
add action=drop chain=forward dst-address=10.3.56.0/22 in-interface=GUEST-Bridge
add action=drop chain=forward comment="HAB network isolation" in-interface=HAB-Bridge out-interface=bridge
add action=drop chain=forward in-interface=HAB-Bridge out-interface=GUEST-Bridge
add action=drop chain=forward dst-address=10.3.56.0/22 in-interface=HAB-Bridge
add action=drop chain=forward dst-address=!10.3.56.0/22 in-interface=HAB-Bridge log=yes log-prefix="DROP HAB: "
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=Spark
add action=drop chain=input in-interface=VF
/ip firewall mangle
add action=route chain=prerouting comment="Route for VF Modem" dst-address=192.168.20.1 dst-address-list="" passthrough=no route-dst=10.3.100.1
add action=route chain=prerouting comment="Route for Spark Modem" dst-address=192.168.21.1 dst-address-list="" passthrough=no route-dst=10.3.100.1
add action=mark-connection chain=prerouting dst-address=10.3.56.0/22 dst-address-list="" new-connection-mark=Local passthrough=yes
add action=mark-connection chain=prerouting comment="Force 2d IMS out VFWAN" dst-address=118.149.14.20 in-interface=bridge new-connection-mark=VFWAN passthrough=yes
add action=mark-routing chain=prerouting comment="Force 2d IMS out VFWAN" dst-address=118.149.14.20 in-interface=bridge new-routing-mark=VFConnectionRoute passthrough=yes
add action=mark-routing chain=output comment="Force 2d IMS out VFWAN" dst-address=118.149.14.20 new-routing-mark=VFConnectionRoute passthrough=no
add action=mark-connection chain=prerouting comment="Force Route" connection-mark=no-mark new-connection-mark=SparkWAN passthrough=yes src-address-list=ForceRouteSparkSRC
add action=mark-connection chain=prerouting connection-mark=no-mark new-connection-mark=VFWAN passthrough=yes src-address-list=ForceRouteVFSRC
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-list=ForceRouteVFDST new-connection-mark=VFWAN passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-list=ForceRouteSparkDST new-connection-mark=SparkWAN passthrough=yes
add action=mark-connection chain=prerouting comment="Tag all connections from Spark WAN" connection-mark=no-mark in-interface=Spark new-connection-mark=SparkWAN passthrough=yes
add action=mark-connection chain=prerouting comment="Tag all connections from VF WAN" connection-mark=no-mark in-interface=VF new-connection-mark=VFWAN passthrough=yes
add action=mark-connection chain=prerouting comment="Equal split connections across WANS" connection-mark=no-mark dst-address-type=!local in-interface=bridge new-connection-mark=SparkWAN passthrough=yes per-connection-classifier=\
    both-addresses-and-ports:2/0
add action=mark-connection chain=prerouting comment="Equal split connections across WANS" connection-mark=no-mark dst-address-type=!local in-interface=bridge new-connection-mark=VFWAN passthrough=yes per-connection-classifier=\
    both-addresses-and-ports:2/1
add action=mark-packet chain=prerouting in-interface=bridge new-packet-mark="Normal Traffic" packet-mark=no-mark passthrough=yes
add action=mark-packet chain=prerouting in-interface=GUEST-Bridge new-packet-mark=GUESTPACKET packet-mark=no-mark passthrough=yes
add action=mark-packet chain=prerouting in-interface=HAB-Bridge new-packet-mark=HABPACKET packet-mark=no-mark passthrough=yes
add action=mark-routing chain=prerouting comment="Tag Routung for connections due to go out Spark" connection-mark=SparkWAN in-interface=bridge new-routing-mark=SparkConnectionRoute passthrough=yes
add action=mark-routing chain=prerouting comment="Tag routing for connectios due to go out VF" connection-mark=VFWAN in-interface=bridge new-routing-mark=VFConnectionRoute passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=GUEST-Bridge new-connection-mark=GUESTMARK passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=HAB-Bridge new-connection-mark=HABMARK passthrough=yes
add action=mark-routing chain=prerouting connection-mark=GUESTMARK in-interface=GUEST-Bridge new-routing-mark=VFConnectionRoute passthrough=yes
add action=mark-routing chain=prerouting connection-mark=HABMARK in-interface=HAB-Bridge new-routing-mark=VFConnectionRoute passthrough=yes
add action=mark-routing chain=output connection-mark=VFWAN new-routing-mark=VFConnectionRoute passthrough=yes
add action=mark-routing chain=output connection-mark=SparkWAN new-routing-mark=SparkConnectionRoute
add action=mark-routing chain=output disabled=yes new-routing-mark=VFConnectionRoute passthrough=yes
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface=VF
add action=masquerade chain=srcnat out-interface=Spark
add action=masquerade chain=srcnat out-interface=VF
/ip firewall service-port
set sip disabled=yes
set pptp disabled=yes
2

When you say “behind Mikrotik”, I suppose there is no active IPsec configuration on the Mikrotik itself and that the VPN to the office is running on your PC connected to the LAN side of the Mikrotik.

Since you say that you can see the packets towards UDP port 500 to leave via the WAN interface, it seems that your strange firewall rules *) do not prevent the connection from being initiated.

In any case, if the initiator (client) on the LAN side of your Tik initiates the IPsec communication towards port 500 of the responder (server), the first few response packets should come from port 500 too; only once the initiator and responder find out that there is a NAT between at least one of them and the internet, they agree on moving to port 4500, and it’s again the initiator who must send the first packet towards responder’s port 4500 to get a response from there, otherwise a mere NAT would not know where to forward packets coming from the responder’s port 4500 to its public address.

With the VPN to the office, I could imagine that it does not support the NAT-T (NAT traversal) option so the migration to port 4500 and UDP-encapsulation of ESP cannot happen, but with VoWiFi I don’t expect this to be the case. So first, check whether you get responses from responder’s port 500; if you don’t, it’s something between the Tik and the internet that blocks them.

*) by strange firewall rules I mean e.g. the following pair:
add action=drop chain=forward dst-address=10.3.56.0/22 in-interface=HAB-Bridge
add action=drop chain=forward dst-address=!10.3.56.0/22 in-interface=HAB-Bridge log=yes log-prefix="DROP HAB: "
It effectively prevents devices connected via HAB-Bridge from initiating any connection whatsoever, is it the actual intention?

Also,
/ip firewall nat
add action=masquerade chain=srcnat comment=“defconf: masquerade” ipsec-policy=out,none out-interface=VF
add action=masquerade chain=srcnat out-interface=Spark
add action=masquerade chain=srcnat out-interface=VF
mean that anything that goes out via VF is masqueraded, regardless whether it matches an ipsec policy or not, so the first rule has no effect.

3

So i eventually worked this one out.

Turned out i wasn’t handling IPSec aswell as i should have been before the PCC/Load Balance rules. so what it was doing is the normal calls over udp/500 then udp/4500 would go out another ip and it would freak (as expected)

/ip firewall mangle
add action=mark-connection chain=prerouting comment=“Force VPN to work” connection-mark=no-mark in-interface=bridge new-connection-mark=AirFibreMark passthrough=yes port=500,4500 protocol=udp

Essentially just mangling IPsec to pass out a single interface (with failover managed by routing metrics).
Has not faulted since on VoWiFi, femtocell and Work VPN (recently moved from the old citrix ipsec style to standard IKEv2 - so much better..)



Your right, those two rules do contradict themselves, and i’ve since simplified it.
they were achieving exactly what they should have been doing though, one was just less effective than the other…

the first nat rule noted, is actually disabled. it was default and i left it in there. I’ve also since trimmed it when i was pulling back rules to work out where i broke IPSec…

4

That’s actually surprising rather than expected, because if the responder only accepted incoming packets on port 4500 from the same remote address from which it had received the initial packets on port 500, it wouldn’t be able to establish connections with any initiator located behind a NAT device which use a pool of public addresses and doesn’t use sepcial measures to let all connections from the same private address be NATed to the same public one. So I would expect this to be an issue maybe with the work VPN where the responder would be made by some exotic manufacturer, but not with the VoWiFi one. Mikrotik’s IPsec stack acting as a responder does not compare the source addresses of the two UDP streams - the incoming packets to port 4500 are accepted if they contain IKE session identifiers matching a session recently initiated by packets coming to port 500, regardless their source address. Of course, the responses to each incoming stream go back to its respective source socket.

5

Not sure then.. key thing for me is, it works. dont break what’s not broken right?

6

100% agreed. What I had in mind is that the actual reason why it started working may be different than you expected, so don’t be surprised if it eventually breaks again :slight_smile: