I had a v7.19 router with an IPSec tunnel to a Palo Alto router. It worked fine. Then I copied the config to a replacement router and updated to 7.21. The tunnel would no longer connect.
The logs showed that it was sending packets out on port 4500 and not receiving any response. nat-traversal=no so it should have been using port 500 by default. In the profile, the port was blank (just like it had always been, and it was using 500 by default with 7.19 and previous versions).
After updating to 7.21, I had to manually specify port 500 for it to work … and it works properly after specifying port 500.
WHY is it using port 4500 when leaving the port blank when nat-traversal is disabled??? This was not the behavior before, because 500 is the standard port.
So is it "...a bug?" or just a change in the defaults that are inconsistient with settings you used to use?
Have you checked changleogs if something could have influenced the behaviour?
I have checked change logs, there is nothing I see that indicates this change.
Regarding your question of a bug vs just a change in defaults: If this really is happening (and not just something I have missed in my config), then this would be considered a bug. It would be no different than if the https fetch tool started using port 2000 instead of the standard port 443 by default, and you had to manually specify port 443.
Port 500 is, by definition, the IPSEC port. Port 4500 is, by definition, the NAT-T port. There would be no reason for those standardized port numbers to ever have their defaults changed. Sure, some configs might need to change them manually for their own purposes, but that would be a per-situation change, not a change in the default behavior of the router.
Ok, so IKEv2. Indeed I seem to remember that IKEv2 can also setup connections on 4500 (skipping the use of 500 altogether) but as you write, that should not be the default. With this config, will it eventually establish an ESP tunnel (protocol 50) or will it keep trying to use port 4500?
Maybe it somehow misdetects the NAT situation…
My IKEv2 router is also still running 7.19.6 so I can not immediately rule out that something has changed. I’m not going to update it right now, this week I have spent several hours to make plain Linux systems using *swan to make and sustain tunnel connection, all those forks have different quirks (and so does RouterOS).
I waited several hours before changing it, and it never did establish during those several hours, until I changed the port. It was only attempting to use 4500.
Yep, but in 7.21.4 there could be "no default" for "port" (and you had to add port =500), you need also the output of same command on 7.19 to see if in that one there was a default of "port=500" (or some other ones).
Do not agree. Can not find any information that the source port for communication HAS TO BE 500/4500 ... communication has to switch to 500 - 500 ports when NAT-T is recognized.
According your argument of https fetch: is there any obligatory rule that says that fetch has to start from port 443 or may use the other one? Do you suggest that all devices behind firewall do https request with SRC443 - DST 443 ports? What are the other ports then?
My example of fetch was destination port. My point is, you can always expect the destination port for regular https traffic to be 443 (if it is not otherwise specified). It would be a bug if Mikrotik were, for example, to start sending fetch traffic to port 2000 of the fetch URL if you leave the port blank. That would not make sense.
Likewise, it does not make sense for Mikrotik to send regular IPSec traffic to the remote IP on dst port 4500 if the port is left blank and if NAT-T / nat-traversal is disabled. Port 4500 is specifically for nat-traversal.
Regarding your point that "Can not find any information that the source port for communication HAS TO BE 500/4500 ... communication has to switch to 500 - 500 ports when NAT-T is recognized." Again, we don't really care about the source port, at least not for this discussion. The destination port, however, which my post is regarding, is supposed to be 500 for regular IPSec and is supposed to 4500 for nat-traversal traffic according to the RFC standards (and this is how Mikrotik seems to have always worked in the past).
According to the standards, port 4500 is reserved for UDP-encapsulated ESP and IKE. Otherwise it should use port 500. Obviously, if both sides agree to change it, that can be done, but that is not the standard and a non-standard method should not be the default.
Now, regardless of whether or not we agree on the above, the following is DIRECTLY from the official Mikrotik Documentation:IPsec - RouterOS - MikroTik Documentation
port (integer:0..65535 ; Default: 500 )
Therefore, with 500 being the official Mikrotik default, that means that having to manually put 500 into the blank field to make it 500 is a bug.