Hello
I have a Fortigate 200E FortiOS v6.0.4 build0231 (GA)
I have two ISP with SD-WAN and each ISP has an ip pool
But if the intranet has an IP that wants to go out with a specific IP of the IP pool
When I configure IPv4 Policy like this and use "use dynamic ip pool", the IP can't access the Internet.
Hi Vincent,
You have to assign the IP Pool to the interface with these CLI commands:
config firewall ippool
edit "IPPool name"
set associated-interface wan1
next
end
But, you have to force the trafic to the right interface in SD-WAN rules. In the current version, we can't assign IPPool on one interface and use outgoing IP address on the other. Feature Request have been asked for this.
If you want to use SD-WAN with IPPool, you have assign IP Pool on both wan interfaces, and don't forget to associate IPPool with the right one! :)
Issue you currently have is weird: Fortigate tries to NAT on interface WAN2 with the IP Pool of the WAN1!
Let me know if it fixes your issue!
Philippe Gagné, NSE7
Androide
I have similar problem to you. Each office room of my company use different Public IP. When our main ISP is at fault, only the interface IP can switchover, I have to manually change to use backup ISP.
As I know, you have to use Interface IP as NAT source. Fortinet hasn't resolve this problem. It's boring.
fred.q wrote:As far as your issue goes, could you not just create separate IP pools for each room/outgoing policy? If WAN2 is being used (failover?), then the new distinct IP pools on that interface would kick in, no? As long as your ISP is pointing the return traffic to those IP pool addresses, this should work. Remember, the IP pool needs to be addresses routable outside of the Fortigate.I have similar problem to you. Each office room of my company use different Public IP. When our main ISP is at fault, only the interface IP can switchover, I have to manually change to use backup ISP.
As I know, you have to use Interface IP as NAT source. Fortinet hasn't resolve this problem. It's boring.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
Vincent.Lai wrote:I cannot see your whole configuration, but if your IP pool has publicly routable IP addresses, then it should work for you as well, AS LONG AS your ISP is pointing those IP addresses back towards your Fortigate.Hello
I have a Fortigate 200E FortiOS v6.0.4 build0231 (GA)
I have two ISP with SD-WAN and each ISP has an ip pool
But if the intranet has an IP that wants to go out with a specific IP of the IP pool
When I configure IPv4 Policy like this and use "use dynamic ip pool", the IP can't access the Internet.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
Hello,
I have exactly the same question , but with the option "one-to-one" of the IPPool.
I have to use this option to be compliant with my SIP provider ( need to have no PNAT ), and I can't configure "set associated-interface" on the IP Pool when "set type one-to-one" is set....
Do we have a solution to use 2 public IP , for one internal server , on 2 ISP , with the option one-to-one ?
Thanks !
BR
Stéphane
[Answering in this thread because I don't see it reposted as a separate question.]
@srevol set up a VIP. You don't need an IP pool for this: Return pathing/interface association is handled at the external interface and VIP level. Depending on your OS release, you may need to adjust the CLI-only options on the VIP entry. The activation is via a policy targeting the VIP. For your SIP provider, if you include their source IPs as part of the filter set, you may experience some issues with outbound traffic pinning to the first VIP match where return traffic is precluded from the same issue. If you steer traffic out, watch for corollary sessions potentially coming from the alternate interface. May also help to setup checks for availability. Frankly, this is more naturally handled without SD-WAN because SD-WAN can limit interface associations, excluding selection of component members (6.0.3-6.0.5).
I'm running 7.0.5 and I don't have an option for "set associated-interface" on an IP pool.
I have two ISPs. They are for failover only. For a few scenarios, I need outbound traffic to be tied to a specific IP for each ISP. I created two IP Pools - one for each ISP and created Firewall Policies that use them but when the router fails over to the secondary connection, it continues to try to send traffic out using the highest-priority Firewall rule. I assume associating an IP Pool with an interface would fix this because the Fortigate would ignore rules applied to a down interface? So my secondary rule for my failover ISP would work correctly?
If there is a feature request to fix this, please link it so I can follow it. If there's a current workaround, let me know. I think I could ditch SD-WAN and use health monitors to manage my setup but SD-WAN has some nicer line monitoring features so I'd prefer to keep it.
Hey Scott,
I have a FortiGate 7.0.5, and I can set associated interfaces in IP pools, though only via CLI:
-> port1 is also a member of an SD-WAN zone (not operational - just to verify that this works)
-> I created the SD-WAN zone first, THEN created IP pool via CLI
Thanks for taking the time to test this out!
So I dug a little deeper and turns out my IP Pool was for a One-To-One NAT. I changed it to Overload and I was then able to associate an interface. I also verified the behavior by unplugging WAN1 and sure enough, my IP Pool traffic was going out on WAN2's specified IP from the IP Pool.
Since my firewall rule only includes one IP address, overload should effectively work the same as 1:1 NAT, it's just semantics i guess...
Is there a reason to not allow interface association for 1:1 nat?
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1735 | |
1107 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.