Can't reach public IP from within LAN

I'm trying to run a development testing web server stack on my Ubuntu server that is on my local network. I'm trying to access it via my DDNS and/or public IP address in a web browser from my LAN but I'm unable to reach it. The port forwarding definitely works as I can reach the server outside of my network.

Using Powershell's Invoke-WebRequest

PS C:\Users\Will> Invoke-WebRequest -Uri http://123.145.156.178:8080 
Invoke-WebRequest : Unable to connect to the remote server
At line:1 char:1
+ Invoke-WebRequest -Uri http://123.145.156.178:8080
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

/etc/config/firewall

config redirect
        option src 'wan'
        option name '3020M-Server2-HTTP'
        option target 'DNAT'
        option dest 'servers'
        option dest_ip '192.168.8.140'
        option dest_port '8080'
        option src_dport '8080'
        option reflection_src 'external'
        option reflection '1'

config redirect
        option dest_port '443'
        option src 'wan'
        option name '3020M-Server2-HTTPS'
        option src_dport '443'
        option target 'DNAT'
        option dest 'servers'
        option dest_ip '192.168.8.140'
        option reflection_src 'external'
        option reflection '1'

Try changing source to any zone (instead of wan)

And I don’t think you want the reflection source to be external.

2 Likes

The reflection works for traffic from the same zone, not from different. It would be easier to create an internal hostname and use that instead of the ddns or the public IP.

2 Likes

Testing the public IP address and DDNS was more of a way of testing the security measures put in place are working as I could test if directory and file restrictions are working on the outside world.

For some reason in LuCI there isn't a way of selecting any. Not sure if it's a bug but I managed to edit the config directly using an asterisk (wildcard) and it does show as any zone on the list of port forwards.

However, upon editing the rule it seems to select the first interface I have.

I've just plugged in my ISP's wireless router, connected my mini server, setup port forwarding to it and visited my public IP address/DDNS and it works from within the LAN.

What could be causing the issues with OpenWrt?

It seems the problems I'm facing are related to a bug that was reported.

https://bugs.openwrt.org/index.php?do=details&task_id=1645

https://bugs.openwrt.org/index.php?do=details&task_id=3875

"NAT loopback" as I've experienced it in OpenWrt - only works on the single IP/net in question.

As other options, you'd have to:

  1. make a firewall redirect rule that covers the zone/interface/subnet; or
  2. DNS entry giving and A Record to the LAN IP

For firewall config, I make a rule that allows the traffic and places the packet in the SRC network :warning: . This changes the DST IP from the Public to the LAN, and allows the packet to travel using the zones regular routing rules.

1 Like

In regards to option one are you referring to what some people refer as inter-VLAN firewall rules?

The reason I'm wanting to get NAT loopback working is I would like to test the forwarding rules work as though I'm outside of my WAN.

It is a couple of DNAT/SNAT rules. Just replicate them to the other zones too.

[0:0] -A zone_iot_postrouting -s 172.30.30.0/24 -d 172.30.30.2/32 -p tcp -m tcp --dport 22 -m comment --comment "!fw3: kakadu SSH (reflection)" -j SNAT --to-source 172.30.30.1
[0:0] -A zone_iot_prerouting -s 172.30.30.0/24 -d 111.111.111.111/32 -p tcp -m tcp --dport 2022 -m comment --comment "!fw3: kakadu SSH (reflection)" -j DNAT --to-destination 172.30.30.2:22

There are many more convenient ways to do that. Use 3G/LTE data or some external service for port forwarding checking/tester while you monitor the hits on the firewall and capturing the packets on the server.

2 Likes

I would go further than @trendy. Given they're 2 separate rules, I'm unsure how that would confirm it works.

You would have to:

  1. test from ["outside of your"] WAN (he covered multiple remote options); or
  2. create another set of IP networks with NATing as a test scenario (but again, that doesn't test your actual rule in question).

(#1 seems so simple, and seems to be the goal of creating the firewall rule :grey_question: )

Well, since it doesn't matter if it's: a network interface, IP or range, defined zone, etc....and I'm, not sure if you're referring to OpenWrt...I guess so.

config redirect                                          
        option target 'DNAT'                                         
        option src 'wan'                                           
        option proto 'tcp'                
        option src_dport '80'                                        
        option dest_port '80'                                      
        option src_ip '192.168.1.0/24'    
        option dest 'lan'                                            
        option dest_ip '192.168.xxx.yyy'                              
        option name 'REDIRECT_HTTP_LAN'

:warning: Note, the packet is made to DST to the LAN zone where the request started :wink: - this takes CPUs and using a local DNS record (option #2) instead would fix that.

This public IP is identical to the one displayed as your WAN interface IP, correct?

Okay interestingly changing the forward destination on the OpenWrt DNAT rule from servers to lan has both allowed the port to work externally (as checked via 4G on my phone) and I'm also able to reach it internally.

Changing from this

To this

That is because the PREROUTING DNAT rule is applied on the source zone taking only the destination address in consideration.
The POSTROUTING SNAT and PREROUTING DNAT rules for reflection are applied on the declared destination zone. This means that it will not work if you try to do the same from servers zone.

1 Like

I'm just trying to get my head around the IP addresses needed for the these iptable rules to work and see how the packes move from place to another. I'm still learning iptables :grin: Would it be worth doing an online CompTIA Network+ course or are there any other courses that you could recommend so I can improve my knowledge in this network area?

My LAN network is 192.168.5.0/24
My Servers network is 192.168.8.0/24
My server's IP address is 192.168.8.140

iptables -t nat -A zone_xyz_postrouting -s www.xxx.yyy.zzz/24 -d  www.xxx.yyy.zzz/32 -p tcp -m tcp --dport 80 -j SNAT --to-source 

iptables -t nat -A zone_xyz_prerouting -s  www.xxx.yyy.zzz/24 -d  www.xxx.yyy.zzz/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination  www.xxx.yyy.zzz:80

xyz = zone name

-s www.xxx.yyy.zzz = source network
-d www.xxx.yyy.zzz = destination address
--to-destination www.xxx.yyy.zzz:80 = real IP of the server

1 Like

I think I have the rules correct as I appear to me able to reach my DDNS/public IP address from within my private LAN.

WAN_IPv4="$(cat /tmp/WAN_IPv4)"

# Private VLAN = 192.168.5.0/24
# Server IP = 192.168.8.140

#iptables -t nat -A zone_lan_postrouting -s 192.168.5.0/24 -d 192.168.8.140/32 -p tcp -m tcp --dport 80 -j SNAT --to source 192.168.5.1
iptables -t nat -A zone_lan_prerouting -s 192.168.5.0/24 -d ${WAN_IPv4}/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.8.140:80

#iptables -t nat -A zone_servers_postrouting -s 192.168.8.0/24 -d 192.168.8.140/32 -p tcp -m tcp --dport 80 -j SNAT --to-source 192.168.8.1
iptables -t nat -A zone_servers_prerouting -s 192.168.8.0/24 -d ${WAN_IPv4}/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.8.140:80
iptables -t nat -A zone_wan_prerouting -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.8.140:80

I can't get my head the postrouting rules. Even if I disable them as you can see above commented out I can still access the server via WAN and LAN.

Without the postrouting rules you'll have asymmetric routing. Packets from host A to server will go through OpenWrt, but the response will come back from Server to A directly. If your firewall is kinda loose, it could work. However there are cases where a firewall will drop packets as invalid.

2 Likes

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