Course menu

Module 3: NATLesson 3.4 (4 of 4 in this module)14 of 18 in the FortiGate Administrator course

Lab: outbound pools and a published web server

Give the LAN an IP pool, publish WEB1 on HTTPS with a VIP, allow hairpin access from the LAN, and fix four NAT faults.

Intermediate · 25 min read

What you will learn

After this lesson, you can configure outbound translation with an IP pool, publish a server with a VIP and policy, make it reachable from inside by its public address, and find the faults that break each step.

  • IP pools
  • VIPs
  • Hairpin
  • Troubleshooting

NAT on a FortiGate changes addresses as traffic passes: source NAT for connections leaving towards the Internet (the interface address or an IP pool), and destination NAT with virtual IPs for connections arriving for published servers. In the default policy NAT mode both are tied to firewall policies.

In simple terms: Going out, inside addresses are swapped for public ones. Coming in, a public address is swapped for the inside server's.

The situation

FGT1 runs the rule base from the policy lab. The ISP now routes 203.0.113.16/29 to FGT1 as well as the port1 link. Requirements:

  • Staff browsing must leave from 203.0.113.17–203.0.113.18, not from the port1 address.
  • www.example.com (203.0.113.20) must reach WEB1 (10.0.2.10) on HTTPS from the Internet.
  • Staff must reach www.example.com by its public address too.
port1203.0.113.0/30port210.0.1.0/24port310.0.2.0/24InternetISP gateway 203.0.113.1FGT1FortiGatePC1LAN · 10.0.1.10WEB1DMZ · 10.0.2.10
  1. 1. Outbound: LAN traffic is translated to an address from Staff-Pool.
  2. 2. Inbound: HTTPS to 203.0.113.20 is translated to 10.0.2.10 by the VIP.

Task 1: the IP pool on the Internet policy

Show the configuration
config firewall ippool edit Staff-Pool set type overload set startip 203.0.113.17 set endip 203.0.113.18 next end config firewall policy edit 3 set ippool enable set poolname "Staff-Pool" next end

Policy 3 (LAN-to-Internet) already has nat enable; selecting the pool switches it from the interface address to the pool.

Task 2: publish WEB1

Show the configuration
config firewall vip edit VIP-WEB1-HTTPS set extintf "any" set extip 203.0.113.20 set mappedip "10.0.2.10" set portforward enable set extport 443 set mappedport 443 next end config firewall policy edit 6 set name "Internet-to-WEB1" set srcintf "port1" set dstintf "port3" set srcaddr "all" set dstaddr "VIP-WEB1-HTTPS" set action accept set schedule "always" set service "HTTPS" set logtraffic all next move 6 before 4 end

Policy 4 is the logged deny-all from the policy lab, so new policies must move above it.

Task 3: hairpin access from the LAN

Show the configuration
config firewall policy edit 7 set name "LAN-to-WEB1-public" set srcintf "port2" set dstintf "port3" set srcaddr "LAN-subnet" set dstaddr "VIP-WEB1-HTTPS" set action accept set schedule "always" set service "HTTPS" set logtraffic all next move 7 before 4 end

Task 4: verify

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # diagnose sys session list | grep act=
hook=post dir=org act=snat 10.0.1.10:52011->198.51.100.80:443(203.0.113.18:52011)
hook=pre dir=org act=dnat 198.51.100.77:60311->203.0.113.20:443(10.0.2.10:443)
hook=pre dir=org act=dnat 10.0.1.10:52040->203.0.113.20:443(10.0.2.10:443)
Line 1: browsing leaves from the pool. Line 2: an Internet visitor reaches WEB1 through the VIP. Line 3: PC1 reaches WEB1 by its public address (hairpin). (Reply lines removed; example output.)

Find the fault

Fault 1

Nobody on the Internet can reach www.example.com. Debug flow shows:

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # (debug flow, trimmed)
msg="vd-root:0 received a packet(proto=6, 198.51.100.77:60400->203.0.113.20:443) from port1. flag [S], ..."
msg="find DNAT: IP-10.0.2.10, port-443"
msg="find a route: flag=00000000 gw-10.0.2.10 via port3"
msg="Denied by forward policy check (policy 4)"
Show diagnosis

The VIP works (DNAT found) and the route is right, but no accept policy matched. show firewall policy 6 shows set dstaddr "WEB1": in policy NAT mode the destination must be the VIP object. Fix: set dstaddr "VIP-WEB1-HTTPS".

Fault 2

The site works from the Internet, but from the LAN https://www.example.com times out. Policy 7 exists.

Show diagnosis

The VIP has set extintf "port1", so it only translates traffic arriving on port1. PC1's packet to 203.0.113.20 arrives on port2, isn't translated, and is routed towards the Internet. Fix: set extintf "any" on the VIP (or use split DNS).

Fault 3

A partner reports that the office still connects from 203.0.113.2, not from the pool.

Show diagnosis

Policy 3 has set poolname "Staff-Pool" but ippool is still disabled, so NAT uses the interface address. Fix: set ippool enable. (Also check that no policy above 3 matches the partner's traffic first.)

Fault 4

Internet users' connections to WEB1 hang. A session with act=dnat appears, and the sniffer shows:

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # diagnose sniffer packet any 'host 10.0.2.10 and port 443' 4
port1 in 198.51.100.77.60500 -> 203.0.113.20.443: syn 1849302
port3 out 198.51.100.77.60500 -> 10.0.2.10.443: syn 1849302
port1 in 198.51.100.77.60500 -> 203.0.113.20.443: syn 1849302
port3 out 198.51.100.77.60500 -> 10.0.2.10.443: syn 1849302
Show diagnosis

FGT1 forwards the SYN to WEB1, but no SYN-ACK ever comes back through port3, and the client retries. WEB1 answers through another gateway: its default gateway is 10.0.2.254 instead of FGT1 (10.0.2.1). Fix: set WEB1's default gateway to 10.0.2.1, so replies return through the session on FGT1.

Check yourself

Predict · scenario 1

In policy NAT mode, what must be the destination of the policy that allows traffic to a VIP?

Predict · scenario 2

Which VIP setting lets LAN users reach WEB1 through its public address?

Predict · scenario 3

The sniffer shows SYNs leaving port3 to WEB1 but no SYN-ACKs returning. What is the likely cause?