I’ve been scouring the forums today and haven’t found anything that has worked so I thought I’d ask for some help.
I am trying to connect a 2011 (v6.40.9)(Site A) to a Cisco RV345(Site B). I’ve created the tunnel and it seems to be connected, the IPSEC Log ending with :
IPSEC :: IPsec-SA established: Public-IP-A[4500]->Public-IP-B[4500] spi=0x#######
IPSEC :: IPsec-SA established: Public-IP-B[4500]->Public-IP-A[4500] spi=0x########
I’ve added a SRC-NAT for accept with src-address=Private-A-Network dst-address=Private-B-Network
When I check my log, I see
Drop Wan : input: in:ether1 out:(none), src-mac 6c:71:0d:39:9c:19, proto 50, Public-IP-B->Public-IP-A, len 136
Drop Wan being the last line of my Firewall rules.
I don’t get any packets on my NAT rule nor do I get packets under Installed SA’s.
As i can see from the Log Nat Traversal is used, UDP 4500, so @sob, why would he need to explicitly allow ESP port 50 on the Firewall ?
If NAT-T is used, the ESP 50 packet is encapsulated to UDP port 4500…
So actually there is no need to allow ESP 50 port…
In a site to site tunnel ofcorse we can choose not to use NAT-T and yes in that case protocol ESP 50 must be allowed in the Firewall …
I also originally thought that port 4500 means NAT and therefore no ESP, but it’s not necessarily the case. I don’t know how others have it, but I see RouterOS using port 4500 by default for IKEv2.
Plus the log shows dropped ESP, so it’s clearly used.
Plus the log shows dropped ESP, so it’s clearly used.
I saw that now…
However am not really sure about that…
I think on IKEv2 as on IKE, encapsulation of the ESP packet to a UDP one, only happens if NAT is being detected…
Right, but port 4500 doesn’t automatically mean that encapsulation is in use. What I see is IKEv2 using 4500 for negotiation instead of 500, it doesn’t use 500 at all. And then where there’s no NAT, it uses plain ESP packets for data. That’s default config with no manually entered port.
With IKEv2 the requirement is that 500 cannot be used for encapsulated traffic. 4500 can be used for either or both as long as both sides can distinguish the traffic.
While it is reasonable for RouterOS to use 4500 to initiate the connection, why does it assume that the counterpart supports both types of traffic on 4500? I don’t see this requirement in the RFC.
ok @sob, i understand… So you mean it uses by default ports 4500 and 50 when there is not NAT and it encapsulates ESP to UDP when nat is detected…
But i can’t seem to find reference on that? Is there any chance that only MikroTik uses only port 4500 for IKEv2 and not 500 ?
I don’t know, I discovered this by accident, took a note that it happens, but so far it didn’t bother me enough to search for details, because it didn’t break anything for me. Only once the other side didn’t like it, but setting peer’s port to 500 fixed it. If it was something under my control, I would probably play with it a little, but it wasn’t.
This is still baffling to me. If we need to allow proto 50 from peers, how does the Roadwarrier setup work (when the client’s public IP will be unknown until it tries to connect)?
How safe/unsafe is it to allow proto 50 from any location?
Can anyone further explain NAT when using port 500 vs 4500? Should we choose one or the other, or do we need to allow both 500 & 4500?
If I’m creating a site-to-site tunnel between two Mikrotiks, does setting the port to 500 make opening proto 50 unnecessary?
Where do I set the port, in the peer config, the policy, or both?
I think with a roadwarrior you effectively have to allow %any or 0.0.0.0/0 because you have no idea which IP they will connect from. Of course you may be able to limit that but YMMV.
Your security is always a trade off with accessibility. If you want to be more secure, don’t allow VPN access. Or restrict it to known IPs. Use certificates and not passwords. etc
The site to site example above limits access to a known IP, but you need a static IP for that.
I have the following - you can add src address if required - and use certificates.