Hi!
I tried to setup a src+dst NAT for a UDP communication but it seems like routeros might not track this session correctly and therefor no answer is sent back to the original host. The first UDP packet goes like this:
192.168.1.2:29999->Router 192.168.1.1:29999 then src+dst NAT is applied. Router 192.168.20.1:29999->192.168.20.2:29999
Now the answer comes:
192.168.20.2:30000->Router 192.168.20.1:29999 and here is where communication ends. Nothing is translated back and sent out on 192.168.1.1 to the original host.
I think it is because the 192.168.20.2 device changes the src port to 30000 so connection tracking does not recognise the reply. Don’t know why as the src port on the router was 29999 and the reply was sent back to the same port, shouldn’t connection tracking pick it up then no matter what the src port was on 192.168.20.2? What is the exact requirements of UDP NAT connection tracking? And can I overcome this by simply adding another dst NAT for this answer or is there a better way?
Background to this is that the 192.168.20.2 is a 25 years old device that I don’t want to mess with and I want to access it remotely from another network.
Connection tracking generally assumes that bi-directional communication flows between same ip:port pair. In your case between 192.168.1.2:29999 and 192.168.20.2:29999 … and in both directions. If 192.168.20.2 instead starts to send return packets from 192.168.20.2:30000, then for connection tracking this is completely different connection (initiated by 192.168.20.2).
There’s an ancient protocol which can start new connections on unrelated pair of ports: FTP. And to handle that, firewalls implement helpers, in ROS that’s under /ip/firewall/service-port. FTP helper then snoops into communication between client and server and when it detects parameters of tge “unrelated” connection, it creates necessary dynamic NAT rules (which persist until connection is closed). It will also change the commands so that it correspond to the dynamic NAT properties. This only works if connection is not encrypted, so it can’t work for e.g. FTPS (FTP over SSL).
In ROS only implements a few helpers for common protocols and it’s not possible to install own helpers for a different protocol.
In your case you could make things working if you created a DST-NAT rule to forward 192.168.20.1:29999 when src-port=30000 to 192.168.1.2:30000 (probably that’s what applucation running there expects).
The problem with this pair of DST-NAT rules is that they only allow bidirectional communication from one machine on one side to one machine on another side.