Justinaquino: Created page with "NOTOC
'''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:_Initial_Confi..."

2026-04-23T06:58:28Z

Created page with "__NOTOC__ <div style="background-color:#fff3e6; border:1px solid #cc6600; padding:10px; margin-bottom:15px;"> '''Lab 2: Interfaces, Firewall Rules, and Aliases'''<br> 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 <code>https://172.17.1.1</code>. </div> == Prerequisites == * Lab topology from Training_Lab_1:_Initial_Confi..."

New page

__NOTOC__

<div style="background-color:#fff3e6; border:1px solid #cc6600; padding:10px; margin-bottom:15px;">
'''Lab 2: Interfaces, Firewall Rules, and Aliases'''<br>
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 <code>https://172.17.1.1</code>.
</div>

== Prerequisites ==

* Lab topology from [[Training_Lab_1:_Initial_Configuration|Training Lab 1]] is in place
* '''HQ LAN:''' <code>172.17.1.0/24</code>
* '''HQ DMZ:''' <code>172.17.2.0/24</code>
* 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 <code>vtnet0</code> to <code>vtnet4</code>. Our DMZ interface will be '''OPT1''', which is assigned to <code>vtnet2</code>.

=== Step 2: Enable and Configure OPT1 ===

Browse to '''Interfaces > OPT1''' and configure:

{| class="wikitable"
! 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 <code>config.xml</code>, but the interface is displayed as '''DMZ'''.

== Exercise 2: Test Connectivity to DMZ ==

=== Ping the DMZ Gateway ===

From the HQ-Client VM:

<pre>
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
</pre>

=== Ping server1 from HQ-Client ===

<pre>
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
</pre>

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:

<pre>
training@hq-client:~$ ssh training@172.17.2.10
Password for training@server1: password
</pre>

From server1, attempt to ping:

<pre>
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
</pre>

=== Troubleshooting: Check ARP Cache ===

Check the ARP cache to confirm Layer 2 connectivity:

<pre>
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]
</pre>

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:

{| class="wikitable"
! Setting
! Value
|-
| Action
| Pass
|-
| Interface
| DMZ
|-
| Protocol
| any
|-
| Source
| any
|-
| Destination
| any
|}

'''Save and Apply Changes.'''

Verify connectivity from server1:

<pre>
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
</pre>

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 ===

{| class="wikitable"
! 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 ===

{| class="wikitable"
! Field
! Value
|-
| Name
| server1
|-
| Description
| server1.example.com
|-
| Type
| Host
|-
| Member
| 172.17.2.10
|}

=== Alias: server2 ===

{| class="wikitable"
! Field
! Value
|-
| Name
| server2
|-
| Description
| server2.example.com
|-
| Type
| Host
|-
| Member
| 172.17.2.20
|}

=== Alias: DNSservers ===

{| class="wikitable"
! Field
! Value
|-
| Name
| DNSservers
|-
| Type
| Host
|-
| Members
| server1, server2
|}

=== Alias: SMTPservers ===

{| class="wikitable"
! Field
! Value
|-
| Name
| SMTPservers
|-
| Description
| authorized outbound SMTP servers
|-
| Type
| Host
|-
| Members
| server1
|}

=== Alias: RemoteAdmin ===

{| class="wikitable"
! Field
! Value
|-
| Name
| RemoteAdmin
|-
| Description
| IPs authorized for remote management
|-
| Type
| Host
|-
| Members
| 192.0.2.100 (student's system)
|}

=== Alias: WebServers ===

{| class="wikitable"
! Field
! Value
|-
| Name
| WebServers
|-
| Description
| publicly-reachable web servers
|-
| Type
| Host
|-
| Members
| server1, server2
|}

=== Alias: WebPorts ===

{| class="wikitable"
! 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''':

{| class="wikitable"
! 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:

<pre>
$ ping 192.0.2.2
$ curl -I https://192.0.2.2
</pre>

== 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 ===

{| class="wikitable"
! 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 ===

{| class="wikitable"
! 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 ===

{| class="wikitable"
! 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 ===

{| class="wikitable"
! 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 ===

{| class="wikitable"
! 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) ===

{| class="wikitable"
! 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:

<pre>
training@server1:~ % ping 172.17.1.100
</pre>

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 <code>172.17.2.10:</code> (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 <code>USER_RULE</code> with the configured description.

== Troubleshooting Reference ==

{| class="wikitable"
! 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 <code>arp -an</code> 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 ==

{| class="wikitable"
! 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:''' [[Training:_Interfaces_and_Firewall_Rules|Section 2 — Interfaces and Firewall Rules]]

''Source: Netgate FUND001-LIVE-Lab2-Rules.pdf''

Training Lab 2: Firewall Rules and Aliases - Revision history