HA Configuration.. still able to route traffic?

That depends. In a/p mode the slave is passive; both units share only ONE MAC address and ONE IP address so the slave cannot participate in handling traffic. In a/a mode you wouldn' t have asked. But there might be a workaround: if you create VDOMs for your a/p cluster, and another one on the slave unit...and on the primary as well for failover. Have a look at the HA Guide, keyword is " Virtual cluster" . What' s so special about that UDP traffic, or are you short on Fortigates?

Hi Ede, Thanks (again) for your response. I' m not sure we' ve had the best solution designed for us. We have two Fortigates in an A/P cluster.. I' m not sure its been designed correctly.. Would it be correct to say that in an A/P cluster that each of the Fortigates should have identical connections on its ports? As it stands each of our two 310B Fortigates has mostly the same connections, but crucially, each has a different Internet Connection (and are housed at physically separate sites).. and I will have devices in the field sending UDP packets to both of these connections (for redundancy).. The devices are sending a packet to two IP Address that they have access to by virtue of an IPSec tunnel they will establish to each of the Fortigates After a long read of the HA Guide.. I' m not entirely sure it can be made to work as designed.. I think they need to be broken out of the HA Cluster they' ve been built with I' m just the software guy.. trying to work out if the Network design is wrong :-) Cheers, Duncan

I agree this looks a little bit convoluted. Basically, there is only ONE configuration on a HA cluster (apart from the hostnames and some device specific HA settings). So if your cluster fails over the second WAN line configuration has to be (more or less) identical to your first one, dial-out parameters, IP addresses, gateway etc. And with each FGT failover you would switch WAN lines...who would do that without being forced to? Of course you' ll lose all sessions and spend a good time waiting for connectivity to be re-established. There must have been a lot of good reasons for this design, or maybe not enough time to think it over. You can have 1 VPN tunnel interface on WAN1 and have the cluster maintain it even when failing over. Of course, the slave unit needs to be connected to WAN1 as well. That' s device redundancy. What your setup is trying is to achieve WAN (ISP) redundancy as well with the same setup. IMHO you could set this up this way: - configure 2 default gateways to ISP1 and ISP2, resp., using different distances to prefer ISP1; will switch over automatically to ISP2 if ISP1 is determined to be dead (enable dead gateway detection/ping server on the WAN interfaces) - to get your devices to connect to the second WAN IP in case of failover you could set up a DDNS entry and terminate the VPN tunnel on that dynamic hostname instead of a fixed IP. I assume the (external) devices dial in, and the tunnel doesn' t need to be up for internal->external traffic. In your current design, your devices generate a lot of traffic that is never answered, i.e. try to build up the second tunnel endlessly, and send traffic down a non-connected tunnel etc. This is crude. One last good advice: if you' re from a different IT field then I' d strongly recommend to get professional help from a FGT partner onsite. Seems like you' re willing to make efforts to get the incoming data lines set up redundant so maybe your company could spend some more money at the right spot, namely on design, setup and testing. This isn' t exactly what you set up every day in 10 minutes.

Op, I think your going to run into problems in that design. A few quick question; >do you even need A/P HA? > Can' t you run both FGT as active with no HA and use the 2 WAN circuits that are independent and seperate by the twp physical locations? > can you explain the nature of the UDP packets that are being sent? ( Any application ack, any return traffic, is it one way only , etc ) Remember in HA ACTIVE/PASSIVE , only the active unit is processing packets and the standby only has the config and the active state updates for the connections.

Hi, Ede, Emnoc, thank you very much for taking the time to reply.. I can see now that we need to engage with someone who knows what they are doing.. and its clear to me that the original design is fundamentally flawed. Breaking the Fortigates out of the HA cluster and employing DDNS sounds like a very neat solution. I think this will work very nicely. I will encourage our company to seek out the skills required to do this properly. Thanks once again. Duncan.