Training Lab 2: Firewall Rules and Aliases
Lab 2: Interfaces, Firewall Rules, and Aliases
This hands-on lab covers configuring the HQ DMZ interface, building firewall rules, creating aliases, and applying restrictive access policies. All configuration is performed on fw1-HQ at https://172.17.1.1.
Prerequisites
- Lab topology from Training Lab 1 is in place
- HQ LAN:
172.17.1.0/24 - HQ DMZ:
172.17.2.0/24 - Access to fw1-HQ web interface and VPN connection
Lab Overview
This lab starts with configuring the DMZ interface at HQ, going through the steps to assign and configure a new interface. This new interface will be used as an example of configuring an additional internal interface treated as a DMZ, with significant restrictions to the other internal networks.
Then we'll go through use cases and examples for firewall rules and aliases. Some firewall rules come in the context of NAT, which is covered in a later lab.
Exercise 1: Configure the DMZ Interface
Step 1: Review Interface Assignments
Browse to Interfaces > Assign.
The firewall's interfaces are assigned in order, from vtnet0 to vtnet4. Our DMZ interface will be OPT1, which is assigned to vtnet2.
Step 2: Enable and Configure OPT1
Browse to Interfaces > OPT1 and configure:
| Setting | Value |
|---|---|
| Enable | ✓ Checked |
| Description | DMZ |
| IPv4 Configuration Type | Static IPv4 |
| IPv4 Address | 172.17.2.1/24 |
Save and Apply Changes.
After saving, OPT1 is still the underlying identifier in config.xml, but the interface is displayed as DMZ.
Exercise 2: Test Connectivity to DMZ
Ping the DMZ Gateway
From the HQ-Client VM:
training@hq-client:~$ ping 172.17.2.1 PING 172.17.2.1 (172.17.2.1) 56(84) bytes of data. 64 bytes from 172.17.2.1: icmp_seq=1 ttl=64 time=0.298 ms 64 bytes from 172.17.2.1: icmp_seq=2 ttl=64 time=0.979 ms 64 bytes from 172.17.2.1: icmp_seq=3 ttl=64 time=1.27 ms
Ping server1 from HQ-Client
training@hq-client:~$ ping -c 5 172.17.2.10 PING 172.17.2.10 (172.17.2.10) 56(84) bytes of data. 64 bytes from 172.17.2.10: icmp_seq=1 ttl=63 time=0.711 ms 64 bytes from 172.17.2.10: icmp_seq=2 ttl=63 time=1.75 ms ... 5 packets transmitted, 5 received, 0% packet loss
This ping traverses two virtual networks, so latency is roughly doubled. Steady replies indicate good connectivity.
Exercise 3: Connectivity from DMZ Network
Verify Default Block Behavior
Newly-added interfaces have no firewall rules by default. All traffic initiated on that interface is blocked.
Log in to server1 via SSH from HQ-client:
training@hq-client:~$ ssh training@172.17.2.10 Password for training@server1: password
From server1, attempt to ping:
training@server1:~ % ping -c 5 172.17.2.1 PING 172.17.2.1 (172.17.2.1): 56 data bytes --- 172.17.2.1 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss training@server1:~ % ping google.com ping: cannot resolve google.com: Host name lookup failure
Troubleshooting: Check ARP Cache
Check the ARP cache to confirm Layer 2 connectivity:
training@server1:~ % arp -an ? (172.17.2.10) at 08:00:27:ec:c0:6b on em0 permanent [ethernet] ? (172.17.2.1) at 08:00:27:59:b4:35 on em0 expires in 139 seconds [ethernet]
A valid MAC address for the gateway confirms the server is on the correct network segment. An incomplete entry indicates a Layer 2 issue.
Check Firewall Logs
Browse to Status > System Logs > Firewall on fw1-HQ to see blocked traffic.
Add Temporary Allow-All Rule
On Firewall > Rules > DMZ, add a temporary rule:
| Setting | Value |
|---|---|
| Action | Pass |
| Interface | DMZ |
| Protocol | any |
| Source | any |
| Destination | any |
Save and Apply Changes.
Verify connectivity from server1:
training@server1:~ % ping -c 3 172.17.2.1 training@server1:~ % ping -c 3 google.com training@server1:~ % ping -c 3 172.17.1.100
All three should succeed with the allow-all rule in place.
Exercise 4: Create Aliases
Aliases ease management by grouping IPs, networks, or ports.
Browse to Firewall > Aliases.
Alias: PrivateNetworks
| Field | Value |
|---|---|
| Name | PrivateNetworks |
| Description | All RFC1918 private IP space |
| Type | Network |
| Members | 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 |
Alias: server1
| Field | Value |
|---|---|
| Name | server1 |
| Description | server1.example.com |
| Type | Host |
| Member | 172.17.2.10 |
Alias: server2
| Field | Value |
|---|---|
| Name | server2 |
| Description | server2.example.com |
| Type | Host |
| Member | 172.17.2.20 |
Alias: DNSservers
| Field | Value |
|---|---|
| Name | DNSservers |
| Type | Host |
| Members | server1, server2 |
Alias: SMTPservers
| Field | Value |
|---|---|
| Name | SMTPservers |
| Description | authorized outbound SMTP servers |
| Type | Host |
| Members | server1 |
Alias: RemoteAdmin
| Field | Value |
|---|---|
| Name | RemoteAdmin |
| Description | IPs authorized for remote management |
| Type | Host |
| Members | 192.0.2.100 (student's system) |
Alias: WebServers
| Field | Value |
|---|---|
| Name | WebServers |
| Description | publicly-reachable web servers |
| Type | Host |
| Members | server1, server2 |
Alias: WebPorts
| Field | Value |
|---|---|
| Name | WebPorts |
| Description | allowed ports to public web servers |
| Type | Ports |
| Members | 80, 443 |
Save each alias, then Apply Changes.
Exercise 5: Allow Remote Firewall Administration
Add a rule on Firewall > Rules > WAN:
| Setting | Value |
|---|---|
| Interface | WAN |
| Protocol | any |
| Source | Single host or alias — RemoteAdmin |
| Destination | WAN address |
| Description | allow all from remote admin IPs |
Save and Apply Changes.
Verify from your host:
$ ping 192.0.2.2 $ curl -I https://192.0.2.2
Exercise 6: Configure Restrictive DMZ Rules
Remove the temporary allow-all rule (or ensure it is at the top, to be deleted later). Then add the following rules in order using the Add button (add to bottom):
Rule 1: Allow Ping to Firewall DMZ IP
| Setting | Value |
|---|---|
| Action | Pass |
| Interface | DMZ |
| Protocol | ICMP |
| ICMP Type | Echo request |
| Source | DMZ net |
| Destination | DMZ address |
| Description | Allow ping to firewall's DMZ IP |
Rule 2: Allow DNS to DMZ IP
| Setting | Value |
|---|---|
| Action | Pass |
| Interface | DMZ |
| Protocol | TCP/UDP |
| Source | DMZ net |
| Destination | DMZ address |
| Destination Port | DNS (53) |
| Description | Allow DNS lookups to DNS Resolver |
Rule 3: Reject All Else to Private Networks
| Setting | Value |
|---|---|
| Action | Reject |
| Interface | DMZ |
| Protocol | any |
| Source | any |
| Destination | Single host or alias — PrivateNetworks |
| Log | ✓ Checked |
| Description | Reject all else from DMZ to private networks |
This prevents DMZ hosts from reaching any other internal services and logs blocked attempts.
Rule 4: Allow DNS Outbound to Internet
| Setting | Value |
|---|---|
| Action | Pass |
| Interface | DMZ |
| Protocol | TCP/UDP |
| Source | Single host or alias — DNSservers |
| Destination | any |
| Destination Port | DNS (53) |
| Description | Allow recursive queries from DNS servers to Internet |
Rule 5: Allow SMTP Outbound to Internet
| Setting | Value |
|---|---|
| Action | Pass |
| Interface | DMZ |
| Protocol | TCP |
| Source | Single host or alias — SMTPservers |
| Destination | any |
| Destination Port | SMTP (25) |
| Description | Allow SMTP servers to send to Internet |
Rule 6: Allow HTTP Outbound for Management (Disabled)
| Setting | Value |
|---|---|
| Action | Pass |
| Disabled | ✓ Checked |
| Interface | DMZ |
| Protocol | TCP |
| Source | DMZ net |
| Destination | any |
| Destination Port | HTTP (80) |
| Description | Management — temp allow HTTP outbound from servers |
This rule is disabled by default and should only be enabled during updates.
Save and Apply Changes after each rule.
Exercise 7: Verify Restrictive Ruleset
Review Rule Order
Ensure the temporary allow-all rule is at the top. With it at the top, all traffic matches it first and the restrictive rules are ineffective.
From server1, start a constant ping to HQ-client:
training@server1:~ % ping 172.17.1.100
Replies confirm the allow-all rule is passing traffic.
Delete Allow-All Rule
Delete the temporary allow-all rule and Apply Changes.
The restrictive ruleset is now enforced for all new connections. The running ping is still permitted because the firewall is stateful — already-permitted connections are never re-evaluated.
Kill the Ping State
Browse to Diagnostics > States. Filter for 172.17.2.10: (note the colon to avoid matching similar IPs). Click the ✕ symbol next to the ping state to delete it.
The ping stops immediately.
Check Firewall Logs
Browse to Status > System Logs > Firewall. Log entries show the blocked traffic.
Click the red X in the Action column on a log entry to see which rule blocked the connection. User-defined rules show USER_RULE with the configured description.
Troubleshooting Reference
| Symptom | Likely Cause | Resolution |
|---|---|---|
| Cannot ping gateway from DMZ host | No firewall rules on DMZ interface | Add pass rule or verify existing rules |
| Cannot resolve DNS from DMZ | DNS port blocked; no DNS rule | Add TCP/UDP pass rule to DMZ address port 53 |
| Can reach Internet but not HQ LAN | Reject rule to PrivateNetworks is working | Verify rule order and alias contents |
| Ping stops after deleting allow-all rule | Stateful firewall; existing state was killed | Expected behavior — new connections follow current rules |
| Cannot SSH to server1 | Layer 2 / ARP issue or VPN problem | Check arp -an on server1; verify MAC address
|
| Firewall web UI unreachable from WAN | No WAN allow rule for remote admin | Add WAN rule with RemoteAdmin alias as source |
IP Addressing Quick Reference
| Host / Network | IP Address / Range |
|---|---|
| fw1-HQ LAN | 172.17.1.1/24 |
| fw1-HQ DMZ | 172.17.2.1/24 |
| fw1-HQ WAN | 192.0.2.2 |
| HQ-Client | 172.17.1.100 |
| server1 | 172.17.2.10 |
| server2 | 172.17.2.20 |
| RemoteAdmin | 192.0.2.100 |
| HQ LAN Network | 172.17.1.0/24 |
| HQ DMZ Network | 172.17.2.0/24 |
Lab Completion Checklist
- [ ] DMZ interface enabled and configured (172.17.2.1/24)
- [ ] Connectivity tested from HQ-Client to DMZ
- [ ] Default block behavior verified from DMZ
- [ ] Aliases created (PrivateNetworks, DNSservers, SMTPservers, RemoteAdmin, WebServers, WebPorts, server1, server2)
- [ ] Remote admin rule added on WAN
- [ ] Restrictive DMZ rules configured and applied
- [ ] Stateful behavior demonstrated (ping continues after rule change, stops after state kill)
- [ ] Firewall logs reviewed and interpreted
This concludes Lab 2.
Previous Module: Section 2 — Interfaces and Firewall Rules
Source: Netgate FUND001-LIVE-Lab2-Rules.pdf