Port forward not forwarding ports

[karlandtanya]

summary: When I enable port forwarding, the outside traffic is not forwarded but instead just goes to the openwrt itself. I'm using wireguard as a device, not openVPN. My ISP permits the incoming connections to port 44818 (just a port I'm using to test with). Listening from openwrt itself the outside connections are working. But I want openwrt to forward the traffic to a different computer where I want to run my server so I can connect to that server from outside. However openwrt is not forwarding the traffic.

Can anyone help me here or tell me what more information I should provide to ask a better question?

Long version follows:

I'm using OpenWrt 22.03.0, r19685-512e76967f on a raspberry Pi

There are 4 "devices":
br-lan (bridged to eth0, and in the "LAN" zone).
eth0 (not in any zone),
eth1 (in the "outside" zone, physically connected to the modem),
wg0 (in the "wan" zone; this is the wireguard device)

There are 3 interfaces:
br-lan is bridged to eth0 where the internal network is connected.
eth1 is the uplink to the fiber modem.
wg0 is the wireguard interface.

There are 3 zones:
The "LAN" zone is br-lan (physically connected to eth0, and the devices inside the house).
The WAN zone is the wireguard interface. All input/output/forwarded traffic forwarded from the lan zone to the wan zone is accepted. Only output traffic from the wan zone is accepted and masquerading from the wan zone is turned on.
The "Outside" zone only forward traffic from the outside zone is accepted.

I added a forwarding rule to send port 44818 to the computer at 10.10.137.233 (same port)

I also added a firewall rule to permit the above traffic:

If I listen to port 44818 at 10.10.137.233 and try to telnet in from the LAN, it works. That's just telnetting from one computer in the house to the computer where I want to run the server.

But, if i listen to port 44818 at 10.10.137.233 and try to telnet in from the outside, the connection is rejected. This is the outside traffic which I want opwnwrt to froward to 10.10.137.233. That telnet connection targets the public IP address assigned to openwrt by the ISP,

Finally, if i listen to port 44818 from openwrt and again try to connect from the outside, it is successful. That telnet connection also targets the public IP address assigned to openwrt by the ISP.

This tells me that my ISP is letting the traffic through and it's arriving at the openwrt router. But openwrt is keeping this traffic to itself rather than forwarding it to the computer that I want things to connect to.

[ncompact]

@karlandtanya

public IP address assigned to openwrt by the ISP

first step (it could be obvious) but it is better to verify the assigned ip address is public?

how to verify the ip address assigned to the wan interface must be the same as the one reported for example by performing this test:

https://whatismyipaddress.com/

[appelsin]

@karlandtanya

masquerading from the wan zone is turned on.

You mean "to" the wan zone.

And it would be less confusing if you renamed the zone with wg0 to "vpn", and went back to calling the zone with eth1 "wan".

if i listen to port 44818 from openwrt and again try to connect from the outside, it is successful.

OK, so apparently openwrt has a WAN IP that you can talk to, that's good.

if i listen to port 44818 at 10.10.137.233 and try to telnet in from the outside, the connection is rejected.

Are you sure it does not just time-out?

"Rejected" has a specific meaning, namely that telnet immediately drops out and says "connection reset by peer" or similar.

This is the outside traffic which I want openwrt to forward to 10.10.137.233.

You made a forwarding rule to allow this, so that is great.

This tells me that my ISP is letting the traffic through and it's arriving at the openwrt router.

Yes, ok.

But openwrt is keeping this traffic to itself rather than forwarding it to the computer that I want things to connect to.

I think you are jumping to conclusions here. And anthropomorphizing the openwrt router a bit.

But we can verify this easily.

Run wireshark on 10.10.137.233 and see if you get a connection initiation ("SYN") packet from the remote end.

You can enter "tcp.port eq 44818" in the display filter line after installing and starting wireshark on the "lan" interface of that computer.

My guess is that you will also see a reply being generated (a SYN-ACK) from 10.10.137.233.

Can anyone help me here or tell me what more information I should provide to ask a better question?

I think you did pretty well!

As far as helping you, hmm...

I think that 10.10.137.233 probably receives the connection initiation and does generate a reply.

And I think it might work better if you enable masquerade into the zone with the eth1 interface (towards your fiber) as well.

Otherwise the reply from 10.10.137.233 will end up having a destination IP that, according to your current routing table, should go into the wireguard tunnel (where it does not belong).

If masquerading towards the the fiber was enabled, I would think the reply packet would get its destination IP rewritten by openwrt to the WAN IP that the connection originally arrived on, and I think this would happen just before the reply packet hits the route table in openwrt, so that it instead will end up on your fiber.

But this is just guess-work...

If you do get wireshark installed and run it with the display filter I showed, we can verify it. I can show you how to do a more full packet capture on openwrt that includes everything and view it in wireshark afterwards.

[appelsin]

@karlandtanya

what more information I should provide

No big deal but if you really want, I can make one suggestion....

It took a bit of imagination to figure out what the wg0 interface was for.

wg0 could have been configured for client vpn with your laptops and tables out in the world "road warrior"ing in.

wg0 could have been a site-to-site vpn to somewhere where your servers are hosted.

wg0 could have been a "vpn" as in a modern "privacy vpn".

Different routing tables required for each of those.

Hope I guessed correctly.....

(maybe the wg0 zone should just be called "mullvad" )

[karlandtanya]

the ip address is public, BUT the ISP looks like it's blocking the port.

[karlandtanya]

Wireshark provided the detailed answer:

Telnetting to the public ip address 98.31.58.100 from inside the house routed the packets to openwrt on eth0 (the inside interface). Those packets never appeared on eth1 (the interface conected to the modem).

So, the traffic was never really going through the ISP and presumably the ISP blocks incoming connections (as most of them do these days...).

[appelsin]

@karlandtanya

Wireshark provided the detailed answer

Awesome!

@karlandtanya

presumably the ISP blocks incoming connections

What kind of IP address do you get on the fiber?

{ 10.0/8, 100.64.0/10, 172.16.0/12, 192.168.0/16 } these are all non-routable on the global internet.

Anything else should be fine.

ISP blocking depends on country and such, where I am the default ISP filter is just "reject outbound tcp port 25".

Is there a public IPv6 address on the fiber interface? We can also try reaching that from the public internet.

(If you then need to reach something on the inside that is IPv4-only, via a public IPv6 address, you could configure eg. interface wg1 to act as a client-vpn gateway that accepts VPN connections on IPv6 and routes IPv4+IPv6 to inside.)

There are also various paid solutions of course. I've seen people buy the cheapest VPS server with a public IPv4, configure a site-to-site tunnel between the VPS and openwrt, and just backhaul all traffic to the public IP back to openwrt. Also exists specialized solutions like ngrok.

Many other ways to do it...

But check the fiber IP first & see what range it falls into.

EDIT:

@karlandtanya

the ip address is public, BUT the ISP looks like it's blocking the port.

Oops, missed this one, sorry.

Hmm okay. Maybe it has reachable IPv6 though?