Interfaces:
LAN static ip + dhcp (Computers are connected here) (Allowed forward to: DMZ + WAN)
WAN: DHCP client to ISP
DMZ: static ip (Servers are connected here) (Allowed forward to: LAN + WAN)
PortForwards:
SSH: Incoming from WAN port 22 > Forward > DMZ 192.168.22.20 port 22 (Enable NAT Loopback enabled)
The problem that I am having is that the NAT loopback rules are only created for the DMZ network.
"NAT Loopback" as noted in OpenWrt works on the specific IP in question. I believe this term has other definitions on different router distros (i.e. DD-WRT).
If you're trying to reach a host by WAN IP/port from another network:
Use its local IP/port instead
Setup a local DNS entry for the LAN IP
You'll have to make an explicit redirect/port forward - that fixes the DST IP and drops it back in the SRC network for forwarding with the local IP
The latter suggestion is not recommended by regulars in the forum (it takes the most CPUs out of the three options).
Thanks for your response. I did end up using my local DNS server to change the DNS entry for my domains.
Example:
Record registered by my DNS service: mywebsite.com > 214.**.**.***
My local DNS: mywebsite.com > 192.168.22.20
And this does work just as you would expect. I was planning to only use that as a workaround, but after reading you message I came to understand that that is the better solution as it eliminates the need for CPU heavy routes?
If you could be so kind to confirm my current understanding on this matter, that would be awesome.
The problem with the local DNS entry approach is that it only works for clients that are using the local DNS server, and you still have to add firewall rules to allow the relevant traffic between zones.
I hit the same problem, where loopback to machines in my lan zone would work for clients in my lan zone, but not for clients in my guest zone. This seems to be by design, but it seems like a slightly odd design to me - it means that everyone in the entire world can access these forwarded external ports except for people on my guest network...
I ended up writing a script which identifies port forwarding rules for a specific zone/subnet and adds new rules to allow loopback from all my local zones:
#!/bin/sh
# Zone and subnet for original port forward rules
original_zone=lan
original_subnet=192.168.111.0/24
# Subnet from which port forwarding loopback connections will be allowed
new_subnet=192.168.0.0/16
echo "Configuring port forwarding loopback rules for guest network..."
# Get the port forwarding loopback rules from the original zone
original_rules=`iptables -t nat -S zone_${original_zone}_prerouting | grep "!fw3:.*(reflection)" ; \
iptables -t nat -S zone_${original_zone}_postrouting | grep "!fw3:.*(reflection)"`
# Prepend "iptables -t nat" command
# Replace the original subnet with the new subnet
# Specify the generic "prerouting_rule" chain for DNAT rules
# Specify the generic "postrouting_rule" chain for SNAT rules
# Edit the comment
new_rules=`echo "$original_rules" | sed -e 's|^|iptables -t nat |g' \
-e "s|${original_subnet}|${new_subnet}|g" \
-e "s|zone_${original_zone}_prerouting|prerouting_rule|g" \
-e "s|zone_${original_zone}_postrouting|postrouting_rule|g" \
-e 's|!fw3: |ALL ZONES: |g'`
# Create a script containing the new rules, and run it
# (We could just run the commands here directly, but it's nice to have a record of what we did)
echo "$new_rules" >/tmp/fix_loopback_temp.sh
chmod 755 /tmp/fix_loopback_temp.sh
/tmp/fix_loopback_temp.sh
echo " Added `echo "$new_rules" | wc -l` rules"
I added a line to my custom firewall rules script to call the script above, but there's one additional wrinkle - the generic pre/postrouting chains get cleared when the firewall gets reloaded, and the custom firewall script does not get executed, so you lose these rules. So I modified /etc/config/firewall so that the custom firewall script does get executed on firewall reload:
config include
option path '/etc/firewall.user'
option reload '1' <---------------
I think you simply confuse other router distro's firewall designs with OpenWrt's.
I assure you when some of your zones are public subnets, it makes a lot of sense. I don't want my router to [incorrectly] guess that I want traffic to cross zones (and possibly routing policies, etc).
Because other routers magically add rules you never see (or more specifically, probably don't use zone-based firewalling), may make it convenient; but probably less safe.
You can easily adapt my script to do that - just change the new_subnet value. In fact I originally wrote it to target my guest zone/subnet specifically, but in my particular use case I don't see any reason not to allow all my internal zones to access my lan forwarded ports (given that I'm already exposing them to the world), so I modified the script to open them up to 192.168.0.0/16 so I don't have to come back and change this if I add more zones in future.
Basically I wrote the script because I'm just lazy and I don't want to have to worry about manually adding rules every time I add or modify a port forward. Laziness is the driver behind most of my scripts
