Forwarding port 443 breaks my internet

I'm trying to forward port 443 in order to gain access to a webapp I'm hosting. This is on OpenWrt 22.03.0 on a Belkin RT3200 WiFi 6 Router (AX3200). In order to do this I have:

  1. Set up Caddy to point to my domain name
  2. Changed uhttpd so that it runs from ports 81 and 444 so I can still access LUCI.
  3. Port forwarded TCP on 80 from which I can successfully reach my web app through HTTP
  4. Port forwarded TCP on 443 which is where I am struggling.

When I forward TCP and UDP on 443, my internet breaks which apparently may be because QUIC on Chrome runs on 443 UDP. So when I forward just TCP on 443, Google search sort of still works but all https websites return a 'not secure' error.

What's the best way to sort this out?

Let’s see your firewall config

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/firewall
1 Like

Thanks. Sure.

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list device 'tun0'
        list network 'lan'
        list network 'wan'
        list network 'wan6'
        list network 'Aquiss'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config redirect
        option target 'DNAT'
        option src 'wan'
        option src_dport '2342'
        option dest_ip 'redacted'
        option dest_port '2342'
        option name 'redacted'
        option dest 'wan'

config zone
        option name 'IOT'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config forwarding
        option src 'lan'
        option dest 'IOT'

config redirect
        option target 'DNAT'
        option name 'caddy2'
        option src 'wan'
        option dest_ip 'redacted'
        option src_dport '80'
        option dest_port '80'
        option dest 'lan'
        list proto 'tcp'

config redirect
        option target 'DNAT'
        option name 'caddy2'
        option src 'wan'
        option src_dport '443'
        option dest_port '443'
        option dest_ip 'redacted'
        list proto 'tcp'
        option dest 'lan'
        option enabled '0'

Just been through the options and I'm guessing I may need to set the external IP address first?

Those look fine.

Are you trying to access the web luci interface for openwrt via the wan?

If you forward/redirect port 443, https detects this and gives the error. This is how https is designed to work ie to give the dire warning to the user that something dodgy is going on.

The lan network is in two zones. A network can only be in one zone. The only network in the wan zone should be wan and wan6 if you are using IPv6.

Also both of your redirect rules have the same name, that could be a problem. In the rule, dest_ip is the LAN IP of the web server (there's no need to redact it, as it only has meaning inside your network). Do not have the WAN IP in the firewall.

Forwarding incoming connections won't affect outgoing activity. The firewall is stateful in both cases.

1 Like

Nope. I am hosting a filebrowser docker container behind my router which I'm trying to get access to outside the local network.

Initially when I port forwarded 80, it broke LUCI and also stopped my WAN/internet access, I was only able to fix this by reverting changes through the command line (SSH).

I realised that this might be a UHTTPD thing so I changed the LUCI ports to 81 and 443 (/etc/config/uhttpd), this allowed me to access the WAN and LUCI. However, now changing it to port forward 443 for HTTPS instead (since there is a login and I don't want the password exposed) broke the internet as well.

I thought that this might be because of QUIC and tried forwarding only the TCP ports on 443 - this allowed the port forward to work but seemed to have the side effect of restricting my access to certain websites - Google and OpenWRT for example was working but Reddit and others returned from a Google search was not.

While posting the firewall settings here I realised that LUCI also had options for the external IP address. The default settings was both the external IP as well as the internal one (192.168.1.1). Deselecting the internal IP seems to have solved these issues. Can anyone give an ELI5 explanation of why this is the case please? In my mind they are referring to one another which is the problem.

This kinda took 5 hours to sort out so was rather painful.... :confused:

The default and recommended configuration is that uhttpd/LuCI will listen on all router addresses, but blocked from wan, guest, or IoT access by the firewall. A redirect of incoming 80 or 443 ports has precedence over the internal service-- even if uhttpd were listening on those ports, it would never see packets from wan.

I also see tun0 in there. If you are tunneling the whole house through a VPN there are special considerations to make a local web server workable. With standard routing, the replies from the web server will be routed into the VPN tunnel instead of direct to the Internet like they need to be.

1 Like

I do have OpenVPN installed but it is currently disabled and has been for a while now. What considerations does one have to make to forward with tunnels enabled please?

Why is the lan network (and maybe the aquiss one too) in the wan zone. This is probably the root of your issue.

Aquiss is the ISP - not sure if it should be under LAN rules or WAN rules. Its a combined router/modem and the cable is plugged into LAN Port 6 (labelled internet on the box). Config file examples suggested WAN.

Not sure re LAN in WAN either. Must have been from when I set it up and made a mistake. Removed it now and please find the updated config attached below.

Setting the "external IP address" under "advanced settings" tab of the port forwarding section explicitly to my static IP solved the no internet issue for some reason (this is the "option src_dip" option under "config redirect").

I have additionally also made the changes you've suggested.

        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list device 'tun0'
        list network 'Aquiss'
        list network 'wan'
        list network 'wan6'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config zone
        option name 'IOT'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config forwarding
        option src 'lan'
        option dest 'IOT'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest_ip '192.168.1.114'
        option src_dport '80'
        option dest_port '80'
        option dest 'lan'
        list proto 'tcp'
        option src_dip 'redacted'
        option name 'caddy2 HTTP'

config redirect
        option target 'DNAT'
        option src 'wan'
        option src_dport '443'
        option dest_port '443'
        option dest_ip '192.168.1.114'
        list proto 'tcp'
        option dest 'lan'
        option src_dip 'redacted'
        option name 'caddy2 HTTPS'

config forwarding
        option src 'lan'
        option dest 'wan'

While orthogonal to your question, consider running services like these (as I don't assume you need to serve this to the whole world, but only yourself and maybe a few family members) behind a VPN (e.g. wireguard) - this both eases the setup and improves security (a lot).

1 Like

Thanks. I can appreciate the idea of safety and security and would myself also ideally not want to share it at all from home. My use case however is with people who don't live in the same home and the aim is to access files only otherwise available from a set location (normally synced with Syncthing between our home PCs). The ease of use for them drastically drops when a VPN setup is used. For security, what I've done at the moment is also reverse proxied the service (and other services) so that I only need to expose ports 80 and 443 - not quite sure if this is enough pro tem.

I'm also considering reverse proxying chaining it - not sure if this was what you meant:

USER -> CADDY (VPS) -> WIREGUARD -> OPENWRT (ROUTER) -> CADDY (HOME) -> SERVICES

instead of

USER -> OPENWRT (ROUTER) -> CADDY (HOME) -> SERVICES

Not sure which is best but I don't have time for the next few weeks at least to explore the more complicated option.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.