Want to use different ports for 80 and 443, or even better, just forward them internally

wizcourage · January 24, 2025, 8:16pm

I have a Synology NAS, which has hard-coded ports 80 and 443 for their own reverse proxy implementation, but I want to use NGINX. ChatGPT suggested to change the defaults in the uHTTPd service, but I think it would be better to keep ports the same, but just forward them differently, similarly how this guy recommended here, at Post #9.

What you could do is not change the HTTPS port (which is 443) but make the firewall translate the requests from your custom ports to a 443. That is a bit cleaner than hacking the webif setup (which does not seem to contain any option for changing the port at first sight).

There are a few more ways to go about this, but I lean towards the following, in this setup:

I have a few firewalls/vlans, at 192.168.1.1 is my router, and at 192.168.4.1 is my NAS. They route properly and everything is fine.

I want to initialize my reverse proxy app (in docker), since 80 and 443 and taken by Synology, with no easy way of changing them, I want to change what my own reverse proxy app (NGINX) listens to, which let's say is 81 and 10443. Then I want the router to know that in my NAS Firewall/VLAN subnet 81 and 10443 are actually ports 80 and 443.

So I guess I need to forward them, not with traffic rules, but with port forwarding. Which I did both anyway to try, but didn't succeed.

Basically I mapped External IP/VLAN to Internal IP/VLAN 443 (Device/router LAN) to 10443 (NAS) to accept, same for 80 to 81, and I did the opposite where I mapped 10443 (NAS) to 443 (Device/router).

Nothing worked, of course I changed the listening ports in my docker configuration.

I would not be able to post my configs immediately, however please let me know if the direction I've looked at is the correct one, maybe give me an example of how it should properly be implemented with an example template, I will try to get back with the configs asap if they are needed.

I can't access ssh for now, but here are some images where I tried all of these in all combinations, both traffic rules and port forwarding and only port forwarding or traffic rules, since I wasn't sure, these are the examples only for 443:

port forwards:

traffic rules:

trendy · January 24, 2025, 8:39pm

So basically all ports 80, 81, 443, and 10443 are on the NAS?
And what do you want to achieve? That traffic coming from LAN zone on port 80 to NAS to be redirected to 81 (and 443 to 10443)?

wizcourage · January 25, 2025, 6:16am

The NAS effectively hard codes 80 and 443, probably for their own reverse proxy, so I can't use my own instance of NGINX on those ports, it just blocks them. I can't simply remap this in the NAS (technically I can but it turns out it's a junky hack and Synology doesn't like it between updates), so I must do it on router level instead.

Now instead of totally remapping 80 to 81 and 443 to 10443, I would like to more optimally translate the requests between the firewall zones. I think this is possible, since it was mentioned here on Post #9.

Since the NAS is on another firewall, I want my NGINX on the NAS to listen to ports 81 and 10443, and all the 80/443 requests it receives and the 81/10443 it sends (let me know if only one rule is needed to cover sending/receiving or also the reverse rules) to actually be translated to 81/10443 when it reaches the NAS firewall, or received as 80/443 when it reaches the 192.168.1.0 subnet which is on the separate LAN firewall.

trendy · January 25, 2025, 5:32pm

You are over-engineering your answers and thus making it hard to understand you.
I asked 2 questions above, the first is yes/no.
The second is like "I want packets from lan firewall zone IPs 192.168.X.0/24 destination port XXX sent to IP 192.168.X.Y (could be either the OpenWRT or the NAS) to be translated to this IP and destination port."

wizcourage · January 25, 2025, 6:11pm

you are right I am over-engineering, probably because I don't know the full mechanism in work to explain it in simple matter. I just know that you can't use 443 and 80 on the Synology NAS at all, so I need to find a way around that.

So basically all ports 80, 81, 443, and 10443 are on the NAS?

I am not sure if I understand this, but I do want to use 10443 and 81 on the NAS firewall side.

And what do you want to achieve? That traffic coming from LAN zone on port 80 to NAS to be redirected to 81 (and 443 to 10443)?

I think yes, got a NAS zon and a LAN zone. I want the NAS to talk to ports 10443 and 81, while the LAN firewall to translate this to 443 and 80. So yes to your question, I just don't know if the direction matters, if it does, then I want traffic coming from NAS zone on port 81 to be forwarded to LAN zone on port 80 (same for 443/10443).

trendy · January 25, 2025, 9:05pm

I am not sure I fully understand you, but this is my best guess.

uci add firewall redirect
uci set firewall.@redirect[-1].dest='NAS'
uci set firewall.@redirect[-1].target='DNAT'
uci set firewall.@redirect[-1].family='ipv4'
uci add_list firewall.@redirect[-1].proto='tcp'
uci set firewall.@redirect[-1].src='lan'
uci set firewall.@redirect[-1].src_dport='443'
uci set firewall.@redirect[-1].dest_ip='192.168.4.4'
uci set firewall.@redirect[-1].dest_port='10443'
uci set firewall.@redirect[-1].reflection='0'
uci set firewall.@redirect[-1].src_dip='192.168.4.4'
uci add firewall redirect
uci set firewall.@redirect[-1].dest='NAS'
uci set firewall.@redirect[-1].target='DNAT'
uci set firewall.@redirect[-1].family='ipv4'
uci add_list firewall.@redirect[-1].proto='tcp'
uci set firewall.@redirect[-1].src='lan'
uci set firewall.@redirect[-1].src_dport='80'
uci set firewall.@redirect[-1].dest_ip='192.168.4.4'
uci set firewall.@redirect[-1].dest_port='81'
uci set firewall.@redirect[-1].reflection='0'
uci set firewall.@redirect[-1].src_dip='192.168.4.4'
uci commit firewall
service firewall restart

Replace 192.168.4.4 with the NAS IP. Also I suppose that the nas zone is with upper case letters. Fix it if it is not, OpenWrt is case sensitive.

wizcourage · January 25, 2025, 9:20pm

Here's the /etc/config/firewall of it, the rule doesn't work on my NAS, and I can't connect with https on my router 192.168.1.1 anymore, of course non-https works since I have not still forwarded port 80. The only difference is that family is auto instead of ipv4.

config redirect
	option dest 'NAS'
	option target 'DNAT'
	option name 'forward 443 router to 10443 nas'
	list proto 'tcp'
	option src 'lan'
	option src_dport '443'
	option dest_port '10443'
	option dest_ip '192.168.4.101'
	option enabled '1'

Here's a screenshot (I redacted the dest_ip here due to the mac address).

trendy · January 25, 2025, 9:26pm

It doesn't work because you made changes.
The family is not so crucial, as it has only IPv4 addresses, so it will be used only for IPv4.
But you didn't use src_dip='192.168.4.101' so you are trying to redirect all the traffic going to the router and not to the NAS.

wizcourage · January 25, 2025, 9:46pm

I see, thanks. I will check back when I get home. That src_dip is not assignable by the GUI (cannot see it on my screenshot)?

trendy · January 25, 2025, 9:48pm

It is in the advanced tab.

wizcourage · January 26, 2025, 10:01am

Perfect. openwrt works fine now! Although my nginx still doesn't seem to work.

Do I need to add the opposite rule too? 443 > 10443 and 10443 to 443?

Basically:

uci add firewall redirect
uci set firewall.@redirect[-1].dest='lan'
uci set firewall.@redirect[-1].target='DNAT'
uci set firewall.@redirect[-1].family='ipv4'
uci add_list firewall.@redirect[-1].proto='tcp'
uci set firewall.@redirect[-1].src='NAS'
uci set firewall.@redirect[-1].src_dport='10443'
uci set firewall.@redirect[-1].dest_ip='192.168.1.1'
uci set firewall.@redirect[-1].dest_port='443'
uci set firewall.@redirect[-1].reflection='0'
uci set firewall.@redirect[-1].src_dip='192.168.1.1'

trendy · January 26, 2025, 11:58am

No, the rule will not be matched as the 443 and 10443 are in source and not destination field.
Do a packet capture either on the NAS or on the vlan41 interface of OpenWrt to verify that packets are send with the proper headers.
opkg update ; opkg install tcpdump ; tcpdump -i br-lan.41 -vnn -c 10 hpst 192.168.4.101

wizcourage · January 26, 2025, 7:12pm

with the rule we just specified 443 only, here's the output of the command:

tcpdump: listening on br-lan.41, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:09:55.923840 IP (tos 0x0, ttl 64, id 26438, offset 0, flags [DF], proto TCP (6), length 171)
    192.168.4.101.5001 > 192.168.1.167.49219: Flags [P.], cksum 0xe187 (correct), seq 1101058478:1101058597, ack 369537892, win 304, options [nop,nop,TS val 655574169 ecr 431649533], length 119
19:09:55.926140 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.167.58668 > 192.168.4.101.5001: Flags [.], cksum 0x06ec (correct), ack 171960269, win 2046, options [nop,nop,TS val 2242653244 ecr 655574169], length 0
19:09:55.926176 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.167.49219 > 192.168.4.101.5001: Flags [.], cksum 0x164f (correct), ack 119, win 2046, options [nop,nop,TS val 431659551 ecr 655574169], length 0
19:09:56.154928 IP (tos 0x0, ttl 64, id 16452, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.4.101.10443 > 192.168.1.167.53705: Flags [.], cksum 0xdf0f (correct), ack 2458220555, win 295, options [nop,nop,TS val 655574400 ecr 1652823696], length 0
19:09:56.156817 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.167.53705 > 192.168.4.101.10443: Flags [.], cksum 0xd835 (correct), ack 1, win 2048, options [nop,nop,TS val 1652838745 ecr 655559351], length 0
19:09:59.179091 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 182)
    192.168.1.167.63271 > 192.168.4.101.5001: Flags [P.], cksum 0xb6fb (correct), seq 1289213211:1289213341, ack 2700274675, win 2048, options [nop,nop,TS val 3515920301 ecr 655572342], length 130
19:09:59.179150 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 153)
    192.168.1.167.63271 > 192.168.4.101.5001: Flags [P.], cksum 0xce55 (correct), seq 130:231, ack 1, win 2048, options [nop,nop,TS val 3515920301 ecr 655572342], length 101
19:09:59.180425 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 183)
    192.168.1.167.63271 > 192.168.4.101.5001: Flags [P.], cksum 0x0568 (correct), seq 231:362, ack 1, win 2048, options [nop,nop,TS val 3515920301 ecr 655572342], length 131
19:09:59.180458 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 153)
    192.168.1.167.63271 > 192.168.4.101.5001: Flags [P.], cksum 0x1abc (correct), seq 362:463, ack 1, win 2048, options [nop,nop,TS val 3515920301 ecr 655572342], length 101
19:09:59.193868 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.167.63271 > 192.168.4.101.5001: Flags [.], cksum 0x30ab (correct), ack 277, win 2043, options [nop,nop,TS val 3515920315 ecr 655577437], length 0

trendy · January 26, 2025, 9:06pm

You have bidirectional communication:

19:09:56.154928 IP (tos 0x0, ttl 64, id 16452, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.4.101.10443 > 192.168.1.167.53705: Flags [.], cksum 0xdf0f (correct), ack 2458220555, win 295, options [nop,nop,TS val 655574400 ecr 1652823696], length 0
19:09:56.156817 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.167.53705 > 192.168.4.101.10443: Flags [.], cksum 0xd835 (correct), ack 1, win 2048, options [nop,nop,TS val 1652838745 ecr 655559351], length 0

Therefore the translation is working properly and the reverse proxy is answering.

wizcourage · January 27, 2025, 5:46am

These requests don't seem to be to the router, *.167 is my PC and probably to my browser (port 53705) and the NAS, there is no NAS port 10443 to router 443 translation here?

the thing is even if I didn't really visit the proxy, the outputs happened on their own once in a while. I believe I tried it with the containers that are hosted offline too, communication continued in bursts. I am retesting now.

Also, the opposite rule worked the same as this one, but you mentioned these should be one directional originally?

Lastly, the proxy still does not work, now that might be due to other reasons that I am unaware of, but I can't be sure.

wizcourage · January 27, 2025, 9:47am

So I've tried multiple things, nothing works and actual communication indeed does not happen, take an example from this:

tcpdump -i any -vnn "(port 443 or port 10443) and host 192.168.4.101 and not host 192.168.1.122"

192.168.1.122 is my current machine I am trying to access this, so we don't need this.

192.168.4.101 is my nas, and 443 and 10443 are the ports in question. I get no output no matter what I try and as previously mentioned the reverse proxy does not work.

I also tried to forward inside the zone, since I think we don't even need to communicate to LAN zone at all? I am not exposing this to the internet. All I need is the router to translate NAS'es (192.168.4.101) 10443 port requests to 443 and vice versa, and for that I probably only need to communicate between the gateway on the firewall zone, which is 192.168.4.1, not outside the zone. But this also doesn't work, at least the way I've configured it.

trendy · January 27, 2025, 11:25am

The .167 IP is expected to be there, as the rule is translating the destination port.
If you translate the ports 80 and 443 on the router to become 81 and 10443 on the NAS, then you'll not be able to communicate with OpenWrt over http(s).

It is expected to get no output, you are excluding packets which have .122 which initiates the traffic.

Since it is getting complicated, let me break it down. Every packet has source IP, source port, destination IP and destination port in its headers. You can change/manipulate these on the OpenWrt firewall, but you need to know first what you want to change and into what. Then you can decide which firewall rule needs to be applied.

wizcourage · January 27, 2025, 12:18pm

https://youtu.be/S7p3_7YRaN4?si=FG-8Fz3yVz1zRBKu&t=768 (Timestamped, watch for less than a minute)

If all of this happens on the Synology NAS zone only, I don't think it matters if it openwrt interface is not reachable on 192.168.4.1, I can still reach it on 192.168.1.1?

This is all I need, yet, I just can't seem to get it working, damn, I am scratching my head hard.

EDIT 1:

I've also tried to following, used the same command, but with a different port to track:

tcpdump -i br-lan.41 -vnn host 192.168.4.111 and port 20492

This port 20492 is completely random, not even mapped to anything (checked synology pre-mapped ports too).

I tried to visit it from my machine and here is an output, basically the same as the previous one which seemed fine, it's just this time there is no port forwarding happening I just typed in a random non-existent port?

tcpdump: listening on br-lan.41, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:25:48.961729 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    192.168.1.132.62341 > 192.168.4.111.20492: Flags [S], cksum 0xe200 (correct), seq 1339461898, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1272601828 ecr 0,sackOK,eol], length 0
12:25:48.962132 IP (tos 0x0, ttl 64, id 35046, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.4.111.20492 > 192.168.1.132.62341: Flags [R.], cksum 0x0393 (correct), seq 0, ack 1339461899, win 0, length 0
192.168.4.111.20492

My point being, do we really have this working properly as the video instructed? Or have I failed to explain the issue on hand properly and we missed a direction?

EDIT 2:

Tried a hacky way of removing the Synology default ports (443 and 80) and now the reverse proxy works as it should. So it indeeds is an issue with the portforwarding on the router, nothing else. I have to get router level fix though, so the issue is not resolved.

trendy · January 27, 2025, 4:29pm

There is no port forwarding. Your packet had destination .111:20492 before and after it went through OpenWrt. It's mere packet forwarding as a router should do.

If nginx works fine, you may as well use the 81 and 10443 directly from the client on the lan side and verify that. The whole exercise with the translation is to use 80 and 443 from the client, which will then be translated to 81 and 10443 on the router before it is forwarded to the NAS.

wizcourage · January 27, 2025, 6:20pm

But isn't the output from the random port 20492 the same as it was on 10443, when you previously told me that there is correct port forwarding here:

But what I need is the NAS to only receive 10443 if 443 is sent to it. The NAS cannot receive 443 without malfunction. Is this what we did here?