Hey all, new OpenWRT user here. Having a port forwarding issue I can't seem to solve alone, figured I'd ask here.
For context: My config has several vlans/firewall zones, but the two main relevant ones here are LAN (trusted devices) and SERVER (for my rack). Both are able to contact WAN, but only LAN is able to initiate connections between itself and SERVER. They've treated me well and I've had no issue till today.
Earlier this week, I got a static IP from my new ISP, and wanted to port forward a server to see if I could host anything. I created a rule in LuCI to try and forward data from WAN to one of my machines on SERVER and it doesn't work. However, when I set it to forward from WAN to the same internal IP via the LAN firewall zone, it works. Why is this? It most certainly doesn't make me comfortable. Am I making a major mistake somewhere in my config? Thoughts welcome, extra info available upon request. Thanks in advance.
So, If I'm reading this correctly, this is intended behavior? Is it cool to do this in production?
Also if you don't mind, could you expand upon this? I have a DNS server running in the server VLAN, so this might be possible. However, I have no idea what exactly this solution entails, whether its viable or not, or even where to get started.
I get this, already doing it for a few of my machines so WAN requests route go thru CF ZTNA, while LAN/SERVER requests just resolve to the local IP. I'm just not quite sure how this would affect the forward's config in LuCI.
Just to make sure we're on the same page: forwarding to my machine in the server vlan via the "lan" destination zone (rather than "server" zone) is totally ok, and then I can use the DNS trick on top of that to make resolution easier?
I don't mean to go in circles here, apologies if I am. Like I said at the start, I'm still new when it comes to routing, so I'm just trying to wrap my head around the issue thoroughly rather than just say "ok!" and potentially misconfigure something critical. Thanks in advance for dealing with me.
Regardless of the DNS trick being used or not, it's to my understanding that I will still need a port forward configured on my router to allow WAN requests to make their way into my network and reach my server. Configuring this forward is my main concern, more than how I plan on contacting said machine.
I've seen tutorials like this one, (Which it looks like you contributed to, actually!) where they set up a network very similarly to mine. The port forwards section specify to set the internal zone to "DMZ", and the internal IP to the machine in said zone. This is the part that confuses me the most. When I try doing the same with my SERVER zone, configured similarly, my port forwards don't work whatsoever. However, when I modify the forward to use the same internal IP and but my LAN internal zone, it does work. Why is this?
Maybe this phrase is what needs to be expanded upon for me to understand. Why when I set the forward's internal zone to my server zone is it unable to contact anything inside the SERVER vlan? I assume it's a firewall config issue more than anything.
Perhaps we're having a language barrier or something. I'm not sure why you're calling this an issue when we already noted it was intended behavior.
I thought we covered that you were using the Public IP originally for the Port Forward, unless I'm mistaken, that would be WAN, not the server VLAN - hence it doesn't work because it's an invalid rule.
I pray you block traffic on WAN, correct?
That's why the Port Forward to WAN doesn't work (aside from the fact your server isn't in WAN).
Perhaps, let me change my question to see if this helps. In the tutorial I linked above, why does the port forward via the DMZ internal zone work? By what you've stated in this thread, wouldn't the port forward have to go to that router's LAN zone for the forward to work, as is my case?
Not the case, WAN-to-local is what I'm having issue with here. Perhaps it was my language in the first post that led us astray, but I want to make it clear that my issue is regarding people connecting to my server from the internet.
My network is configured to separate my LAN from my Server rack, in two zones: LAN and SERVER. LAN is able to initiate communications with SERVER, but not vice-versa. Both are able to contact WAN.
When I configure a port forward from WAN to my server, it will not work unless the internal zone is set to LAN, despite the server being located within the SERVER firewall zone.
Also the linked thread is a guide, not a question. I didn't think there needed to be a solution.
Your description of how you tested led us astray (you mentioned 'Internal IP' and confused me)...
To be clear, you're testing from the Internet, correct?
Your ISP allows port 8000?
Set TCP or UDP
I surmised you'd note (exactly) why you referred me to the thread. I tried reading 33 posts to understand why you linked it...but I'm more confused now that you explained your issue.
So, let's verify you're actually testing form WAN. Also, to be clear, you have to set the IP of the server:
option dest_ip '[Local address within SERVER's IP range]'
This was set correctly in the actual config, I just redacted it in the config I sent because I'm a paranoid SoB. The actual IP in there is a 10.1.1.x address which points to a machine on the SERVER vlan. Said machine was hosting a python3 http.server on internal 8000, just for testing.
Correct, I used my cell phone on 5G for testing. Specifically Termux on Android running watch -n 1 curl http://my_public_ip:port.
I know the rest of the forward's config isn't the issue because I am successfully able to get the server to respond, only when the server's port forward was configured to use the LAN firewall zone. Everything else stayed the same: Source zone (WAN), external port, internal ip (10.1.1.X), internal port (8000). See the second image I linked for reference. The only thing that changes is the internal zone, and it must be set to LAN for the forward to work, apparently. Ideally, it should be SERVER, right?
EDIT: It is now 2 AM in my time zone, I have to get some sleep. Will revisit this in the morning, when I get some time.
Please run the following commands (copy-paste the whole block) and paste the output here, using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have
ubus call system board; \
uci export network; \
uci export dhcp; uci export firewall; \
head -n -0 /etc/firewall.user; \
iptables-save -c; \
ip -4 addr ; ip -4 ro li tab all ; ip -4 ru
I got an error when posting the output here; seems I've hit the character limit, so I saved the output of your command to pastebin instead. Hope this doesn't cause an issue. Link
I've annotated the output a little to redact WAN IPs, MACs, and Static Leases I didn't think would be imperative to share. See my "editor's notes" on L167 and L398. Hope this helps, more info available upon request.
# I have redacted, because they detailed static IP assignments that
# contained lots of MAC addresses
Most WAN Port Forwards don't need MAC address entries. In fact, WAN port forwards noting MAC addresses tend to be erroneous.
This is because the only WAN MAC you usually see is that of the ISPs device at the other end.
I'm trying to understand why ypu qpuld create a rule with MAC addresses; but without seeing the rule or its description that's difficult. Good thing you mentioned this!
I could have configured my server network so that each of my servers used a static IP configuration, I just decided to use DHCP to make adding new devices onto that network less of a pain.
Either way, the actual forward on L391 uses an IP, not MAC.
First you should remove the internet dns from iot, guest, server, and lan interfaces and add them in wan interface, where they are reachable from.
config interface 'IOT'
...
list dns '10.1.1.3'
list dns '1.1.1.1'
list dns '1.0.0.1'
If you want to advertise specific DNS servers to the hosts, you can use option 6 in dhcp options. list dhcp_option '6,10.1.1.3,1.1.1.1,1.0.0.1'
If you don't use anything, OpenWrt will advertise itself as DNS.
