IP block forwarding from ISP

[VicAndr]

I know that am not the first asking a similar question, but I' ve gone through the posts and still don' t fully get it. So here is our situation. On our primary WAN interface (we have dual-ISP connections) we have a " standard" /26 public IP block with the FG' s and ISP' s upstream router' s IP addresses being the part of this block. We are contemplating idea now to switch primary WAN connection to a different ISP. The " new" ISP provides public IP addresses differently. Instead of assigning one single IP block to a client they provide main IP block (/30) strictly for client' s and IPS' s routers communication and then forward the second IP block containing the bulk of IP addresses to the client' s firewall/router. What would be the right way of configuring a FG to handle this second IP block? Would it be sufficient to configure just VIPs on that WAN interface or we have to explicitly assign the second IP block to it as well? Some expert members (ede-pfau here, emnoc there, ...) do not recommend setting secondary IPs on a FG' s interface. In what circumstances we have to use secondary IP addresses then? Also if I need to ensure that some outbound traffic flows through/from specific IP addresses - I use IP pools for that purpose, right? Do I require to assign a secondary IP block in this case or could " get away" without it? Thank you,

[ede_pfau]

ha, nice to see me quoted on here...my post still holds for your situation:

Agree - you should create VIPs (and VIPgroups if you like) to make the additional IP addresses active. As long as there' s a route to the FGT for these you should not have any problem.

So if you create one or more VIPs on the wan interface the FGT will act as a proxy arp for them, i.e. answer any request to these addresses and in fact make these addresses usable. But don' t forget to actually use the VIP or VIP group in a policy to make them active.

Setting up secondary addresses invalidates the FGT' s anti-spoof check which is a drawback security-wise. So I' d always go for VIPs.

That is a bit naive I think (now). It' s totally true if the secondary address is within the range of the primary address. Then you would have to disable the antispoof feature. But in your case I assume that the second address block is non-overlapping, and then you would not have to do that. Anyways, go with the VIP setup. Better visibility and easy to handle, especially for a greater number of addresses. Use a VIP group to economize on policies.

[VicAndr]

Thank you for almost immediate response, ede. So if we could " get away" with just VIPs alone, why someone would need secondary IPs anyway? Also servers with WAN visibity over VIPs do not stick to the same IP address in case outgoing traffic initiated by those servers themselves. To accomplish that we would use IP pools in firewall policies for outbound traffic' s NAT-ting in our scenario, right? Again, is it necessary to assign secondary IP block to be able to configure appropriate IP pools or not?

[ede_pfau]

With secondary IPs you don' t have the option to forward and/or translate ports. And, with additional public IPs from the same subnet as the primary address you almost always would prefer VIPs over secondary addresses because of the address overlap. As long as you don' t use IP pools together with VIPs the VIP will sourceNAT the server' s address for server initiated traffic as well. So to speak, ' intelligent NAT' . There' s been a recent thread on exactly this topic, you might read up on it here: https://forum.fortinet.com/FindPost/112623 And no, you can use IP pools with addresses from your imagination, without any ' real' assignment first. IP pools just exchange the source address of traffic passing, and you can change it to whatever you like. Of course, traffic will only come back if the routing is correct, so NATting to 192.168.1.1 will work but will not be routed back to you.

[VicAndr]

The topic you' ve referred me to is a real eye-opener for me. I' ve been using IP pools to specify outbound IP addresses for some servers for years. But it appears that Source NAT was available as an option for a VIP configuration (through CLI only) starting from at least FortiOS 3.0.X! Thank you, ede.