DMZ configuration using VLANs

The DMZ is a security concept. It comprises the separation of the LAN-side network into at least two networks: the user LAN and the DMZ. Generally the DMZ is imprisoned: only access to certain ports from the Internet are allowed into the DMZ, while the DMZ is not allowed to establish new connections to the WAN-side or LAN-side networks. That way, if a server inside of the DMZ is hacked the potential damage that can be done remains restricted! The whole point of the DMZ is to cleanly create a unique firewall rule set that dramatically restricts access in to, and out of the, DMZ.

Publicly accessible servers remain the most vulnerable part of any network, although they are:

  • set up and hardened professionally
  • updated regularly
  • and also thoroughly monitored (mail Log files and read the mail)

Many of the malicious robots and spiders on the internet scan well-known TCP ports and then try to exploit vulnerabilities. The most used webserver, Apache, has numerous POVs (Point of Vulnerability) that can be exploited. See the CVE database on Apache vulnerabilities or Apache 2.4 Vulnerabilities for information - scary!

For more information on splitting up your OpenWrt LAN-side network (default is a single bridge) into more networks:

It is possible to set up firewall rules based simply on the IP addresses of the public servers (see NAT for LAN-side Public Server), but this is not the most secure topology. If an attack exploits a POV and gains access to the public server all stations behind the firewall could be available to the attacker.

A more secure topology is to set up a separate VLAN for the DMZ, stick it into a new firewall zone and groom the firewall rules for only that zone.

This following switch configuration will assign switch ports specifically to traffic to the stations in the DMZ.

:!: The DMZ station(s) should be attached to a wired ethernet switch port. First for better performance and second for easier VLAN provisioning.

Use the switch interface in /etc/config/network or through the LuCI Network → Switch page.

This example is based on, and tested against, the Reference Network Topology. The STA-server2 station is a public webserver accessible from the internet.

The switch ports are highly dependent on the switch hardware. To view how the physical ports are configured, use:

swconfig list
swconfig dev switch0 show

:!: Confirm the switch ports align with the physical labeling on the router. Sometimes wired ports 1,2,3,4 are labelled as 4,3,2,1.

The Ethernet switches used in this example have the following switch port mappings (Atheros/Qualcomm):

  • 0: wired port to WAN (1)
  • 1, 2, 3, 4: wired GigE LAN ports (4)
  • 5: eth1 to the CPU
  • 6: eth0 to the CPU

So where are the 802.11 WLANs? For the DUT, there is only one, a 2.4GHz 802.11n interface integrated on the CPU chip. Both the CPU and the WLAN use the CPU eth0 switch port.

The original /etc/config/network shows VLAN1 for the WAN-side and VLAN2 for the LAN-side. VLAN1 has port 0 and port 5: the wired WAN port and eth1 to the CPU. VLAN2 has port 1,2,3,4 and 6: the four wired ports and eth0 for the CPU and WLAN PHY.

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'
 
config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 5'
 
config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 2 3 4 6'

To split off the DMZ on the LAN-side, pick a port (1) for the DMZ and use it in a vlan. Notice both VLANs have 6t in the port list. In VLAN 102 this is the CPU and WLAN, in VLAN 103 this is just the CPU. It must be a tagged port to differentiate which VLAN the packet is on.

config switch_vlan
        option device 'switch0'
        option vlan '102'
        option ports '2 3 4 6t'
	list comment 'vlan102: LAN ports'
 
config switch_vlan
        option device 'switch0'
        option vlan '103'
        option ports '1 6t'
	list comment 'vlan103: LAN-side DMZ'

It is very helpful to add a comment using list comment and to assign vlans with some sort of pattern. The DUT switch can support up to 4095 VLANs.

:!: The vid option defaults to the vlan index so no need to specify it also. In fact, it is generally just a configuration error source.

:!: On many Realtek and Atheros switches the ARL table (where the switch stores already learned MACs and the corresponding ports), uses only the MAC address for indexing. This has the effect that the switch tries to forward a frame to a port that isn't part of the current VLAN (since it learned that the destination is at that port), notes that the destination isn't part of the current VLAN, and drops the frame. When making changes be sure to flush the router ARL cache when provisioning the new VLANs.

Next, add the interface for the DMZ:

config 'interface' dmz
        option 'ifname' eth0.103
        option 'proto'   static
        option 'ipaddr'  192.168.30.1
        option 'netmask' 255.255.255.0

Notice the ifname must correspond to the <port>.<vlan>. The subnet must be different than the other VLANs.

Once you set up the firewall, DNS should automatically be available to the new network, DHCP will not. For DHCP, you need to add a new section to /etc/config/dhcp. It is very similar to the lan section.

config dhcp 'dmz'
	option interface 'dmz'
	option start '50'
	option limit '70'
	option leasetime '12h'

Additionally, the public server should be very static, so it helps to add a static DHCP lease. First because it makes the firewall rules easier and second to debug future issues:

config host
	option name 'STA-server2'
	option dns '1'
	option mac '24:B6:FD:24:59:B9'
	option ip '192.168.30.20'
	option leasetime '12h'

Now the most important thing, the reason why you split up your network: the firewall rules. A typical DMZ can be fully provisioned using the firewall application.

Each VLAN should be a unique firewall zone. So create one for the DMZ. Nothing is initiated from the DM zone so the policy is to REJECT everything.

config 'zone'
       option 'name' 'dmz'
       option 'input' 'REJECT'
       option 'output' 'REJECT'
       option 'forward' 'REJECT'
       option 'network' 'dmz'

Now, the main goal is to redirect HTTP/S from the Internet to the STA-server2. Next, allow the server to do DNS lookups. Finally, for maintenance, allow SSH from any station in the LAN zone.

# Make STA-server:80 publicly accessible using the public ipv4 of the router
config redirect             
        option target 'DNAT'
        option src 'wan'
        option src_dport '80 443'
        option proto 'tcp'
        option family 'ipv4'
        option dest 'dmz'
        option dest_ip '192.168.30.20'
        option dest_port '80'
        option name 'DNAT-HTTP-WAN-DNZ'
        option enabled '1'
 
# Allow the DMZ to access a DNS server
config 'rule'
       option src 'dmz'
       option proto 'tcp udp'
       option dest 'wan'
       option dest_port 53
       option target 'ACCEPT'
       option name 'ACCEPT-DNS-DMZ-WAN'
       option enabled '1'
 
# Allow all LAN stations to SSH to DMZ stations
config rule   
       option src 'lan'
       option dest 'dmz'
       option proto 'tcp'
       option family 'ipv4'
       option dest_port '22'
       option target 'ACCEPT'      
       option name 'ACCEPT-SSH-LAN-DMZ'
       option enabled '1'

:!: What about using LuCI from the WAN zone now that a public webserver is sitting there? All requests coming in the WAN to port 80 are going to public web server so LuCI requests from the WAN-side would do the same.

If the requirement is to have LuCI access from the WAN-side, redirect HTTP to a new TCP port and use http://dut:8080 to access the router's LuCI webserver.

config redirect
        option target 'DNAT'
        option src 'wan'
        option src_dport '8080'
        option proto 'tcp'
        option family 'ipv4'
        option dest_port '80'
        option name 'DNAT-HTTP-WAN-DEVICE'
        option enabled '1'
This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2022/10/27 20:43
  • by vgaetera