Accessing same external resource - works from outside, not from inside

Skylark13 · March 16, 2026, 3:51pm

Hello,

I am trying to get access to an internal resource working the same from outside my local network than from inside. Of course, the root of the problem is my lack of knowledge, I'm trying to figure it out but this is not my area of expertise. I don't think the resource is that important (it's NextCloud, and I find it really annoying that it doesn't respect relative paths and just assumes you will access it from an external domain name, but it is what it is).

I will access it through let's say https://nextcloud.example.com/ so I have my external domain, nextcloud.example.com which I've set up as a dynamic DNS record to my external IP. In OpenWRT I have set up a port forward for the wan at port 443 to the internal IP of the machine running my reverse proxy (10.0.1.2), at its own port 443. And on that machine, I have Nginx Proxy Manager taking requests from port 443, and I have a proxy defined so that when the source is nextcloud.example.com, it will proxy to the machine running NextCloud (10.0.1.5) at port 11000 (which is what NextCloud runs on). I need this extra proxy because I want to access through HTTPS with a certificate generated by LetsEncrypt for my domain (and I need to use the DNS challenge since I cannot use the HTTP challenge).

This all works fine when I use say my phone on the mobile network, or a machine outside my home network. It does not work when I try from a machine on my home network, or my phone on my home wifi. The specific error is a timeout ("The server at nextcloud.example.com is taking too long to respond.")

I think it's because it only replies to requests from the wan, and even if I use the full address to access it, OpenWRT knows the internal clients can access that IP directly and so it doesn't route through the domain and port forward? But I'm not sure.

Part of the problem might also be that OpenWRT's management interface runs on port 443 (lan only of course). So requests can come in from the wan IP at port 443 and be forwarded, but if something hits the lan interface it won't get to the right place. But maybe I'm also misunderstanding something there.

Here is my /etc/config/firewall, let me know if any other configs are required to troubleshoot this.

/etc/config/firewall

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

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option log '1'
        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 network 'wan'
        list network 'wan6'

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 zone
        option name 'tailscale'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option mtu_fix '1'
        list network 'tailscale'

config forwarding
        option src 'lan'
        option dest 'tailscale'

config zone
        option name 'wg'
        option input 'ACCEPT'
        option forward 'ACCEPT'
        option output 'ACCEPT'
        option network 'wg0'

config forwarding
        option src 'lan'
        option dest 'wg'

config rule
        option src '*'
        option target 'ACCEPT'
        option proto 'udp'
        option dest_port '51820'
        option name 'Allow-Wireguard-Inbound'

config zone
        option name 'netbird'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'netbird'
        option log '1'

config forwarding
        option src 'netbird'
        option dest 'lan'

config forwarding
        option src 'tailscale'
        option dest 'lan'

config forwarding
        option src 'wg'
        option dest 'lan'

config forwarding
        option src 'lan'
        option dest 'netbird'

config redirect
        option target 'DNAT'
        option name 'Nginx-Proxy-Manager-HTTPS'
        option src 'wan'
        option src_dport '443'
        option dest_ip '10.0.1.2'
        option dest_port '443'
        option reflection_src 'external'
        option dest 'lan'

config rule
        option dest 'lan'
        option name 'Allow-Nextcloud-Inbound'
        option src_port '443'
        option dest_port '443'
        option target 'ACCEPT'
        option src '*'
        list dest_ip '10.0.1.2'

(note that the rule "Allow-Nextcloud-Inbound" is me trying stuff. It is not needed for the access from wan to work.)

I tried to read through the traffic table (System - Firwall in LuCI) but all that seems ok. I must be missing some knowledge to know what is wrong exactly.

Thanks in advance.

(edit: what's frustrating is that at some point it was working from inside as well, not sure what I changed when I was trying to make it work from outside that broke it.)

egc · March 16, 2026, 4:16pm

On the port forward have a look at the Advanced Settings you need to enable "NAT loopback"

frollic · March 16, 2026, 4:52pm

Add nextcloud.example.com to local DNS, resolve with LAN IP to skip public name lookup.

Skylark13 · March 16, 2026, 4:53pm

It is already enabled.

Skylark13 · March 16, 2026, 5:02pm

Hey, yeah, that worked.

Is that what people normally do? (seems kind of a hassle to manage the mapping for all subdomains in both local DNS and in reverse proxy)

frollic · March 16, 2026, 5:03pm

There are probably other/better/smarter ways, but you wanted it to work, you didn't ask for the optimal solution

egc · March 16, 2026, 5:03pm

I use Loopback source: internal IP address and that works for me, but i do not use port 443, I use it for my WireGuard server

Skylark13 · March 16, 2026, 5:07pm

I appreciate the expeditive answer as much as anyone else. But I also mentioned I am aware that my lack of knowledge led me to the problem in the first place, so I'm open to suggestions for better ways, which will help me learn at the same time.

_bernd · March 16, 2026, 5:47pm

Either you use split DNS or nat loopback. Both are fine in small home or small business networks.

In "real" networks without private aka non global routable addresses it is no issue at all.

_bernd · March 16, 2026, 8:35pm

The whole ipv4 stuff just gets annoyingly complicated for new one.
The imported bit is that IP networks are packet switched networks with end to end connectivity.
All the shit with private addresses and all the pain with nat and DNS and everything is post 1994. Before that all these issues did not existed.

However the mistakes of the escaped lab experiment namely ipv4 got fixed with IPv6.
My advice. Learn with IPv6 first and then dig in the complex history of IPv4 afterwards.

_bernd · March 16, 2026, 8:42pm

And not to forget my go to recommendation. It's online. It's free. No ads. Good quality.

system · March 26, 2026, 8:42pm

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