FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
rmetzger
Staff
Staff
Article Id 195331
Purpose
This document describes why and how to use Policy Based Routing with a Static VIP (Virtual IP) in a dual Wan scenario.

Scope
  • FortiGate or VDOM running in NAT mode.
  • Configuration and verification steps for FortiOS 4.0

Diagram
rmetzger_FD31240_diagram_3.jpg

Expectations, Requirements
From the above diagram, the expectations and requirements are :

1- The SMTP server is known and accessible from the Internet with its "public" IP address associated to the VIP : 172.31.224.58 (MX record in DNS servers), via wan2/ISP2

2- The SMTP server, when initiating traffic towards the Internet , must use the same the same source IP address 172.31.224.58.
This is the reason to use a Policy Based Routing, which will push the traffic on wan2 in order to benefit from the VIP translational in the other direction.

3 - All other traffic, from either the DMZ or the LAN must be routed via wan1/ISP1 normal routing process.

4 - In case of wan1 failure, routing failover for all other traffic is ensured over wan2.
Failover of SMTP services and VIP is not in the scope of this article. This can be achieved with a second MX record and/or with dynamic routing protocols. For this last option, please see also the related article : "Static NAT VIP accessible from 2 external interfaces with E-BGP peerings"


Note that this could apply to other services than SMTP, like HTTP or HTTPS for example.




Configuration
Details :

  • The secondary default route via wan2 has got a higher priority value (less preferred) is used to : 1) allow packet ingressing wan2 from the internet  2) be used as backup default route in case of wan1 failure.
  • In this scenario, only one Policy Based Route is used to force traffic with destination port 25  to egress on wan2. This is to benefit from the bi-direction address translation created with the VIP.
  • Firewall Policy 7 has a deny action to prevent SMTP traffic to be sent via wan1 ; this will avoid that SMTP traffic be source with another IP address than the one published by the MX record (SMTP failover is not covered in this article).
Note :
  • Despite the Policy Based rule, a Firewall Policy is still necessary (policy id 6) from input-device to output-device as defined in this rule.
  • Bi-directional VIP translation requires to NOT use port forwarding in the VIP definition.
 
The CLI configuration given below describes only the parts relevant to this article.


config firewall vip

    edit "VIP_SMTP"
        set extip 172.31.224.58
        set extintf "wan2"
        set mappedip 10.160.0.10
    next
end

config firewall policy
    edit 1
        set srcintf "internal"
        set dstintf "wan1"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
        set nat enable
    next
    edit 3
        set srcintf "wan2"
        set dstintf "dmz1"
            set srcaddr "all"
            set dstaddr "VIP_SMTP"
        set action accept
        set schedule "always"
            set service "ANY"
    next
    edit 4
        set srcintf "internal"
        set dstintf "wan2"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
        set nat enable
    next
    edit 7
        set srcintf "dmz1"
        set dstintf "wan1"
            set srcaddr "all"
            set dstaddr "all"
        set schedule "always"
            set service "SMTP"
    next
    edit 5
        set srcintf "dmz1"
        set dstintf "wan1"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
        set nat enable
    next
    edit 6
        set srcintf "dmz1"
        set dstintf "wan2"
            set srcaddr "all"
            set dstaddr "all"
        set action accept
        set schedule "always"
            set service "ANY"
        set nat enable
    next
end

config router static
    edit 1
        set device "wan1"
        set gateway 192.168.183.254
    next
    edit 2
        set device "wan2"
        set gateway 172.31.225.254
        set priority 10
    next
end


config router policy
    edit 1
        set input-device "dmz1"
        set protocol 6
        set start-port 25
        set end-port 25
        set output-device "wan2"
    next
end






Verification

                  Verification condition when wan1 and wan2 are up


1- FortiGate routing table

The routing table must include BOTH default routes, where the default route over wan2 is primarily used for accepting ingress traffic, and secondly to ensure failure in case of wan1 failure.


FGT # get router info routing-table all


S*      0.0.0.0/0 [10/0] via 172.31.225.254, wan2, [10/50]
                  [10/0] via 192.168.183.254, wan1
C       10.140.0.0/23 is directly connected, internal
C       10.160.0.0/23 is directly connected, dmz1
C       172.31.224.0/23 is directly connected, wan2
C       192.168.182.0/23 is directly connected, wan1




2a - SMTP traffic initiated from the server -  sniffer trace


FGT # diagnose sniffer packet any "host 10.160.0.10" 4

12.229670 dmz1 in 10.160.0.10.1407 -> 10.1.1.1.25: syn 3277362429
12.230192 wan2 out 172.31.224.58.1407 -> 10.1.1.1.25: syn 3277362429
15.202517 dmz1 in 10.160.0.10.1407 -> 10.1.1.1.25: syn 3277362429
15.202565 wan2 out 172.31.224.58.1407 -> 10.1.1.1.25: syn 3277362429
21.127111 dmz1 in 10.160.0.10.1407 -> 10.1.1.1.25: syn 3277362429
21.127170 wan2 out 172.31.224.58.1407 -> 10.1.1.1.25: syn 3277362429



2b - Other traffic initiated from the server -  sniffer trace


FGT # diagnose sniffer packet any "host 10.160.0.10 or port 80 or port 53" 4

6.100873 dmz1 in 10.160.0.10.1417 -> x.2.2.2.53: udp 41
6.100986 wan1 out 192.168.182.106.59661 -> x.2.2.2.53: udp 41
6.263140 wan1 in x.2.2.2.53 -> 192.168.182.106.59661: udp 100
6.263200 dmz1 out x.2.2.2.53 -> 10.160.0.10.1417: udp 100

96.824258 dmz1 in 10.160.0.10.1410 -> x.70.202.225.80: psh 8827644 ack 2365598618
96.824319 wan1 out 192.168.182.106.60166 -> x.70.202.225.80: psh 8827644 ack 2365598618



See from both traces above that traffic with destination TCP port 25 sourced from 'dmz1' is sent on wan2 while all other traffic is sent on wan1.

It is important to note that the SMTP traffic is source on wan2 NATed with the VIP address 172.31.224.58




                          FAILOVER TEST 1  :   WAN1 DOWN


3- FortiGate routing table


FGT # get router info routing-table all

S*      0.0.0.0/0 [10/0] via 172.31.225.254, wan2, [10/50]
C       10.140.0.0/23 is directly connected, internal
C       10.160.0.0/23 is directly connected, dmz1
C       172.31.224.0/23 is directly connected, wan2



4- Traffic flow with sniffer trace

FGT # diagnose sniffer packet any "port 25 or port 80 or port 53 or icmp" 4

12.652540 dmz1 in 10.160.0.10.1422 -> 10.1.1.1.25: syn 3775067211
12.652705 wan2 out 172.31.224.58.1422 -> 10.1.1.1.25: syn 3775067211

36.183922 dmz1 in 10.160.0.10.1423 -> x.2.2.2.53: udp 41
36.184095 wan2 out 172.31.224.58.1423 -> x.2.2.2.53: udp 41

40.397406 dmz1 in 10.160.0.10.1425 -> x.70.202.225.80: syn 3025064714
40.397570 wan2 out 172.31.224.58.1425 -> x.70.202.225.80: syn 3025064714

43.029569 internal in 10.140.0.132 -> 10.1.1.1: icmp: echo request
43.029608 wan2 out 172.31.224.106 -> 10.1.1.1: icmp: echo request

 

See from above that ALL traffic is routed via wan2, and that :
  • the SMTP server traffic gets source NATed with 172.31.224.58
  • other sources are NATed with the wan1 IP address 172.31.224.106



                                FAILOVER TEST 2  :   WAN2 DOWN


Note that in this scenario, the traffic destined to the SMTP server and normally ingressing wan2 must be re-routed via wan1. This routing backup  consideration is not covered in this article.


5- FortiGate routing table

FGT # get router info routing-table all

S*      0.0.0.0/0 [10/0] via 192.168.183.254, wan1
C       10.140.0.0/23 is directly connected, internal
C       10.160.0.0/23 is directly connected, dmz1
C       192.168.182.0/23 is directly connected, wan1

 


6- Traffic flow with sniffer

FGT #  diagnose sniffer packet any "port 25 or port 80 or port 53" 4

2.835204 dmz1 in 10.160.0.10.1446 -> 10.1.1.1.25: syn 3777327276
8.166812 dmz1 in 10.160.0.10.1447 -> 10.1.1.1.25: syn 858679722

25.762376 dmz1 in 10.160.0.10.1436 -> x.2.2.2.53: udp 41
25.762535 wan1 out 192.168.182.106.36632 -> x2.2.2.53: udp 41

35.876978 dmz1 in 10.160.0.10.1459 -> x.39.139.170.80: syn 3828525805
35.877144 wan1 out 192.168.182.106.54583 -> x.39.139.170.80: syn 3828525805
36.088958 wan1 in x.39.139.170.80 -> 192.168.182.106.54583: syn 1378868659 ack 3828525806

 

See from above that ALL traffic is routed via wan1, except SMTP which is blocked by Firewall Policy 7



Related Articles

Technical Note: Static NAT VIP accessible from 2 external interfaces with E-BGP peerings (dual-homin...

Technical Note : Policy Based Routing example : HTTP/HTTPS redirection. Configuration and troublesho...

Technical Note : Policy Based Routing example to redirect HTTP traffic to a Proxy

Contributors