When enabling NAT loopback for a port forward, it seems to be enabled for both the LAN and guest network. Is it possible to restrict this somehow to the just the LAN network? The server for which I'm creating the port forwarding rules, is located in the LAN network. So it's not accessible directly from the guest network (different vlan). Without the NAT loopback, the connection would appear to come from the WAN, and it would work just fine. I could of course disable the NAT loopback entirely, but then I also loose the advantage for the clients in the LAN network.
NAT loopback is a bad idea as it is using router resources to allow lan hosts to communicate. You can add an entry in hostnames (fqdn->internal server IP) and you won't need it.
Other than that the reflection applies only to the prerouting of the lan zone, provided that the port forward is wan->lan. So if you have guest interface in the lan zone, there is the culprit.
2 Likes
Sorry for jumping in: why is "NAT loopback" (aka "reflection") the default choice when creating a new rule?
I suppose it was decided by some developer to make it easier for users who didn't understand why their DDNS is not working from inside the lan.
2 Likes
Not sure why DDNS should fail without that but ok... I had it enabled only for port forwardings from wan to lan (ssh and anydesk) so I can just turn it off, I guess. Thanks.
Because without it OpenWrt would drop the packets from LAN towards the public IP of the wan, resolved by the DDNS and we would have tons of posts asking why the port forward is not working.
2 Likes
Understood.
I'm using different names for the wan and the lan, that's why I never noticed it.
1 Like
This works fine too, others are using the internet name from inside the lan and that causes the issues.
2 Likes
I want to be able to use the same name such that everything always works, regardless of whether I'm using a mobile device (phone or laptop) from inside the LAN or remotely.
Okay, so this results in a DNS request returning the LAN IP address, and going directly to the destination. This seems like a nice alternative, provided that all port forwards are towards the same IP address, and the internal and external port are the same.
But I don't think it will fix the problem of the guest network. Both the lan and guest network use the same DNS server. Thus on the guest network, a DNS request will also return the internal LAN IP address. But the firewall will block access to that IP address.
The guest interface is in a separate guest zone, and not the lan zone.
You can create a rule on the firewall to allow that particular flow.
1 Like
(BTW,the NAT loopback only works on the IP/port in question anyways.)
1 Like
Using a hostname to map the FQDN directly to the internal IP address seems to break the DDNS scripts. When they try to resolve the FQDN with nslookup, they also get the internal IP address instead of the public one.
Bummer, looks like you'll have to rely on reflection to make it work all together.
However the reflection only works for the specific zone that the port forward points to. So unless the guest interface is part of the lan zone, then enabling the reflection on a port forward from wan to lan it won't work for traffic coming from guest.
2 Likes
I found a solution for the DDNS problem! In the ddns configuration there is a dns_server option to specify an external dns server to detect the current registered IP address. This allows to bypass the local dns resolver (which returns the local ip address) for this specific purpose only. I simply use the nameserver of my DDNS provider.
2 Likes