Rutx09 Port Forwards not working

NETWORKING SOLUTIONS
1

Hello,

I have a fresh “Restore to factory default” Rutx09 with firmware version RUTX_R_00.07.06.3.

For testing the WAN port is connected to a 192.168.1.0/24 lab network with WAN IP 192.168.1.166 and all clients that are used to test are also the same network (ex, 192.168.1.10).

The Rutx09 LAN network is 10.10.123.0/24, with an internal IP that I want to forward TCP port 1880 is 10.10.123.114 (Vinverter.lan).

Image of port forward rule:

Screenshot 2024-02-15 094332
Screenshot 2024-02-15 094332572×533 18 KB

Image of advance settings
Screenshot 2024-02-15 102010

Rutx09 CLI welcome msg:

-----------------------------------
     Teltonika RUTX series 2024
-----------------------------------
   Device:     RUTX09
   Kernel:     5.10.199
   Firmware:   RUTX_R_00.07.06.3
   Build:      9b07149879
   Build date: 2024-01-12 14:47:21
-----------------------------------

Internal LAN IP is responding to port 1880 via CURL:

root@RUTX09:~# curl http://10.10.123.114:1880
<!DOCTYPE html>
<html>
<head>

I also tried using the WAN IP (NAT loopback is enabled):

root@RUTX09:~# curl http://192.168.1.166:1880
curl: (7) Failed to connect to 192.168.1.166 port 1880 after 0 ms: Error

Now lets test from a client on the 192.168.1.0/24 network:

root@192.168.1.10:~# curl http://192.168.1.166:1880

Nothing it just hangs.

Now let see what tcpdump shows on the Rutx09:

root@RUTX09:~# tcpdump -i br-lan port 1880
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:12:19.787921 IP 192.168.1.10.47840 > Vinverter.lan.1880: Flags [S], seq 2530448646, win 64240, options [mss 1460,sackOK,TS val 411604439 ecr 0,nop,wscale 7], length 0
18:12:20.815780 IP 192.168.1.10.47840 > Vinverter.lan.1880: Flags [S], seq 2530448646, win 64240, options [mss 1460,sackOK,TS val 411605465 ecr 0,nop,wscale 7], length 0
18:12:21.833383 IP 192.168.1.10.47840 > Vinverter.lan.1880: Flags [S], seq 2530448646, win 64240, options [mss 1460,sackOK,TS val 411606485 ecr 0,nop,wscale 7], length 0

Also we can access the Rutx09 Web UI via WAN from the same 192.168.1.0/24 client

root@192.168.1.10:~# curl http://192.168.1.166:80
<!DOCTYPE html>
<html lang="en">
  <head>

I also tried enabling the DMZ rule for the 10.10.123.114 IP and I’ve tried this port forwarding rule on several other Rutx11’s we have in our lab with the same results. Any suggestions is greatly appreciated!

Thanks,
Lael

2

Hopefully I can get some suggestion or advice for my issue above.

Thanks!

4

Hello,

Indeed, the issue seems strange.
Are you by any chance also using a mobile connection on the RUTX09? If so, could you try navigating to Network → Failover → Multiwan, enable the available WAN interfaces and change the operating mode to Load Balancing? This would help if the mobile interface has a higher metric compared to the wired WAN. However, this is not guaranteed to help, as it doesn’t explain the TCPdump output where the LAN device is not responding.
Could you also try capturing a TCPdump without the port filter? Instead, use IP 10.10.123.114 as the filter. We’ve experienced issues in the past where devices utilize multiple ports for communication and port forward fails when the other port is inaccessible.
Lastly, this is a long shot, but could you try enabling masquerading on the LAN zone by navigating to Network → Firewall → General Settings to check if perhaps the source IP of a different network could be causing the issues?

Let me know how it goes.

Best regards,

5

Thanks for the reply.
This is a very simple testing setup, a factory fresh reset rutx09, with only the WAN via ethernet (No SIM card for mobile) with our LAB network IP 192.168.1.166 and a single RPI on the LAN side with IP 10.10.123.114.

tcpdump without port filter:

root@RUTX09:~# tcpdump -i br-lan host 10.10.123.114
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:09:40.008188 IP 192.168.1.10.38356 > Vinverter.lan.1880: Flags [S], seq 914600089, win 64240, options [mss 1460,sackOK,TS val 843444352 ecr 0,nop,wscale 7], length 0
18:09:41.025239 IP 192.168.1.10.38356 > Vinverter.lan.1880: Flags [S], seq 914600089, win 64240, options [mss 1460,sackOK,TS val 843445369 ecr 0,nop,wscale 7], length 0
18:09:42.044881 IP 192.168.1.10.38356 > Vinverter.lan.1880: Flags [S], seq 914600089, win 64240, options [mss 1460,sackOK,TS val 843446389 ecr 0,nop,wscale 7], length 0

Now for the long shot, enabling masquerading on the LAN zone:

Success!

root@192.168.1.10:~# curl http://192.168.1.166:1880
<!DOCTYPE html>
<html>
<head>

But why? I’m not clear by what you mean “source IP of a different network could be causing the issues?”

Source IP 192.168.1.166 or the client IP 192.168.1.10? Because I’ve tried from other client IP’s and then we also have seen the same behavior with several other rutx11 which all get different DHCP WAN ip’s from our LAB router? The is no other device on our LAB network using the same IP (192.168.1.166).

Thanks.

6

Hello,

If the packet is originating from 192.168.1.0/24, and no 10.10.123.0/24 network is present on any other networks in the middle, the issue is likely related to the default gateway not being set on the Vinverter.lan device. Since it’s using DHCP, it does seem odd, but we have seen some IoT devices that do not have an option for the default gateway.
If this is the case, then I’d simply suggest leaving the masquerading enabled for the LAN zone, and if you need other devices in the RUTX network to avoid NAT, maquarading can be restricted only to the single 10.10.123.114/32 source host in the advanced settings of the LAN zone in the firewall settings.

Best regards,

7

Thank you so much, that’s the info I needed. The issue was due to the RPI device having two default gateways because the WLAN (wifi) interface was enabled and connecting to the same LAB (192.168.1.0/24) network. I disabled the RPI wifi interface and disabled masquerading on the LAN zone; now port forwards works as expected!

Thanks again!

8

Glad to hear that!
Let us know if any further issues arise.

Best regards,

9

This topic was automatically closed after 15 days. New replies are no longer allowed.