I am trying to make an IPSec L2TP server for MacOsX and iOs clients.
I have a test lab here to check different cases.
RB IPSec L2TP Server with “white” IP ------- Internet -------- client with “white” IP
Server gets UDP packet with Dst port 500 and Src port 500 - successful connection.
RB IPSec L2TP Server with “white” IP ------- Internet -------- client with “grey” IP
Server gets UPD packet with Dst port 500 and random Src port like 14912 because of provider’s NAT.
There’s a problem - no connection, RouterOS does not detect incoming UPD packets as ISAKMP.
RB IPSec L2TP Server with “white” IP ------- Internet -------- RB with “white” IP and masquerade -------- client
Server gets UDP packet with Dst port 500 and Src port 500 - successful connection.
Is it possible to make 2-nd case to become working?
Хозяйке на память: “белые” и “серые” адреса - жаргон русскоязычной среды, остальному миру значение этих названий непонятно.
The reason why RouterOS doesn’t recognize packets coming from UDP port 14912 to UDP port 500 as ISAKMP one can be one of the following:
your rules in chain=input of /ip firewall filter block such packets
not only the source address and port but also the contents of the packet has been modified on the path between the client and the server
(speculation) you use some pre-historic version of RouterOS on server side
You can check whether case 1. or 2. is relevant by adding the following rules before the action=masquerade one at client-side RB in your case 3. (and removing the old connection established using the action=masquerade one or simply waiting for 4 minutes before trying again):
Packets was “accepted” by NAT rule and than was “dropped” by firewall “defconf: drop all from WAN” rule.
I know about a flowchart, but it was rather difficult to find a solution with almost no debug tools. And problem has become even more dufficult because there was correct counters increment in NAT rule.
Not that I would understand this explanation, so I assume that the packets from the ISP were coming in via WAN so the drop rule in /ip firewall filter was dropping them, whereas the packets from the other RB were coming in via some other interface than the WAN, and so the drop rule in /ip firewall filter wasn’t dropping them and the accept rules in /ip firewall nat didn’t actually modify them.
Other than that, I believe you can mark your own post as a solution by clicking the “tickbox” icon in the right upper corner, so you need not add the [solved] to the topic title manually, but I may be wrong.
As for debug tools, Mikrotik is full of them - you can use /tool sniffer, /tool torch, log=yes option on firewall rules, and /ip firewall … print stats to show the number of packets and bytes handled by the individual rules.
I was really send traffic between RBs not via WAN - it was a mistake.
There is very confusing thing: I can really see an incoming packet in WireShark during shiffing, but I can’t see if RB accepted or dropped it. So sniffer and torch are not suitable in this case. Just only logging with prefixes, but you should assume all the rules suspected.
And also: NAT “dst-nat accept” rule is not enough for RB to accept a packet.
Well, that should not confuse you - torch and sniffer show you what happens “on the wire” (leaving virtual interfaces and IPsec out of discussion to keep it simple), so it is clear that they cannot tell you what the firewall does.
However, the structure of the firewall and the role of tables and chains is essential and documented quite well, so you normally don’t need debug tools to learn that that action=accept in /ip firewall nat or /ip firewall mangle does not provide a final verdict like in /ip firewall filter but just stops the packet from being inspected by further rule in that chain. So no debug tool which would show you the complete way of a packet through the firewall is availble.