Simple Port Forwarding not working

Installing and Using OpenWrt Network and Wireless Configuration
1

First time posting here. I’m trying to get a very simple port forward for a HTTPS local lan proxy implemented and it’s refusing to work for me. Everything I’ve looked at says it should work but I can’t see what I’m doing wrong (I did have this working on an older ASUS-Merlin router before it died). I’m running version OpenWrt 24.10.2 and have this as a forward:

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'HTTPS_Proxy_fwd'
        option src 'wan'
        option dest_ip '192.168.62.160'
        option reflection '0'
        option src_dport '39768'
        option dest_port '4443'
        list proto 'tcp'

checking the fw shows the expected entry

nft list chain inet fw4 dstnat_wan

table inet fw4 {
        chain dstnat_wan {
                meta nfproto ipv4 tcp dport 39768 counter packets 0 bytes 0 dnat ip to 192.168.62.160:4443 comment "!fw4: HTTPS_Proxy_fwd"
        }
}

The other additional fw rules are there as well:

nft list chain inet fw4 forward_wan | grep dnat
      ct status dnat accept comment "!fw4: Accept port forwards"
nft list chain inet fw4 input_wan | grep dnat
      ct status dnat accept comment "!fw4: Accept port redirections"

When I try to connect to this port from the WAN the packet counters don’t change. Doing a tcpdump clearly shows the packets hitting the wan interface so I know they’re coming in (I’m also running a OpenVPN server as well on another port and that’s working just fine so it’s not an ISP blocking issue). tcpdump on the LAN also shows nothing there as well. netstat does not show my src port being listened to but I’m unclear if it’s supposed to as there is no local process to listen, just forward via the firewall (is that a correct assumption?). I do see openvpn listening on the correct port. Also tried making the src/dest ports the same but no difference. Tried adding an accept in the Traffic Rules (I know I shouldn’t have to, no difference).

Also curious is that if I turn the forward rule into “send everything”

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'HTTPS_Proxy_fwd'
        option src 'wan'
        option dest_ip '192.168.62.160'
        option reflection '0'
        list proto 'all'

I get traffic but no port remapping. Unfortunately, it turns that local IP into a DMZ and it’s not really an option I want. Would appreciate any suggestions.

2

You will not see listening socket for dnat filter.
What is your hardware? ubus call system board

Do you use multiple routing tables for vpn vs no vpn?

Check conntrack -E /-L for the connection being established?

Rul€ is correct (all them)

3

Here’s the hardware

    "kernel": "6.6.93",
        "hostname": "gateway",
        "system": "ARMv8 Processor rev 4",
        "model": "GL.iNet GL-MT6000",
        "board_name": "glinet,gl-mt6000",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.2",
                "revision": "r28739-d9340319c6",
                "target": "mediatek/filogic",
                "description": "OpenWrt 24.10.2 r28739-d9340319c6",
                "builddate": "1750711236"

I have both an openvpn server and a client running, server when I need to work remote and client to connect to a 3rd party VPN provider. I’m using PBR to do split routing through either the VPN provider or the wan directly depending on the local device’s needs. The local HTTPS proxy is routed back via the wan with a PBR entry as that’s where the incoming connection is made.

Ah, install conntrack first. conntrack shows packets as UNREPLIED when it hits the wan. I’ve also disabled the openvpn server and client and disabled PBR and it makes no difference, still UNREPLIED. I have no idea why they're bouncing of the interface and not going through.

4

UNREPLIED means they did not get routed properly, check PBR config and exclude the port.....

5

option src_dport '39768'

You have a mistake, there's an extra letter.

6

Where is the extra letter?

7

I was wrong, please ignore it.

8

Ah, you may have missed my earlier comment. I turned off PBR (and both vpn server and client) and tried again but was still receiving an UNREPLIED when it hits the router's WAN which is really annoying because AFAIK this should be "plain vanilla" and just work.

Just to try it I added the following PBR prerouting policy (is it correct??)

config policy
        option name 'HTTPS_Proxy'
        option src_addr '192.168.62.160'
        option interface 'wan'
        option src_port '4443'
        option proto 'tcp'
        option dest_port '39768'

but again no response. I assume prerouting is the correct chain as I'm using it with other local devices to bypass the VPN provider. Should I use option chain forward instead?

I also tried

config policy
        option name 'HTTPS_Proxy'
        option src_addr '192.168.62.160'
        option interface 'wan'

and no response (this should send anything from src_addr to the wan?). I'm a little fuzzy on the PBR stuff, I'm assuming it does routing from LAN to another interface whereas port forwarding is from the WAN to the LAN. I'm running out of ideas to try.

9

Can we see the result of

tcpdump -nnvvi any tcp port 39768 or port 4443 -c 20

Redact the public IPs.

10

Okay, feel like a real fool here.

My feeble brain was having difficulty interpreting tcpdump and conntrack outputs. Went into my ISP's router to double check it's settings (my router is behind the ISP's) and confirmed it was set up as a DMZ. Did a bit more research on it and it turns out it's not really a DMZ even though it's documented as such in the UI. Turns out "DMZ" only means forward it's WAN IP to the DMZ LAN IP and nothing else. I had a look at the Port Forwarding part of the UI and discovered to my surprise forwarded ports for the openvpn client and server which I had totally forgotten doing (years ago). Added the 39768 port here and now it works.

Thanks for helping out, I'll go skulk off somewhere for a while...