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.
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.
Statistics: Posted by mkx — Fri Jan 26, 2024 6:05 pm