Port forwarding with RUT241 not working

[frankvu]

Hi there! We have this scenario

The goal is to forward incoming traffic on ports 80 and 443 to the webserver. I tried with DMZ, a setup that used to work on a RUT950 running RUT9XX_R_00.03.410 firmware. No luck. Then I tried to set up two port forwards, no luck either. As there was a configuration issue on the upstream router/firewall, many tests were performed. At this moment telnetting the webserver from the RUT on ports 80 and 443 leads to a connection, so at least that part seems OK. However, I have the impression that on the RUT cumulative configurations and reversals do not necessarily lead back to the initial, desired state. Eg, have a look at this

-A zone_mob_forward -m comment --comment “!fw3: Custom mob forwarding rule chain” -j forwarding_mob_rule

and

Chain forwarding_mob_rule (1 references)
target prot opt source destination

Chain forwarding_rule (1 references)

That’s an empty chain, and that looks suspicious, doesn’t it?

So, my questions:

1. is my interpretation of the behavior that you cannot be certain to revert to a previous state correct?
2. how should I be able to make the required forwards work? Don’t really mind if it’s DMZ or specific forwards based.
3. is there a way to reset the RUT’s firewall to factory defaults without resetting the entire device? It’s installed at a hosting facility so a full reset would require an on-site intervention.

Note: the setup with the RUT950 was slightly different in the sense that there the webserver and the RUT’s LAN interface were in the same subnet.

Thanks in advance!

[AndzejJ]

Hello,

It would be great to know what firmware version is installed on RUT241 now, and what port-forwarding rule you have configured.

Also, since there are two networks, and you can reach the webserver from the RUT, but not via port-forwarding, the issue can be related to networking. You could try enabling masquerading on LAN zone in Network → Firewall → LAN => WAN zone. This way, when the packets are forwarded to the server, they will appear as if they are coming from RUT241.

Could you also run a tcpdump from RUT241? You can install it via opkg:

opkg update
opkg install tcpdump
# wwan0 is for mobile interface, but on the latest firmware it can be 'qmimux0'
tcpdump -i wwan0 port  8080
tcpdump -i br-lan port 8080

Kind Regards,

[frankvu]

Hi Andzej, thank you for your reply. It definitely helped me looking in the right direction.

The RUT241 is currently running firmware RUT2M_R_00.07.04.5

In the mean time I applied the command explained here How to reset firewall to default - Crowd Support Forum | Teltonika Networks (teltonika-networks.com) to bring the firewall back to a reasonable state.

I added a new forwarding rule just for port 80 for the time being, like this:

http fwd
IPv4 tcp
From any host in wan
Via any router IP at port 80
IP 10.10.20.21, port 80 in lan

and enabled masquerading as you suggested

Then, after installing tcpdump on the RUT241 I went back to testing, using

telnet 10.42.0.66 80

root@RUT241:~# tcpdump -vv -i br-lan port 80
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
10:25:08.816272 IP (tos 0x0, ttl 62, id 51884, offset 0, flags [DF], proto TCP (6), length 60)
10.10.19.4.53046 > 10.10.20.21.80: Flags [S], cksum 0xa43d (correct), seq 710845466, win 14600, options [mss 1450,sackOK,TS val 585199286 ecr 0,nop,wscale 8], length 0
10:25:08.818165 IP (tos 0x0, ttl 63, id 0, offset 0, flags [none], proto TCP (6), length 60)
10.10.20.21.80 > 10.10.19.4.53046: Flags [S.], cksum 0x6c81 (correct), seq 443798409, ack 710845467, win 65160, options [mss 1460,sackOK,TS val 3895172088 ecr 585199286,nop,wscale 7], length 0
10:25:08.890231 IP (tos 0x0, ttl 62, id 51885, offset 0, flags [DF], proto TCP (6), length 52)
10.10.19.4.53046 > 10.10.20.21.80: Flags [.], cksum 0x9976 (correct), seq 1, ack 1, win 58, options [nop,nop,TS val 585199324 ecr 3895172088], length 0

and

root@RUT241:~# tcpdump -vv -i wwan0 port 80
tcpdump: listening on wwan0, link-type RAW (Raw IP), capture size 262144 bytes
10:34:28.174208 IP (tos 0x0, ttl 63, id 61107, offset 0, flags [DF], proto TCP (6), length 60)
10.42.0.1.53047 > 10.42.0.66.80: Flags [S], cksum 0xcdda (correct), seq 1230546827, win 14600, options [mss 1460,sackOK,TS val 585255224 ecr 0,nop,wscale 8], length 0
10:34:28.176678 IP (tos 0x0, ttl 62, id 0, offset 0, flags [none], proto TCP (6), length 60)
10.42.0.66.80 > 10.42.0.1.53047: Flags [S.], cksum 0xcc84 (correct), seq 901642471, ack 1230546828, win 65160, options [mss 1450,sackOK,TS val 3895731445 ecr 585255224,nop,wscale 7], length 0
10:34:28.243124 IP (tos 0x0, ttl 63, id 61108, offset 0, flags [DF], proto TCP (6), length 52)
10.42.0.1.53047 > 10.42.0.66.80: Flags [.], cksum 0xf974 (correct), seq 1, ack 1, win 58, options [nop,nop,TS val 585255257 ecr 3895731445], length 0

I stopped the capture when after several seconds nothing further happened.

This seems to suggest that all traffic is properly forwarded, doesn’t it?

So then I repeated the same telnet test from the rut241, with success:

(had to reduce the number of screenshots as I am only allowed to add 1…)
so for now the question seems to be why does it work properly when starting from the 241, but not with forwarding?

The rest of the problem indeed looks like a networking problem higher-up, I will have to discuss that with our hosting company (it looks like 10.10.20.21, the webserver, isn’t aware that traffic for 10.42 should go through the RUT).

Thanks in advance for your help!

[frankvu]

Still struggling…

In the hope of getting a better insight in the exchanged data I exported the captured data of attempts to my computer to have a look at them with Wireshark

Then I loaded the third frame (that in a working scenario indicates that the connection is established and the dialog can start) in WinMerge. I copied the what I think is the problem in the screenshot below. The third frame is sent by the originating system, ie the client running telnet … 80

The left side is from a working conversation (ie, from the RUT241 to the backend webserver), the right side from another system in the APN, via the RUT241. However, that client computer never gets the “Connected to …” message.

I also looked that the wwan interface, same behavior (co conversation completeness is also Incomplete, established. The other side is a RUT950 running firmware RUT9XX_R_00.03.410. It’s in production (see above) and seems able to discuss just fine from and to the APN.

I have absolutely no idea where this difference in behavior comes from. Could it still be the underlying network infrastructure? Can anybody help me?

Thanks in advance!

[frankvu]

In the end it was a combination of a network infrastructure upstream and unexpected behavior of the telnet client on the RUT241: when its connection is established, it doesn’t mention that on the console. However, just go ahead and type, and the data will be sent to the other side.

One only has to know