View source for Training Lab 3: NAT and Virtual IPs

__NOTOC__

<div style="background-color: #fff3e0; border-left: 6px solid #FF9800; padding: 16px; margin-bottom: 20px;">
<strong>Lab Overview:</strong> This hands-on lab covers Virtual IPs, Port Forwards, 1:1 NAT, and Outbound NAT in pfSense Plus. You will configure VIPs on the WAN subnet <code>192.0.2.0/24</code> and implement various NAT scenarios using Virtual IPs <code>192.0.2.4</code>–<code>192.0.2.6</code>.
</div>

== Lab Environment ==

{| class="wikitable"
|+ WAN Subnet Allocation
|-
! IP Address !! Purpose
|-
| 192.0.2.1 || ISP router (default gateway)
|-
| 192.0.2.2 || fw1-HQ WAN IP
|-
| 192.0.2.3 || Reserved for fw2-HQ (Advanced Application class)
|-
| 192.0.2.4 || Virtual IP — server1 WAN external address
|-
| 192.0.2.5 || Virtual IP — server2 WAN external address
|-
| 192.0.2.6 || Virtual IP — hq-client / VoIP PBX alternate outbound
|}

== Exercise 1: Configuring Virtual IPs ==

At HQ, we have a /24 public IP subnet assigned by our ISP: <code>192.0.2.0/24</code>. In most real-world networks, this will be a smaller subnet such as a /29, /28, or /27. The concepts are the same regardless of subnet size.

Our WAN1 ISP router has IP <code>192.0.2.1</code>, used as the default gateway. fw1-HQ has a WAN IP of <code>192.0.2.2</code>. In order for us to use additional IPs in the WAN1 subnet, the firewall must answer ARP requests for those addresses — this tells the ISP router to send traffic destined to those addresses to the firewall.

=== Step 1.1 — Add VIP 192.0.2.4 ===

On fw1-HQ, browse to '''Firewall → Virtual IPs'''.

Click '''+ Add''' to add a new VIP.

{| class="wikitable"
|+ VIP Configuration for server1
|-
! Field !! Value
|-
| Type || IP alias
|-
| Interface || WAN
|-
| IP Address || 192.0.2.4/32
|-
| Description || server1 WAN external address
|}

'''Note:''' You can enter the IP without choosing a mask; the JavaScript on the page will automatically set the mask to /32 after detecting an IPv4 address.

Click '''Save''', then click '''+ Add''' again to add the second VIP.

=== Step 1.2 — Add VIP 192.0.2.5 ===

{| class="wikitable"
|+ VIP Configuration for server2
|-
! Field !! Value
|-
| Type || IP alias
|-
| Interface || WAN
|-
| IP Address || 192.0.2.5/32
|-
| Description || server2 WAN external
|}

Click '''Save''', then add the third VIP.

=== Step 1.3 — Add VIP 192.0.2.6 ===

{| class="wikitable"
|+ VIP Configuration for PBX / alternate outbound
|-
! Field !! Value
|-
| Type || IP alias
|-
| Interface || WAN
|-
| IP Address || 192.0.2.6/32
|-
| Description || VoIP PBX / alternate outbound IP
|}

Click '''Save''', then click '''Apply Changes'''.

Now <code>192.0.2.4</code>, <code>192.0.2.5</code>, and <code>192.0.2.6</code> are available for use. Adding VIPs only makes the firewall answer on the configured addresses; they are not yet used for NAT.

== Exercise 2: Configuring a Basic Port Forward ==

We will set up a port forward allowing remote desktop access from the host machine to hq-client using VNC.

'''Warning:''' Opening VNC to the Internet is not recommended in production. Use a VPN instead. This is for demonstration purposes only.

=== Step 2.1 — Create VNC Port Forward ===

On fw1-HQ, browse to '''Firewall → NAT''', Port Forward tab. Click '''Add'''.

{| class="wikitable"
|+ VNC Port Forward Rule
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || TCP
|-
| Source || any
|-
| Destination || WAN address
|-
| Destination port || 5900
|-
| Redirect target IP || 172.17.1.100
|-
| Redirect target port || 5900
|-
| Description || forward VNC to hq-client
|}

Click '''Save''', and '''Apply Changes'''.

=== Step 2.2 — Verify the Port Forward ===

From your host OS or the internet-host VM, connect to <code>192.0.2.2:5900</code> with VNC Viewer.

On fw1-HQ, browse to '''Diagnostics → States''' and filter for <code>:5900</code>. You will see two states: inbound (WAN) and outbound (LAN).

== Exercise 3: Port Forward on a Different External Port ==

Sometimes you need to use a different external port than the internal port. For example, opening SSH on port 222 externally to port 22 internally reduces SSH brute-force log noise.

=== Step 3.1 — Create Alternate SSH Port Forward ===

Instead of clicking '''Add''', click the '''copy''' icon to the right of the VNC port forward to duplicate it. Then change:

{| class="wikitable"
|+ Alternate SSH Port Forward Rule
|-
! Field !! Value
|-
| Destination port || 222
|-
| Redirect target port || 22
|-
| Description || external SSH port 222 to hq-client
|}

Click '''Save''' and '''Apply Changes'''.

=== Step 3.2 — Test SSH Connection ===

From your computer, run:

<pre>
ssh -p 222 training@192.0.2.2
</pre>

Or from Windows, use PuTTY with IP <code>192.0.2.2</code> and port <code>222</code>, ensuring SSH is selected.

== Exercise 4: Restricted Source Port Forward ==

Restrict the hq-client VNC port forward to the RemoteAdmins alias.

=== Step 4.1 — Edit VNC Port Forward ===

Edit the VNC port forward. In the '''Source''' field, click '''Advanced'''.

* Type: '''Single host or alias'''
* Address: Type <code>r</code> to populate the '''RemoteAdmin''' alias
* Source port: '''any'''

Save and apply changes.

=== Step 4.2 — Verify Restriction ===

* From the remote-host VM (if not in RemoteAdmin alias): connection should fail
* From the host OS (if in RemoteAdmin alias): connection should succeed

== Exercise 5: Alternate External IP Port Forward ==

Use the Virtual IPs added earlier instead of the WAN IP.

=== Step 5.1 — Create HTTP Port Forward on VIP ===

Click '''Add''' to add a new port forward.

{| class="wikitable"
|+ HTTP to server1 via VIP
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || TCP
|-
| Source || any
|-
| Destination || 192.0.2.4
|-
| Destination port || 80
|-
| Redirect target IP || 172.17.2.10
|-
| Redirect target port || 80
|-
| Description || HTTP to server1
|}

Save and apply changes.

=== Step 5.2 — Verify HTTP Access ===

Browse to <code>http://192.0.2.4</code> from your host OS or internet-host VM. It should display the server1 page.

'''Note:''' Reflection is not yet configured, so this will only work from outside the network.

== Exercise 6: Configuring 1:1 NAT ==

1:1 NAT maps one external IP to one internal IP. Port forwards take precedence over 1:1 NAT where they overlap.

=== Step 6.1 — Delete Overlapping Port Forward ===

First, delete the '''HTTP to server1''' port forward entry, then apply changes. This is preferable to letting 1:1 NAT handle the traffic.

=== Step 6.2 — Configure 1:1 NAT for server1 ===

Browse to '''Firewall → NAT''', 1:1 tab. Click '''Add'''.

{| class="wikitable"
|+ 1:1 NAT for server1
|-
! Field !! Value
|-
| Interface || WAN
|-
| External || 192.0.2.4
|-
| Internal || 172.17.2.10
|-
| Description || server1
|}

Save and apply changes.

'''Important:''' Adding a 1:1 NAT entry only defines how traffic is translated. Without firewall rules, no traffic will pass in or out.

=== Step 6.3 — Configure 1:1 NAT for server2 ===

Click '''Add''' to add another 1:1 NAT entry.

{| class="wikitable"
|+ 1:1 NAT for server2
|-
! Field !! Value
|-
| Interface || WAN
|-
| External || 192.0.2.5
|-
| Internal || 172.17.2.20
|-
| Description || server2.example.com
|}

Save and apply changes.

== Exercise 7: Firewall Rules for 1:1 NAT ==

=== Step 7.1 — Allow Pings to Public Web Servers ===

Browse to '''Firewall → Rules''', WAN tab. Click '''Add'''.

{| class="wikitable"
|+ ICMP Rule for Web Servers
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || ICMP
|-
| ICMP Type || Echo request
|-
| Source || any
|-
| Destination || Single host or alias — WebServers alias
|-
| Description || allow pings to public web servers
|}

Save and apply changes.

Test by pinging <code>192.0.2.4</code> from your host machine:

<pre>
ping 192.0.2.4
</pre>

Leave the ping running and browse to '''Diagnostics → States'''. Filter for <code>192.0.2.100:</code> (if from host OS) and observe the states. Traffic sourced from <code>192.0.2.100</code> to <code>192.0.2.4</code> is translated to <code>172.17.2.10</code>.

=== Step 7.2 — Allow SSH to Web Servers from RemoteAdmins ===

{| class="wikitable"
|+ SSH Rule for RemoteAdmins
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || TCP
|-
| Source || Single host or alias — RemoteAdmins alias
|-
| Destination || Single host or alias — WebServers alias
|-
| Destination port || 22
|-
| Description || allow SSH to web servers from remote admin
|}

Save and apply changes.

From your host machine, test:

<pre>
ssh training@192.0.2.4
</pre>

=== Step 7.3 — Allow Web Access to Public Web Servers ===

{| class="wikitable"
|+ HTTP/HTTPS Rule for Web Servers
|-
! Field !! Value
|-
| Interface || WAN
|-
| Protocol || TCP
|-
| Source || any
|-
| Destination || Single host or alias — WebServers
|-
| Destination port || WebPorts alias
|-
| Description || allow web ports to public web servers
|}

Save and apply changes.

Now browse to <code>http://192.0.2.4</code> (server1) and <code>http://192.0.2.5</code> (server2).

== Exercise 8: Configuring Outbound NAT ==

Outbound NAT defines whether and how the source IP of matching traffic will be translated when it leaves an interface.

=== Step 8.1 — Switch to Manual Outbound NAT ===

Browse to '''Firewall → NAT''', Outbound tab. Select '''Manual Outbound NAT''', then click '''Save'''.

The system auto-populates the outbound NAT ruleset with the rules it was automatically generating previously. The configured manual rules take effect only upon applying changes.

=== Step 8.2 — Clean Up Auto-Generated Rules ===

The auto-generated rules include:

* LAN subnet, DMZ subnet, and loopback <code>127.0.0.0/8</code>
* IPv6 rules
* Static port for UDP port 500 (for non-NAT-T IPsec VPN clients)

Clean up by:

* Deleting the <code>127.0.0.0/8</code> rule (unusual circumstance)
* Deleting IPv6 rules (not using IPv6)
* Deleting UDP port 500 rules (nearly unheard of today)
* Replacing LAN and DMZ subnets with the summarized <code>172.17.0.0/16</code>

Edit the '''LAN to WAN''' rule:

{| class="wikitable"
|+ Consolidated Outbound NAT Rule
|-
! Field !! Value
|-
| Interface || WAN
|-
| Source || 172.17.0.0/16
|-
| Destination || any
|-
| Translation || Interface address
|}

Delete all other outbound NAT rules. Your list should have one rule.

'''Important:''' 1:1 NAT entries take precedence over outbound NAT. server1 traffic goes out via <code>192.0.2.4</code> and server2 via <code>192.0.2.5</code> regardless of outbound NAT rules.

=== Step 8.3 — Send hq-client Out via Alternate IP ===

Click the top '''Add''' button to add the new rule at the top of the list.

{| class="wikitable"
|+ Outbound NAT for hq-client
|-
! Field !! Value
|-
| Interface || WAN
|-
| Source || 172.17.1.100/32
|-
| Destination || any
|-
| Translation || 192.0.2.6
|-
| Description || hq-client out via .6
|}

Ensure this rule is above the <code>172.17.0.0/16</code> rule, since the first match wins.

=== Step 8.4 — Static Port for VoIP PBX ===

NAT can break VoIP. If rewriting source ports breaks SIP/RTP, configure static port for the PBX.

Assume a PBX at <code>172.17.1.200</code>. Click the '''copy''' icon next to the hq-client outbound NAT rule, then change:

{| class="wikitable"
|+ Outbound NAT for VoIP PBX
|-
! Field !! Value
|-
| Source || 172.17.1.200/32
|-
| Destination || any
|-
| Translation || Address 192.0.2.6, Static port checked
|-
| Description || VoIP PBX static port
|}

Ensure this rule is above the <code>172.17.0.0/16</code> rule.

== Lab Summary ==

In this lab, you learned to:

* Configure IP Alias Virtual IPs on the WAN interface
* Create Port Forwards (same port, alternate port, restricted source, alternate external IP)
* Configure 1:1 NAT mappings
* Add firewall rules to permit traffic through 1:1 NAT
* Switch from Automatic to Manual Outbound NAT
* Configure alternate outbound IPs and static port for VoIP

== Next Module ==

Proceed to the next training module. Return to the '''[[Training:_NAT_and_Virtual_IPs|NAT and Virtual IPs — Lecture Slides]]''' for review.

----

''Source: Netgate FUND001-LIVE-SLIDE-SEG3-NATVIP.pdf / FUND001-LIVE-Lab3-NATandVIPs.pdf''