Virtual IP's with Policy Routes

Hi Ryan

When you have a policy route configured on the device, if you would like to access the VIP address on public IP address from internal network, then you need to create another policy route as below

Source interface : internal interface

Source Address: internet subnet

Destination interface: internal interface (on which interface the mapped IP address is present)

Destination Address: internal mapped IP address

And place this policy route on top of all other policies

Let me know if this helps

Somu

FTNT-Dubai

Thanks, for your reply. I have Configured a policy route that should match traffic destined to the interface of the VIP and moved it to the top. I'm still having troubles getting traffic through even with a policy allowing all traffic between the two interfaces. In the debug output it appears to be matching policy 0 and not the policy i have defined.

id=20085 trace_id=648 func=print_pkt_detail line=4368 msg="vd-root received a packet(proto=1, xx.xx.10.2:1->xx.xx.200.41:8) from port13. code=8, type=0, id=1, seq=18585."
id=20085 trace_id=648 func=init_ip_session_common line=4517 msg="allocate a new session-61e7a9aa"
id=20085 trace_id=648 func=fw_pre_route_handler line=174 msg="VIP-xx.16.50.50:1, outdev-port13"
id=20085 trace_id=648 func=__ip_session_run_tuple line=2532 msg="DNAT xx.xx.200.41:8->xx.16.50.50:1"
id=20085 trace_id=648 func=vf_ip4_route_input line=1586 msg="Match policy routing: to xx.16.1.1 via ifindex-9"
id=20085 trace_id=648 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-xx.16.1.1 via port16"
id=20085 trace_id=648 func=fw_forward_handler line=554 msg="Denied by forward policy check (policy 0)"

After explicitly defining the VIP in the firewall policy instead of any address the policy was matched and I'm now able to communicate between the two LANS. 

Thanks for your help.

Ryan

There are multiple posts in this forum related to VIP policy [...]  Please refer to the below correspondence to see if it pertains to your situation.  Thank you.   ==========   Fw: FortiGate Security "Loophole" and Severe Bug   Two issues were discovered during FortiGate firewall product tests, the first a documentation issue which FortiNet has confirmed affects FortiOS 5.0.x and 5.2.x and the second a bug which affects any FortiGate "D" series in combination with FortiOS 5.0.10 (the FIPS 140 version; it is unknown whether other combinations of FortiOS and FortiGate are affected.)   1)  FortiGate Deny All rules do not deny all traffic.  What is documented:  "VIP rules" take precedence over "regular rules."  However, until two days ago (6/15/2015) after it was recently brought to their attention this was mentioned only briefly in a technical note and not in any of their standard documentation (the FortiOS handbook, admin guide, etc.)  It remains inexplicit that "VIP rules" also take precedence over "Deny All" rules.   - Here's the link to the technical note (taken from the support case):  http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33338   - Here's the link to the updated handbook, published 6/15/2015 (see page 956, "Exception to policy order (VIPs):")  http://docs.fortinet.com/d/fortigate-fortios-handbook-the-complete-guide    The scenario documented in the stem support case is given below.  Rules appear in the same order they would after issuing the commands "config firewall policy" and "get."   =====   config firewall policy edit 1 set srcintf "wan1" set srcaddr "outside_blacklist" set dstintf "dmz" set dstaddr "all" set action deny set schedule "always" set service "ALL" set logtraffic all next edit 2 set srcintf "wan1" set srcaddr "all" set dstintf "dmz" set dstaddr "nat_inside" set action accept set schedule "always" set service "ALL" set logtraffic all next end   =====   In the above example, "outside_blacklist" is a group of outside addresses and "nat_inside" is a VIP on the firewall.  As depicted, traffic will not follow the usual order of precedence.  Any traffic destined for "nat_inside" will ignore the Deny All in Rule 1 but match the Accept in Rule 2.  Below is the fix suggested by a FortiNet support engineer.   =====   config firewall policy edit 1 set srcintf "wan1" set srcaddr "outside_blacklist" set dstintf "dmz" set dstaddr "nat_inside" set action deny set schedule "always" set service "ALL" set logtraffic all next edit 2 set srcintf "wan1" set srcaddr "all" set dstintf "dmz" set dstaddr "nat_inside" set action accept set schedule "always" set service "ALL" set logtraffic all next end   =====   Shown above, the change replaces the Deny All in Rule 1 with Deny "nat_inside."  This in effect restores the order of precedence.  (For an explanation, see the new section "Exception to policy order (VIPs)" in the handbook.  For the alternative fix, "match-vip," see the technical note.)  To summarize, FortiGate "VIP rules" are matched before "regular rules."  Most significantly, "VIP rules" are matched before "Deny All" rules.   The potential for a security "loophole" as described in the above case is compounded by:   a) a reasonable (until two days ago) expectation that a Deny or Deny All policy always denies blacklisted traffic in order of precedence; and   b) typical industry practice that only denied traffic gets logged.   Given these factors, a configuration error which would allow blacklisted traffic to enter a network undetected via an Accept rule is not unlikely.  [...]   2)  The secondary unit in a FortiGate "D" series active/passive cluster bricks (i.e., fails closed and must be re-imaged) after the first couple FIPS self-tests under certain conditions, two of them being:  when it can't contact the master; when it is given the master's configuration file.  Anyone with "D" series units will not be able to maintain an active/passive cluster in FIPS-CC mode.  An "emergency" code fix of FortiOS 5.0.10 is underway which will be released as 5.0.13.  We have been assured by FortiNet this will not affect the FIPS 140 certification of FortiOS.