Skip to main content
dwear
dwear
New Member
October 18, 2017
Solved

Multiple ISP IP Pool within Zone

  • October 18, 2017
  • 1 reply
  • 15473 views

I migrated a user over from a Sonicwall, and for sake of uniformity with other fortigates and policy management, I created Zones for the WAN interfaces. They have 3 ISP connections. There are 2 SMTP relay servers that go outbound (outbound only) using IP Pools. I need to NAT them to an appropriate IP per ISP. When I create the policy, I can choose multiple IP pools, but it appears to use them top down with no association to the appropriate ISP/interface. For instance if ISP-A was on 1.1.1.1 and ISP-B was on 2.2.2.1, it will always use the 1.1.1.1 IP because its the first IP Pool. 

 

What I really need is to associate an IP Pool to an interface, the same way you would a VIP. This way IP Pool 1.1.1.2 will only ever be used on the ISP-A interface, and same for the other IP Pools. Anyone know if this is possible, or a way of solving this problem?

    Best answer by tanr

    If you're creating inbound rules with a deny that reference VIP IP's, make sure you set match-vip to enable for that rule, otherwise it might not properly match.

     

    It's been a little while since I set up my own dual ISP failover, and I don't have quite your situation, but here are some of the key points.

     

    [ol]
  • If you have multiple static routes with the same distance but different priorities they will all stay in the routing table.  Without a policy route to redirect to the lower priority routes, only the highest priority matching route will get used.  These routes need to be here for the policy routes to redirect to them.
  • Create link monitors for all your wan ports so that if one goes down the static routes referencing it will get removed from the routing table.
  • Create multiple policy routes to route your smtp servers out the appropriate interfaces.  Note that unlike static routes, the policy routes are evaluated in order.  So you can set the one that normally routes a particular smtp server out the interface you would normally want it to use higher in the list.  However, if the interface that the policy route would normally route to goes down, the static route will have been removed from the routing table (by your link monitor) and thus that particular policy route won't fire.  In this case, the policy routes further down the list would be evaluated and the smtp server would then get routed out the next available interface by a matching policy route.[/ol]

    @emnoc, feel free to correct me here!  It's been a while.

     

    References:

    [ul]
  • http://kb.fortinet.com/kb/viewContent.do?externalId=FD32103 
  • http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-advanced-routing-54/Routing_Advanced_Static/Routing_Concepts.htm [/ul]

     

     

    • 1 reply

    emnoc
    emnoc
    New Member
    October 18, 2017

    Not sure what your doing but the main reason is because you have "zones" and the collective interfaces in the single zone.

     

     

    tanr
    tanr
    New Member
    October 18, 2017

    @dwear, we need more details to understand the question. Description of the interfaces, sources, routing, ip pools, etc. as well as details like should the SMTP relays be the only ones using those IPs , for which protocols, etc.

     

    My guess is, as I think emnoc was implying, that you have multiple physical interfaces as members of a single wan zone?  And your difficulty is that you can't force them to use a specific interface within that zone?  Or use the appropriate NAT IP from the IP Pool you refer to in the security policy? 

     

    One way (though probably not the best) to do this would be to use policy routes to route your SMTP relay servers out the appropriate physical ports.  You can policy route or static route to specific ports even if they're in a zone.  You would need your static routes to have multiple routes out the different ports with equal distance but different priorities for this to work with policy routes (see other forum discussions of how to work with multiple ISPs).  To get the specific IPs you can just create different IP Pools and specify whichever you wish in your security policies.  But I'm just guessing here, because we don't really know your issue without more details.

     

    dwear
    dwearAuthor
    New Member
    October 19, 2017
    Sorry if I wasn't clear, let me try again. I have 3 ISP connections setup in a single zone. They are currently in a zone, though I suspect using wan-llb would cause the same problem since it groups the interfaces. I want to explicitly define outgoing NATs for those SMTP servers so I have dedicated IPs whitelisted in O365. I have 1 IP per ISP whitelisted, and I don't care which SMTP server it comes from as long as they both have the ability to use any of the ISPs, but they don't have to share the IP. The problem I'm running into is that I cannot specify a which IP Pool is used per ISP. If I set all the IP Pools on the same policy, it uses them top down regardless of the ISP, which means it's using the primary ISPs IP for all the ISPs which doesn't work. What I did right now, which seems to work though it seems very backward, is I created a VIP for each IP Pool. That allows the FG to use the VIP address when it's leaving the interface, and since the VIP is associated with the interface, it knows which public IP to use. Since I have to reference the VIP for it to be applied, but I don't want to allow inbound traffic, I created a WAN to LAN policy, referenced those VIPs as destinations, and made it a DENY. The policy routing idea you mentioned seems interesting, but I'm not sure I completely understand. I could force each SMTP server out one ISP, but then I lose the redundant ISP for that SMTP server as it could only ever route out 1 ISP. If I set policy routes for each ISP, how would it ever hit anything besides the first route, assuming the interface doesn't go down but the ISP does? Does that make more sense? The only goal is really to give redundant ISPs to these SMTP servers and specify the NAT for each.
    Terms & ConditionsAccessibility statement