| Description | This article describes how to configure FortiGate to perform DNAT (VIP) and SNAT together on the same packet in cases where it needs to masquerade (hide) both the original source IP and destination IP. |
| Scope | FortiGate. |
| Solution |
Topology:
Using VIP (DNAT) to hide the real IP of the Application server is quite common: this operation translates the destination IP so users on the internet (or the other side), do not see or know the actual IP of the server hosting the application being use by them. However, there are times when the a need to hide the source IP as well, this might be due to the fact that the source IP subnet/range already existed on the network where the Application server is sitting, therefore creating IP address clash, which will result in routing issue on return traffic. This is when or scenario where NATing the source IP as well became necessary. This article depicts a source with 10.10.10.10, and this IP already exists on the network where the App server resides (so 10.10.10.10 must be masqueraded (hidden) in a similar way to the real server IP). Since FortiGate uses Central SNAT in this case, the configuration is slightly different from when Central SNAT is not in play.
Here are the needed configurations:
It is also possible to not enable 'port-forwarding'. Also, filtering source is optional.
From CLI:
config firewall vip edit "DNAT-POLICY" set src-filter "10.10.10.10" set extip 200.200.200.200 set mappedip "192.168.168.168" set extintf "any" set portforward enable <----- Optional. set extport 443 <----- As applicable to the environment. set mappedport 443 <----- As applicable to the environment. next end
This is where the SNAT, which masquerades (hides) the source IP takes place. In this example, 10.10.10.10 was NATed to 190.190.190.190 using IP-Pool (IP pool is needed in this case because IP 190.190.190.190 is not the IP configured on the outgoing interface). It is possible to NAT the source IP to the 'Outgoing Interface Address' if that is practicable in the environment.
From CLI:
config firewall central-snat-map edit 1 set srcintf "INCOMING-INTF" set dstintf "OUTGOING-INTF" set orig-addr "10.10.10.10" <----- Source IP of user. set dst-addr "APP_SERVER_IP" <----- Real IP of Internal Application server. set nat-ippool "190.190.190.190" <----- The IP source address is NATed to. next end
Reference to the real Application server IP (192.168.168.168 in this example) in the destination of the Firewall policy, not the VIP object.
From CLI:
config firewall policy edit 1 set name "AA" set srcintf "INCOMING-INTF" set dstintf "OUTGOING-INTF" set action accept set srcaddr "all" set dstaddr "APP_SERVER_IP" << Real IP of Internal Application server. set schedule "always" set service "ALL" set logtraffic all next end
Verification and troubleshooting:
The test PC (10.10.10.10) can ping the masqueraded IP of the Internal Application server (200.200.200.200).
The output of 'debug flow' and 'session information' on TCP port 443, shows that DNAT and SNAT were performed on the packet and routed appropriately.
Command for collecting debug flow:
diag debug reset
Session table information shows both original and reply direction is DNAT and SNAT:
diagnose sys session filter clear
Troubleshooting: Collecting the right log, the right way and being able to interpret it precisely is very important in troubleshooting issues, so this article will show how to collect and interpret some needed logs for this deployment. Collect the following when facing issues with this type of solution.
The log of the debug flow and cmds to fetch it are already provided above.
Here is how to interpret the log output:
msg="vd-root:0 received a packet(proto=6, 10.10.10.10:60452->200.200.200.200:443) tun_id=0.0.0.0 from INCOMING-INTF. flag [S] <----- This means the packet from 10.10.10.10 (user) to the server was received on FortiGate from interface 'INCOMING-INTF', and it's a SYN packet.
msg="find DNAT: IP-192.168.168.168, port-0(fixed port)" <----- This means 'DNAT policy configuration' was found with 'port forwarding' disabled.
msg="VIP-192.168.168.168:443, outdev-unknown" <----- This means DNAT (VIP) was configured with interface 'any'.
msg="DNAT 200.200.200.200:443->192.168.168.168:443" <----- This means External IP was DNATed to Internal IP successfully.
msg="find a route: flag=00000000 gw-6.1.1.1 via OUTGOING-INTF" <----- This means FortiGate was able to perform routing on the destination IP (192.168.168.168 in this case).
Note: FortiOS will first perform DNAT, whenever applicable, before doing routing lookup, after routing lookup, a Firewall policy check follows.
msg="in-[INCOMING-INTF], out-[OUTGOING-INTF] <- This shows incoming and outgoing interface from user to App. server, as FortiGate sees it.
If it is contrary to the setup, it is likely that an issue has been issued or a wrong routing configuration. Use 'get router info routing-table details <real destination IP>' to investigate what is wrong.
msg="Allowed by Policy-1: SNAT" <----- This means the source IP will be NATed as well. It also shows the firewall policy that permits (allowed) the traffic.
msg="SNAT 10.10.10.10->190.190.190.190:60452" << this showed the IP address the source (10.10.10.10 in this case) was NATed to.
To sniff the packet in the original direction (traffic from 10.10.10.10 -> 200.200.200.200 in this example), use 'diagnose sniffer packet any "host 10.10.10.10 and port 443" 4 0 l' <----- Use real source IP and service port.
The below output will be shown: NOTE the INCOMING-INTF in and out.
To sniff packet in reply direction (return traffic from Application server, 192.168.168.168 in this example). 'diagnose sniffer packet any "host 192.168.168.168 and port 443" 4 0 l' <----- Use real destination IP and service port.
The below output will be shown: NOTE the OUTGOING-INTF in and out.
Symptoms and possible causes:
If the RST flag is sourced from the Application server, it means the server is not listening on the 'dport xxx'.
If the RST flag is sourced from FortiGate’s IP, it means FortiGate is likely proxy-ing ARP for the IP. In that case, disable ARP reply on VIP objects and IP-pools (if used), with the below command:
config firewall ippool
This could be caused by: wrong DNAT and virtual IP configuration (e.g. using the wrong IP address, port mapping error). In addition, FortiGate may be proxy-ing ARP for that IP, disabling ARP reply as stated above.
|
