I was wondering if anyone had any experience with setting up an IPSEC VPN between Draytek and Microtik. My Draytek has a private subnet of 172.16.0.0/16. Microtik has a private subnet of 192.168.88.0/24. I have set up the corresponding policies on both sides and the tunnel is established successfully. I can also access hosts on Microtik subnet from Draytek and vice versa so up to this point everything is working as expected.
Here is however where things start to break. I have set up an additional routing policy on Draytek that routes packets destined for a particular country via the IPSEC tunnel. This works as expected up to a point when these packets arrive to Microtik. I can see them in Microtik firewall in both NAT and Mangle chains (pre-routing) with source IP of e.g. 172.16.1.5 and destination as public IP of the target.
I would expect these packets to then go into FORWARD chain of firewall and be forwarded using default gateway specified in the routing table. This, however does not happen. They end up in the INPUT chain instead and get “lost”. What I can’t quite figure out is why that is happening. It is quite clear that destination IP of these packets has nothing to do with Microtik.
Has anyone had a similar experience? Or perhaps I am missing something very obvious here? Thanks in advance for your help!
If destination is definitely not any address on RB, then only way how those packets could end up in input chain would be if they were redirected by some dstnat rule. Also the beginning is slightly misleading, you mention two LAN subnets, so I would expect “corresponding policies” to be just one between them, but there wouldn’t be any routing to internet with that and plain IPSec.
Thank you for your response. That is actually my confusion as the packets definitely come through dstnat as I would expect but there is nothing there to alter their routing and direct them to INPUT chain as opposed to FORWARD. You will see all the rules I have in NAT chain below:
You are also quite right - the IPSEC policies only direct the traffic between the two subnets. However Draytek also has an option on top of IPSEC policies (and as it does not really expose IPtables-like interface, I am not sure what it does in the background) of a routing policy where other packets can be directed to a particular interface based on defined rules. That is what I use in this case to direct other packets via IPSEC. Given that I can see these packets arriving to Microtik on the other side, I assume it works correctly.
I neither have or know Draytek (last router I saw from them was almost twenty years ago), but I’m curious about what’s happening. Can you export and post your whole config?
Next step in diagnostics can be to enable debug logging for ipsec on mikrotik and capture traffic for analysis (make sure to save all negotiated keys for later decryption, IIRC they are written to the logs).
So let’s say you ping from 172.16.1.5 to x.x.x.x that is routed to RB, and it’s something in internet. Then on RB you see it logged as FROM_SERG in prerouting, SERG_NAT_INPUT in dstnat (*), and then SERG_MANG_INPUT, instead of SERG_MANG_FWD? I don’t see how it would be possible.
Only suspicious thing is the mangle rule with action=route, but I assume .129 is default gateway, right? Or not? You shouldn’t need this rule at all if it is, only if it differs from it. But as long as this .129 is not assigned to this router, there’s nothing else that could send these packets to input.
(*) This rule’s to-addresses doesn’t make sense, it must be some leftover from this rule having originally action=dst-nat, but still it can’t do anything when it’s action=log now.
That is correct. And you are right - .129 is the gateway and the only reason I created this rule was in the hope that it would direct traffic to FORWARD chain as opposed to INPUT, but it did not help.
The funny thing is that if I try to access e.g. 192.168.88.70 IP address on the internal network (Mikrotik side), then those packets flow to the FORWARD chain as expected. It almost feels like the router does not know that it needs to send packets for external addresses to the internet gateway when they come across from Draytek via IPSEC tunnel.
Do you have any suggestions as to how I could investigate this issue further?
At first I wasn’t sure about IPSec config. Policy for just the two subnets is obviously not enough, and I’m not sure it it’s used at all, because I normally use static configs myself. You have generate-policy=port-override, which creates whatever policies peer asks for. You can check what’s created (/ip/ipsec/policy/print detail), but it can’t (or at least shouldn’t) break things in a way you’re seeing.
Another thing is FastTrack, you can try to disable it, because according to manual it’s not compatible with IPSec. But it’s hard to believe that it would cause this behaviour.
And remove the rule with action=route, that’s really not needed.
Do not disable FastTrack globally or with custom rules, use the notrack-chain property of an IPsec identity.
But Sob’s right, my understanding is that if it were a FastTrack problem then you would not see traffic in the direction Mikrotik → Draytek: NAT rewrite happens before packets are routed according to IPsec traffic selectors
Although I’m confused why Mikrotik → Draytek works with the attached config.
