Guide to set up DMZ via LUCI

Perhaps I don't understand, or you are not aware that a Linux firewall is basically sets of modules loaded into the running Kernel. You cannot turn off the firewall, since in Linux, NATing is done via the same software as the firewall.

You can also use option proto 'all'

Totally lost, as this only happens if you don't allow forwarding from the Zone to WAN by default. In any case, the established/related to the ports opened would be allowed to reply (I think this is what your concern was).

Not really, it seems you're new to learning the Zone-based firewall method. I had the same concerns first starting in OpenWrt.

:+1:

Thanks a lot for your patient and clear answer. Indeed I'm completely new to open source firmware for routers and despite I am a Linux user for quite some years now on my desktop computer, I didn't know that in linux the firewall was part of the kernel.

I (somehow) understood that the hosts in the zone were automatically allowed to answer to incoming requests (if these incoming requests were allowed by the firewall).
I was not sure that the DMZ was allowed to be the initiator of outgoing traffic on any port (not just the classical ports for the main protocols: 80 for HTTP etc.). Probably due to the fact that I misinterpreted the word "Forwarding" in the main settings... Indeed my question was pure non-sense.
It also imply that an issue I try to solve was not due to my ISP router (some forums said port forwarding and DMZ was buggy on this router when UDP was involved), and that it will probably not find any solution with my brand new router with Openwrt (with or without a DMZ). The problem is probably due to some filtering located in the servers of my ISP. But that's another story...

Thanks again for your answers!

I think dhcp-dns should be dmz-dns in this step.

Also the text does not say to change the Source zone to DMZ.

Both of these are clearly shown in the image, so this is just a nit.

Thanx for the step-by-step instructions.

Are you sure this is all it takes?
I am running a netperf server on the DMZ PC.
When I run the speedtest from outside, download test works, but upload test doesn't work.
By any chance these rules are incomplete?

If you only have a single IP on WAN (and 1 WAN), there should be no additional configurations necessary. Outbound is the same as any other client.

  • Are you certain that you do not have any conflicting inbound port forwarding rules?
  • Is the traffic TCP or UDP?
  • Do you have other outbound traffic issues with this server?
1 Like

I have 2 WAN's, using mwan3 in failover mode.

That's your issue. Your DMZ server must use one WAN connection during the test. In addition, the connection to your DMZ machine cannot failover to the other WAN during the test.

To be sure i uninstalled mwan3, removed the backup ISP.
It made no difference.
Still, only the upload test is not able to run. Download test works.
Internet is working on dmz pc.
The same setup works when I replace the openwrt box with a DLink stock router and use it's dmz feature.

My /etc/config/firewall

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

config zone
	option name 'lan'
	list network 'lan'
	list network 'lan2'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wwan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

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 src_ip 'fe80::/10'
	option src_port '547'
	option dest_ip 'fe80::/10'
	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 include
	option path '/etc/firewall.user'

config rule
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option src 'wan'
	option proto 'tcp'
	option dest_port '22'
	option target 'ACCEPT'

config rule
	option src 'wan'
	option proto 'tcp'
	option dest_port '23'
	option target 'ACCEPT'

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp udp'
	option src_dport '1-65535'
	option dest_ip '192.168.8.210'
	option dest_port '1-65535'
	option name 'DMZ'

This works!!
I was doing some mistake from netperf client side.

1 Like

This works for a lan client from wan

config dmz 'dmz'
option from 'wan'
option to_ip '192.168.1.223'

thanks a lot!

I would just congratulate with @Knomax for having proposed a real DMZ solution, even if in practice this is usually required for higher security to physically sit between WAN and LAN networks by also splitting them with additional firewalls. In the end you should have WAN<-firewall->DMZ<-firewall->LAN, but your solution based on VLANs is fine for consumer/SOHO purposes.

Of course as you all may know already, the usual consumer "virtual DMZ" is just a general static port-forward fallback (i.e. "do PAT to that host if no other static PAT rules are defined") plus some extra firewall exceptions, and that has absolutely nothing to do with DMZ, even if consumer device vendors insist in improperly abusing the DMZ term. This fake "DMZ" where all ports are forwarded to a single static host is all you need to get a game console to think it is working without a NAT in the middle. You don't need the real DMZ. All you need is that rule as suggested by @mindwolf above I think @Knomax should remove the 1-65535 forward rule from his otherwise perfect guide as it has nothing to do with DMZ and creates confusion.

edit: If you are curious to know how a commercial consumer DMZ is done in openwrt-based routers here is an example https://github.com/FrancYescO/tch_firmware_extracted/blob/AGTHP_2.2.1_003_CLOSED/lib/functions/dmz.sh

edit 2: In a typical real DMZ you have all - multiple - DMZ members to be publicly addressable with their own IPs with no NAT performed. This is what usually happens on enterprise networks where you get many IPs assigned by the ISP. It is the same for IPv6 even for consumer networks. In that sense, having a host in DMZ means to have no NAT issues for that host, and that's why consumer devices implements such fake "virtual DMZ" features where all traffic is simply statically PAT'd after NAT to a single host in the usual LAN zone. A proper way of achieving 1:1 mapping of public addresses to DMZ hosts (and therefore no NAT issues for them) would be to [a] statically NAT or [b] directly assign them unique public addresses.

For instance, in the awesome @Knomax solution we have each DMZ host in the 192.168.0.0/24 subnet. and public address is released via PPPoE.

  • option [a] - Assuming we need to map a dedicated public IP to an xbox at 192.168.0.42, we need to bring up a second PPPoE connection to get a second wan IP, then install mwan3 to instruct the openwrt router to use this second interface for the xbox only, and finally NAT everything coming from this second IP to 192.168.0.42. Then you also buy a playstation on 192.168.0.43, so you create a third wan interface, configure mwan3 to use that third wan for playstation only and finally do static NAT from such interface to 192.168.0.43
  • option [b] - You also enable PPPoE relay (aka passthrough) on the openwrt router for the DMZ zone only (!!) such that each xbox/playstation is also capable of getting their public IP on their own.

The second option is simpler, I often see it being improperly used in home gateways where it is allowed from the main LAN zone too (unbelievably insecure….). I usually discourage this since this hardly gets optimal performance due to transiting via main router cpu for PPPoE relaying (thus no hw-nat probably) causing latency spikes depending on main cpu load. There also exists an equivalent DHCP relay for non-PPPoE based services where DHCP relay daemon takes care of creating necessary routing entries automatically, however I'm not sure how this actually works.

The first option is my favorite. You get the best results and works for both PPPoE and DHCP based deployments. I have also seen static NAT options in some commercial consumer home routers but this usually relates to their single main wan connection so enabling it is simply useless for this case.

So, build a real DMZ like @Knomax described in the first post, then find your preferred way of statically mapping your public addresses to hosts in DMZ (xbox, playstation, webserver, ecc.).

  • consumer home routers do it "virtually" for a single host at time with poor general static PAT fallback rules (they call it DMZ, it is not DMZ thou), you have an openwrt router … try doing something better!
  • go for option [b] if you don't feel comfortable configuring static NAT or mwan3, it's a good starting point
  • go for option [a] if you are ambitious
1 Like

config dmz 'dmz'

If that's really all it takes to do a DMZ, then that should be in the documentation at: https://openwrt.org/docs/guide-user/start#firewall_configuration

Personally my brain turns off at the sight of the VLAN stuff. It's nonsense for home users. Most people have a computer and a phone and a Sonos and don't need the VLANs, guys! The sysadmins already know the answers to the sysadmin questions, they aren't coming here asking for help about "DMZ".

It is not - seems to be some proprietary 3rd party extension.

Thanks, Knomax. To create a DMZ I think that I understand that we add a second VLAN to our network on switch0, then open its ports and bridge it to the existing local network. But the differences between the LUCI guide and my R7800 make this frustratingly difficult to follow. For all of the documentation on this site, and it IS impressively voluminous, there is not one diagram to pull together the various components of a DMZ into an understandable whole, except for the "poneys and rainbows" illustration in routing.example.1.bridged.dmz, which IMHO could/should have been simplified to just the lower third for understandability.

I am stuck at understanding/creating VLAN10. The example for a DHCP VLAN shows:

VLAN ID Port 0 Port 1 Port2 Port 3 Port 4 CPU

While my router is:

VLAN ID CPU(eth0) CPU(eth1) LAN1 LAN2 LAN3 LAN4 WAN

I'm assuming that your illustration is the 2-port "after" view, with only one port existing in the "before". Am I correct? My default has two existing ports, for the two CPUs I guess (why?), and I guess the added #10 port will be a third after completion. I also have a "WAN" column that I am not at all sure about. Tagged? Untagged? How to handle this configuration?

1 Like

In both diagrams it is the "after"
In the first case there is one CPU port. In the second there are 2 CPU ports. The first is handling the lan ports and the second is handling the wan port. Since you are going to allocate a port from the lan for dmz, you need to tag the lan CPU.

Thanks, trendy! I spent literally hours trying to figure this part out. On to the next...

Greetings!

i have tp-link archer c20 v4 with luci 19.07.4.

i did all the steps mentioned above, but still when i check my ports they arent open on https://canyouseeme.org/...

i did do all the steps correctly i think...
but i m not able to get my ports open, not a single one of them is open... idk where i did mistakes

Test the ports yourself and don't depend on such sites.

2 Likes

Maybe not, but this looks very similar to this blog, down to the VLAN assignment - https://blog.christophersmart.com/2015/01/17/creating-a-dmz-in-openwrt/

We need more people who can really contribute.