Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
dwear
New Contributor

Multiple ISP IP Pool within Zone

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?

2 Solutions
tanr
Valued Contributor II

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_... [/ul]

     

     

  • View solution in original post

    Boxheimer

    Hi, 

     

    In 5.6.2 it's possible to use associated-interface for an IPPool. I use it in combination with SD-WAN, since then the NAT was always correctly. Before it could happen that the Source-IP was natted to an IP of ISP_1 instead of ISP_2 on WAN-Link of the ISP_2.

    This very useful feature is not documented.

     

    Marcus

    [NSE4-8]

    View solution in original post

    9 REPLIES 9
    emnoc
    Esteemed Contributor III

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

     

     

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    tanr
    Valued Contributor II

    @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
    New Contributor

    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.
    dwear
    New Contributor

    With some help from a Fortinet SE, I figured out a solution to this problem. In 5.6, they introduced a CLI command "set associated-interface" under the "config firewall ippool". There you can assign an interface to an IP pool so the IP pool can only be used on that specific interface. 

    tanr
    Valued Contributor II

    Being able to set associated-interface for an ippool sounds very useful for those of us working with zones.

    I hope it gets ported back to the 5.4.x branch.

    Otherwise, your VIP solution seems to be one of the only ways to make this work for 5.4.x, 

     

    A cleaner solution, IMO, would be (as emnoc mentioned) if the FortiGates allowed firewall security polices that use a specific interface even when that interface is part of a zone.  I've done that on other platforms and really miss it with Fortinet.  If you want this sort of feature, make sure to make a feature request with Fortinet!

     

    emnoc
    Esteemed Contributor III

    Does anybody ever seen away to set fwpolices that uses  "specific interfaces" when the interface is also part of a zone? Juniper SRX allows for this type of fwpolicy.

     

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    tanr
    Valued Contributor II

    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_... [/ul]

     

     

  • emnoc
    Esteemed Contributor III

    No,  I think you did a  5tars good ;)

     

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    Boxheimer

    Hi, 

     

    In 5.6.2 it's possible to use associated-interface for an IPPool. I use it in combination with SD-WAN, since then the NAT was always correctly. Before it could happen that the Source-IP was natted to an IP of ISP_1 instead of ISP_2 on WAN-Link of the ISP_2.

    This very useful feature is not documented.

     

    Marcus

    [NSE4-8]

    Labels
    Top Kudoed Authors