I’m afraid it is an answer to another question.
“cone”, “restricted cone” etc. are terms from an RFC which has attempted to classify NAT types by behaviour in order to allow prediction how future connections through that NAT will look like, so that e.g. a SIP phone could indicate in SDP the public IP address of the NAT and the correct port on it when sending the SDP already before the RTP flow has even started so before the pinhole in the NAT could be created. The concept is called STUN.
So all these “NAT types” deal with what Mikrotik calls src-nat. The differences between these NAT types consist in how many attributes of the flow are taken into account when creating a new pinhole and when letting traffic through the pinhole from the public side to the private one.
When a UDP packet is sent from port a on IP address A at the private side of the NAT to port b on IP address B on the remote end, the NAT allocates port c on its public interface to forward that packet.
The first difference between NATs is whether they try to keep c=a whenever possible or whether they prefer that c != a even if c=a would be possible.
Another difference is whether if c cannot be equal to a, a random one is chosen or the last assigned one incremented by 1.
Yet another difference is whether, once port c is open, only packets coming to C:c from B:b are forwarded to A:a or whether packets from anywhere else are forwarded too.
Yet another difference is whether, for a connection from another internal IP address (D) but same port (a) to another external socket than B:b, the same port c=a is used or another one.
I’m afraid that from this perspective, you cannot configure how Mikrotik’s src-nat behaves. You can only configure whether a single public address will be used or a pool of them, plus you can choose network prefix NAT (network to network) or 1:1 mapping (where each address on private side is systematically NATed to its own unique address on the public side but the mapping is not prefix based and only some private addresses may have their own public address assigned). But for many:1 (private:public) mapping, you cannot influence the behaviour - the connection tracking ensures that always only packets from B:b are let in, but that says nothing about how c is chosen.
Thanks for your answer!
My problem is that,
Setting upnp,and user’s ps4 can’t login or log out in on minute when join to “room”
For test,the firewall filter is empty.
But,if I set dst-nat manually it works well.
As you mention upnp, there is no need to think about NAT type - upnp allows the device on the LAN to tell the router which ports on the WAN address it wants to open and forward to itself, so the autonomous rules for allocating pinholes as described earlier are not used. So the correct question would be “why upnp does not work (as expected) between the PS4 and the Mikrotik”.
Can you provide the output of “export hide-sensitive” from your Mikrotik?
effectively does nothing because the default policy of Mikrotik firewall is ****
accept
. So packets which match the rule above are accepted by that rule, while all the other packets are accepted by default.
You have no rules in ****
/ip firewall filter chain=input
and no address ranges in
/ip service
. So unless there is some other firewall between your device and the internet which prevents access to your Mikrotik’s management ports (telnet, http, …) but permits access to other ports (as otherwise the upnp or dstnat rules would be useless and they clearly are not), all the management services of your Mikrotik are accessible from anywhere in the internet.
I am sorry for that " discrepancy" confused you.
It’s a testing “trail” for vlan 2363 because I have multiple wan line in production environment.
I do user wan interface (vlan 1) to test upnp,
and set
/ip upnp interfaces
add disabled=no interface=LAN type=internal
add disabled=no interface=WAN type=external
Thanks a lot for the reminding of firewall setting. It is only configuration for testing.
I didn’t feel confused before but now I do Has this change solved your initial issue or not? I.e. do you need the dst-nat rule to make the ps4 work even with this modified upnp setting?
Thanks a lot for the reminding of firewall setting. It is only configuration for testing.
Having no context, I didn’t know whether that is an issue or not. But even if it is a testing configuration, having unprotected devices exposed to internet is a bad idea as they may start spreading malware themselves if infected.
I didn’t feel confused before but now I do > > Has this change solved your initial issue or not? I.e. do you need the dst-nat rule to make the ps4 work even with this modified upnp setting?
Because of the setting of upnp didn’t make ps4 work,I configed the dst-nat setting manualy,then ps4 do work.
Having no context, I didn’t know whether that is an issue or not. But even if it is a testing configuration, having unprotected devices exposed to internet is a bad idea as they may start spreading malware themselves if infected.
Thanks, I have changed the ports of service and limited the source ip address to protect the device.