Recently attempted a migration from Fortigate v3.0 MR7 (I know, I know).. to PAN-OS. I got completely blindsided by my misunderstanding/oversight of how FortiOS is handling NAT. I have a CCNA-Security & CCNP-Security, so the concept of NAT isn't foreign to me, but I could use some help here..
1. the Fortigate has static 1:1 NAT's, appears to be destination NATs
"config firewall vip edit "HOSTA" set extip 1.1.1.1 set extintf "port1" set mappedip 2.2.2.2 "
2. the Fortigate has many FW policies that have "nat enabled" checked - but most of these policies do not reference a VIP in the SRC or DST field, nor do the objects referenced even have a VIP configured, e.g. HOSTB -- I'm interpreting this to mean a Dynamic Overload/masquerade/PAT (whatever you want to call it)
" edit 20 set srcintf "port2" set dstintf "port1" set srcaddr "HOSTB" set dstaddr "REMOTE-HOST1" set action accept set schedule "always" set service "HTTP" set logtraffic enable set nat enable "
3. there are FW policies that do reference VIP's in the config - and that makes sense to me
"edit 30 set srcintf "port1" set dstintf "port2" set srcaddr "REMOTE-HOST1" set dstaddr "HOSTA" set action accept set schedule always set service "ICMP" "HTTP" set logtraffic enable "
4. No IP Pools configured, no VIP groups, all that I see in VIP section in GUI are the static 1:1 NAT's listed in example #1
My question(s): 1. FortiOS dox say "Inbound NAT is bidirectional NAT" - would we call example #3 "bidirectional NAT"? where the SRC is translated, and the return traffic has the DST translated
2. FortiOS dox say "when the NAT check box is selected, then full NAT is enabled" , e.g. SRC and DST NAT (sounds like bidirectional). -- thus in example #2, outbound traffic from HOSTB is NAT'd to the interface IP of port1, and inbound traffic from REMOTE-HOST1 is NAT'd to the VIP of the object.. in my scenario however, as noted, HOSTB doesnt have a VIP
3. FortiOS dox say "when the NAT check box is NOT selected, then DST/NAT is performed" -- meaning that the DST IP in the original request is changed to the translated IP of the VIP destination, but w/out changing the SRC IP
Unfortunately the night of the migration, no amount of logs, or testing the nat-policies on the PAN would have shown that there was a problem, but a quick mod of the PAN cfg to enable the following worked:
HOST-NAT-Test { from INSIDE; source 2.2.2.2; to DMZ; to-interface ethernet1/2 ; destination [ 3.3.3.3 3.3.4.4 3.3.5.5 ]; service any/any/any; translate-to "src: ethernet1/2 5.5.5.5 (dynamic-ip-and-port) (pool idx: 1)"; terminal no; }
in this case, outbound traffic from 2.2.2.2 translated to the eth1/2 int IP of 5.5.5.5 --- which must mean in all these FW policies that have "NAT enabled" there must be a corresponding SRC NAT translation tied to the outbound interface IP
Sorry for the huge dump.. my brain hurts. Any help is much appreciated
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1714 | |
1093 | |
752 | |
447 | |
232 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.