Ubuntu’s Port forwarding is not working properly on Nvidia Jetson Xavier

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
,
1

I am trying to set up port forwarding on my Nvidia Jetson device with Ubuntu installed.

I am trying to forward traffic going to IP 172.16.0.100 and port 81 to forward to IP: 192.168.0.200 and port 554.

I am using IPTABLES to setup the forwarding. I have used the following rules:

sudo iptables -t nat -A PREROUTING -p tcp --dport 81 -j DNAT --to-destination 192.168.0.200:554

sudo iptables -t nat -A POSTROUTING -p tcp -d 192.168.0.200 --dport 554 -j SNAT --to-source 172.16.0.100

Adding these rules does not work. I cannot access 192.168.0.200 on port 554. I’ve tested these rules on a different PC running the same version of Ubuntu and it worked perfectly.

I’ve also tried a combination of NAT and Firewall rules, like:

sudo iptables -I FORWARD 1 -m state -p tcp -d 192.168.88.207 --dport 81 --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A POSTROUTING -j MASQUERADE

iptables -t nat -A POSTROUTING -s 172.168.88.207 -j MASQUERADE

But nothing seems to work.

I ran a TCPDUMP on the Nvidia device to see what happens with the traffic:

####@Ubuntu:~$ sudo tcpdump -n --interface=tun0 port 81

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes

13:18:41.533140 IP 172.16.0.1.56502 > 172.16.0.100.81: Flags [S], seq 1758976221, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:18:42.538221 IP 172.16.0.1.56502 > 172.16.0.100.81: Flags [S], seq 1758976221, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:18:44.523913 IP 172.16.0.1.56502 > 172.16.0.100.81: Flags [S], seq 1758976221, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:18:48.539027 IP 172.16.0.1.56502 > 172.16.0.100.81: Flags [S], seq 1758976221, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:18:56.540632 IP 172.16.0.1.56502 > 172.16.0.100.81: Flags [S], seq 1758976221, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

####@Ubuntu:~$ sudo tcpdump -n --interface=enp0s3 port 554

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes

13:20:01.713725 IP 172.16.0.1.56509 > 192.168.0.200.554: Flags [S], seq 1737771977, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:20:02.705634 IP 172.16.0.1.56509 > 192.168.0.200.554: Flags [S], seq 1737771977, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:20:04.694546 IP 172.16.0.1.56509 > 192.168.0.200.554: Flags [S], seq 1737771977, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:20:08.694197 IP 172.16.0.1.56509 > 192.168.0.200.554: Flags [S], seq 1737771977, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:20:16.703544 IP 172.16.0.1.56509 > 192.168.0.200.554: Flags [S], seq 1737771977, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

The traffic is being received and forwarded to the correct IP and port. But there is no reverse NAT happening.

Here I ran TCPDUMP on the Ubuntu PC with the same rules, which was working:

####@Ubuntu:~$ sudo tcpdump -n --interface=tun0 port 81

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes

13:21:39.705604 IP 172.16.0.1.56517 > 172.16.0.100.81: Flags [S], seq 448973759, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:21:39.722259 IP 172.16.0.100.81 > 172.16.0.1.56517: Flags [S.], seq 237888001, ack 448973760, win 65535, options [mss 1460], length 0

13:21:39.896538 IP 172.16.0.1.56517 > 172.16.0.100.81: Flags [.], ack 1, win 64240, length 0

13:21:42.259338 IP 172.16.0.1.56517 > 172.16.0.100.81: Flags [P.], seq 1:3, ack 1, win 64240, length 2

13:21:42.259562 IP 172.16.0.100.81 > 172.16.0.1.56517: Flags [.], ack 3, win 65535, length 0

####@Ubuntu:~$ sudo tcpdump -n --interface=enp0s3 port 554

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes

13:23:21.862358 IP 172.16.0.100.56535 > 192.168.0.200.554: Flags [S], seq 3200998178, win 64240, options [mss 1351,nop,wscale 8,nop,nop,sackOK], length 0

13:23:21.879541 IP 192.168.0.200.554 > 172.16.0.100.56535: Flags [S.], seq 250752001, ack 3200998179, win 65535, options [mss 1460], length 0

13:23:22.044519 IP 172.16.0.100.56535 > 192.168.0.200.554: Flags [.], ack 1, win 64240, length 0

13:23:24.314366 IP 172.16.0.100.56535 > 192.168.0.200.554: Flags [P.], seq 1:3, ack 1, win 64240, length 2: RTSP

13:23:24.314601 IP 192.168.0.200.554 > 172.16.0.100.56535: Flags [.], ack 3, win 65535, length 0

Both devices have a fresh install of Ubuntu with the exact same NAT rules.

Does anybody know what the issue might be?

3

Hi,
We don’t have much experience in the use-case. Would need other user to share suggestion.

For Xavier NX, the two latest releases are Jetpack 4.6.3 and 5.1.1. You may try the releases and see if either one works.

5

Have same problem here on an NX with Jetpack 5.1.

Forwarding Config in the NX:

$ sudo iptables -t nat -L --line-numbers -n -v
...
6        0     0 DNAT       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080 to:172.31.254.2:8080
...

When connecting to port 8080 the packages arrive at the extern interface eth0:

$ sudo tcpdump -n --interface=eth0 port 8080
...
17:03:21.180971 IP 192.168.1.122.49440 > 192.168.13.195.8080: Flags [S], seq 755876140, win 64240, options [mss 1460,sackOK,TS val 2022915643 ecr 0,nop,wscale 7], length 0

But are not forwarded to the internal VLAN interface eth0.196

$ sudo tcpdump -n --interface=eth0.196 port 8080
...

Equivalent rules in a regular ubuntu desktop or ZynqUltrascale arm64 with debian are working

6

Had to resort to forwarding ports via socat ( socat port forwarding for https - Stack Overflow ) because we couldnt get iptables to work on Xavier NX.

7

This solution is not ideal as a lot of features of iptables can not be implemented with socat such as forwarding of port ranges for example which is still a problem for us.

8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.