Advanced FortiGate installation and setup : Protecting a web server on a DMZ network
  
Protecting a web server on a DMZ network
Problem
You need to keep a web server secure and available from the Internet and from an internal private network.
Solution
This solution protects and provides access to the web server by:
Installing the web server on a DMZ (demilitarized zone) network separate from your internal network that exposes the web server to the Internet and the internal network.
Connecting the DMZ network to a FortiGate interface (the DMZ interface or any other available interface).
Creating a destination NAT (DNAT) security policy that includes UTM protection and that allows users on the Internet to access the web server.
Creating a route mode security policy that allows users on the internal network to access the web server.
 
When you connect multiple networks to your FortiGate unit, you might want to add interface aliases that describe the function of the interface or the network connected to it. Aliases are easy to add: go to System > Network > Interface, edit an interface and then add descriptive text to the Alias field. The alias appears with the interface name in most places on the web‑based manager.
Connecting the networks to the FortiGate unit and configuring IP settings
1 Connect the DMZ network to the FortiGate DMZ interface the internal network to the internal interface and the Internet to the wan1 interface (or any available interfaces).
2 Go to System > Network > Interface.
3 Edit the dmz interface:
Alias
DMZ server network
Addressing mode
Manual
IP/Netmask
10.10.10.10/255.255.255.0
4 Edit the internal interface:
Alias
Private internal network
Addressing mode
Manual
IP/Netmask
192.168.1.99/255.255.255.0
5 Edit the wan1 interface:
Alias
Internet
Addressing mode
Manual
IP/Netmask
172.20.120.14/255.255.255.0
6 Go to Router > Static > Static Route and Edit the default route as follows.
Destination IP/Mask
0.0.0.0/0.0.0.0
Device
wan1(Internet)
Gateway
172.20.120.2
7 Go to System > Network > DNS and add Primary and Secondary DNS servers.
8 Configure the web server’s IP network settings.
IP address
10.10.10.123
Netmask
255.255.255.0
Default Gateway
10.10.10.10
DNS Servers
IP addresses of available DNS servers.
 
If the web server does not have the correct default gateway, its response packets will not reach the DMZ interface, so the web server will appear to not be responding.
Create a DNAT security policy to allow sessions from the Internet to the web server
Configure DNAT (port forwarding) by creating a firewall virtual IP (VIP) that maps the Internet address of the web server (172.20.120.123) to the actual IP address of the web server on the DMZ network (10.10.10.123). Then, add this VIP to a security policy that allows users on the Internet to browse to the Internet address of the web server (in this example, 172.20.120.123) to connect through the FortiGate unit to the web server on the DMZ network.
1 Go to Firewall Objects > Virtual IP > Virtual IP and select Create New to add a new virtual IP with the following settings:
Name
Web-server-DNAT
External Interface
wan1(Internet)
Type
Static NAT
External IP Address/Range
172.20.120.123
Mapped IP Address/Range
10.10.10.123
2 Go to Policy > Policy > Policy and select Create New to add a security policy to allow users on the Internet to connect to the web server on the DMZ network.
Source Interface/Zone
wan1(Internet)
Source Address
all
Destination Interface/Zone
dmz(DMZ server network)
Destination Address
Web-server-DNAT
Schedule
always
3 Beside Service, select Multiple and add HTTP and HTTPS to the Members list.
4 Set Action to ACCEPT.
5 Select UTM and select Enable AntiVirus, Enable Application Control, and Enable IPS.
6 Select OK to save the security policy.
Create a route mode security policy to allow users on the internal network to connect to the web server on the DMZ network
By using a route mode policy, users on the internal network can connect to the web server using its real DMZ IP address (by browsing to http://10.10.10.123 or https://10.10.10.123). Since users on the internal network know the real address of the web server, you do not have to enable NAT in the security policy that allows this access.
1 Go to Firewall Objects > Address > Address and select Create New to add a firewall address for the user address range on the internal network.
Address Name
Internal-user-addresses
Type
Subnet / IP Range
Subnet / IP Range
192.168.1.100 -192.168.1.150 (can also be entered as 192.168.1.[100-150])
Interface
Internal(Private internal network)
2 Select Create New to add a firewall address for the web server on the DMZ network.
Address Name
DMZ-web-server-address
Type
Subnet / IP Range
Subnet / IP Range
10.10.10.123/255.255.255.255
Interface
dmz(DMZ server network)
3 Go to Policy > Policy > Policy and select Create New to add a security policy that allows users on the internal network to connect to the DMZ network.
Source Interface/Zone
Internal(Private internal network)
Source Address
Internal-user-addresses
Destination Interface/Zone
dmz(DMZ server network)
Destination Address
DMZ-web-server-address
Schedule
Always
4 Beside Service, select Multiple and add HTTP and HTTPS to the Members list.
5 Set Action to ACCEPT.
6 Select UTM and select Enable AntiVirus, Enable Application Control, and Enable IPS.
7 Select OK to save the security policy.
 
For this policy, you could have selected Enable NAT to enable source NAT. However, doing this would mean that all packets from the internal network connecting to the web server would have the same source address (the IP address of the DMZ interface). If you do not select Enable NAT you can record web server usage according to the actual source address of sessions from the internal network.
Add a security policy to allow users on the internal network to connect to the Internet
1 Go to Policy > Policy > Policy and select Create New to add the following security policy.
Source Interface/Zone
Internal(Private internal network)
Source Address
Internal-user-addresses
Destination Interface/Zone
wan1(Internet)
Destination Address
all
Schedule
Always
Service
ANY
Action
ACCEPT
2 Select UTM and select Enable AntiVirus and Enable Application Control.
3 Select OK to save the security policy.
Results
Test the configuration by connecting to the web server from the internal network and from the Internet.
 
If any of the following tests fail, re-check your FortiGate configuration. Also, make sure the web server has the correct default route. This is especially important for connections from the internal network because the security policies do not perform source NAT, so the web server needs the correct default route to be able to send return packets correctly. You can also try the steps described in “Troubleshooting NAT/Route mode installations” .
Testing the connection from the internal network to the web server
From the internal network, browse to the web server’s actual IP address (http://10.10.10.123 or https://10.10.10.123). The connection should be successful. This communication uses the internal to dmz policy. Go to Policy > Monitor > Policy Monitor to view sessions accepted by the internal to dmz policy (in the example, policy 3). Sessions for other policies may also be visible.
Drill down to view details about the sessions accepted by the policy. They should all be HTTP (port 80) or HTTPS (port 443) sessions. The source address should be an address on the internal network and the destination address should be the real address of the web server (10.10.10.123). The NAT columns should be blank because no address translation is taking place.
You can also view similar session information using the FortiGate packet sniffer. The following sniffer output shows HTTP traffic (port 80) between a PC with IP address 192.168.1.110 and the web server (IP address 10.10.10.123). You can see the HTTP sessions between the PC and the internal interface and between the dmz interface and the web server. Note that the source and destination addresses and ports are not translated:
 
 
diagnose sniffer packet any 'port 80' 4 10
interfaces=[any]
filters=[port 80]
5.360359 internal in 192.168.1.110.4359 -> 10.10.10.123.80: syn 2514178891
5.361982 internal out 10.10.10.123.80 -> 192.168.1.110.4359: syn 656842736 ack 2514178892
5.362165 internal in 192.168.1.110.4359 -> 10.10.10.123.80: ack 656842737
5.362463 internal in 192.168.1.110.4359 -> 10.10.10.123.80: psh 2514178892 ack 656842737
5.366684 internal out 10.10.10.123.80 -> 192.168.1.110.4359: ack 2514179678
5.370189 dmz out 192.168.1.110.4359 -> 10.10.10.123.80: syn 1168283220
5.370411 dmz in 10.10.10.123.80 -> 192.168.1.110.4359: syn 1433097504 ack 1168283221
5.370606 dmz out 192.168.1.110.4359 -> 10.10.10.123.80: ack 1433097505
5.375160 dmz out 192.168.1.110.4359 -> 10.10.10.123.80: psh 1168283221 ack 1433097505
5.375417 dmz in 10.10.10.123.80 -> 192.168.1.110.4359: ack 1168284007
The following FortiGate sniffer output shows HTTPS traffic (port 443) between IP address 192.168.1.110 and the web server (IP address 10.10.10.123). You can see the HTTPS sessions between the PC and the internal interface and between the dmz interface and the web server. Note that the source and destination addresses and ports are not translated:
diagnose sniffer packet any 'port 443' 4 10
interfaces=[any]
filters=[port 443]
5.124564 internal in 192.168.1.110.4366 -> 10.10.10.123.443: syn 3141078769     
5.128308 dmz out 192.168.1.110.4366 -> 10.10.10.123.443: syn 3141078769
5.128538 dmz in 10.10.10.123.443 -> 192.168.1.110.4366: syn 2403170564 ack 3141078770
5.130991 internal out 10.10.10.123.443 -> 192.168.1.110.4366: syn 2403170564 ack 3141078770
5.131151 internal in 192.168.1.110.4366 -> 10.10.10.123.443: ack 2403170565
5.131414 dmz out 192.168.1.110.4366 -> 10.10.10.123.443: ack 2403170565
5.131702 internal in 192.168.1.110.4366 -> 10.10.10.123.443: psh 3141078770 ack 2403170565
5.138192 dmz out 192.168.1.110.4366 -> 10.10.10.123.443: psh 3141078770 ack 2403170565
5.138361 dmz in 10.10.10.123.443 -> 192.168.1.110.4366: ack 3141078914
5.138632 internal out 10.10.10.123.443 -> 192.168.1.110.4366: ack 3141078914
You could also use the following sniffer command to get similar results:
diagnose sniffer packet any 'host 192.168.1.110 or 10.10.10.123' 4 10
Testing the connection from the Internet to the web server
From any location on the Internet, (or any location on the 172.20.120.0 network), browse to the web server’s Internet IP address (http://172.20.120.123 or https://172.20.120.123). The connection should be successful. This communication uses the wan1 to dmz policy. Go to Policy > Monitor > Policy Monitor to view the sessions accepted by security policies. The policy monitor should show sessions accepted by the internal to dmz policy.
Drill down to view details about the sessions accepted by the policy. They should all be HTTP (port 80) or HTTPS (port 443) sessions. The source address should be an address on the Internet (or the 172.20.120.0 network) and the destination address should be the Internet address of the web server (172.20.120.123). The wan1 to DMZ policy performs DNAT on incoming packets, translating the destination IP address of the packets from 172.20.120.123 to 10.10.10.123. The destination NAT IP address is shown in the Src NAT IP column when destination NAT is taking place. The destination ports are not translated so the Src NAT Port column and Dst Port column both show port 80.
You can also view similar information using the packet sniffer. The following sniffer output shows HTTP traffic (destination port 80) from 172.20.120.12 to 172.20.120.123. All packets received by the wan1 interface have a source address of 172.20.120.12 and a destination address of 172.20.120.123. All packets exiting from the dmz interface have a source address of 172.20.120.12 and a destination address of 10.10.10.123:
diagnose sniffer packet any 'port 80' 4 10
interfaces=[any]
filters=[port 80]
5.384633 wan1 in 172.20.120.12.59485 -> 172.20.120.123.80: syn 3310195461
5.390855 wan1 out 172.20.120.123.80 -> 172.20.120.12.59485: syn 1257313456 ack 3310195462
5.392429 wan1 in 172.20.120.12.59485 -> 172.20.120.123.80: ack 1257313457
5.392970 wan1 in 172.20.120.12.59485 -> 172.20.120.123.80: psh 3310195462 ack 1257313457
5.402474 wan1 out 172.20.120.123.80 -> 172.20.120.12.59485: ack 3310196396
5.404772 dmz out 172.20.120.12.59485 -> 10.10.10.123.80: syn 3794602648
5.405014 dmz in 10.10.10.123.80 -> 172.20.120.12.59485: syn 4209798675 ack 3794602649
5.405236 dmz out 172.20.120.12.59485 -> 10.10.10.123.80: ack 4209798676
5.406434 dmz out 172.20.120.12.59485 -> 10.10.10.123.80: psh 3794602649 ack 4209798676
5.406689 dmz in 10.10.10.123.80 -> 172.20.120.12.59485: ack 3794603583
The following sniffer output shows HTTPS traffic (destination port 443) from 172.20.120.12 172.20.120.123. You can see the HTTPS sessions between the PC and the wan1 interface and between the dmz interface and the web server. Note that the source and destination addresses and ports are not translated:
diagnose sniffer packet any 'port 443' 4 10
interfaces=[any]
filters=[port 443]
4.557201 wan1 in 172.20.120.12.59666 -> 172.20.120.123.443: syn 2276259104
4.561331 dmz out 172.20.120.12.59666 -> 10.10.10.123.443: syn 2276259104
4.561577 dmz in 10.10.10.123.443 -> 172.20.120.12.59666: syn 3539944843 ack 2276259105
4.562214 wan1 out 172.20.120.123.443 -> 172.20.120.12.59666: syn 3539944843 ack 2276259105
4.562974 wan1 in 172.20.120.12.59666 -> 172.20.120.123.443: ack 3539944844
4.563323 dmz out 172.20.120.12.59666 -> 10.10.10.123.443: ack 3539944844
4.563540 wan1 in 172.20.120.12.59666 -> 172.20.120.123.443: psh 2276259105 ack 3539944844
4.570165 dmz out 172.20.120.12.59666 -> 10.10.10.123.443: psh 2276259105 ack 3539944844
4.570270 dmz in 10.10.10.123.443 -> 172.20.120.12.59666: ack 2276259473
4.570566 wan1 out 172.20.120.123.443 -> 172.20.120.12.59666: ack 2276259473
You could also use the following sniffer command to get similar results:
diagnose sniffer packet any 'host 172.20.120.12 or 172.20.120.123' 4 10