Failover GW for non-WAN interface
-
@viragomann Thanks for your response. If that's okay, I'd like to dig a bit further. Regarding your comments below,
If not, set another IP within the customer network, which does, as monitoring IP. You need a different one for each.
Can the same IP address be used? Because I believe customer network also uses a sort of fail-over on their end with a single IP address (like advertising a virtual IP address).
Set GW1 as tier 1 and GW2 as tier 2 and the Trigger Level to "Member down".
In this context, member means GW1 and GW2? Say, GW1 is fine but customer target host is down and they switch over to their fail-over. Will fail-over attempt via GW2 happen on our pfSense as well?
Thanks again.
Eoin
-
@eoin said in Failover GW for non-WAN interface:
Can the same IP address be used?
No each gateway need a different monitoring IP.
pfSense add a route for this IP to direct the pings to the concerned gateway. But you cannot have to routes for a single IP.Does the gateways themself not respond to pings?
As said, if you use another IP it must reside behind the gateway.
If there is only one device you have access to, you can also assign two IPs to it and use each for a gateway monitoring.@eoin said in Failover GW for non-WAN interface:
In this context, member means GW1 and GW2?
Yes.
Say, GW1 is fine but customer target host is down and they switch over to their fail-over. Will fail-over attempt via GW2 happen on our pfSense as well?
Not clear, what kind of failover at customer site this could be. If they have an active - passive failover configuration, you would also from your site only be able to access the active one anyway.
-
@viragomann Apologies, my explanation might not have been clear enough. I've posted another diagram below.
pfSense and two gateways are in the same subnet (192.168.5.0/24). Yes, I can make both gateways respond ping, no problem. Below is a sort of situation that I'm interested in.
Normally, network itself is very stable, robust. From time to time, customers give a notice in advance saying - "Hey, direct WAN (primary connection) will have maintenance, you should route your traffic via GW2 (IPsec)". The customer endpoint IP address doesn't change. I don't know what mechanism they use but it doesn't change anyway.
Instead of manually changing the route setup on pfSense, I'd like to make a sort of automatic fail-over and fail-back. Say, if 100.100.100.3 is not reachable via GW1 (192.168.5.102), switch route via GW2 (.103). When the primary connection maintenance is completed, then switch back via GW1. That's why I was asking about single IP address monitoring, which is 100.100.100.3 in the diagram.
Hope I explained okay this time. Thank you.
Eoin
-
@eoin
No, it cannot work with a single IP due to the mentioned reason. Possibly pfSense could failover and back again if the gateways are in an active-passive setup, but if they are active-active, pfSense would never fall back to the primary route.
pfSense has to be able to determine each routes health independently for proper failover and fail-back. -
@viragomann Hmm... okay. I might need to find other ways to do it. Thanks for your help.
-
@stephenw10 Apologies to put you in this old conversation but I can't set the gateway group as a gateway in static route. Is there a way to setup what I want to achieve in pfSense? Hope you can help. Cheers.
Eoin
-
@eoin said in Failover GW for non-WAN interface:
I can't set the gateway group as a gateway in static route. Is there a way to setup what I want to achieve in pfSense?
Seems, this is not doable. I was thinking, I did this in the past though, but not sure.
However, you can use a gateway group as default gateway and in policy routing rules. So try to do this with policy routing, as you mentioned before already.
-
@viragomann Thanks for your suggestion. The catch is that gateway group shouldn't be the default gateway. There's already a separate default gateway for all other connections, which is not shown in the diagram I posted.
-
@eoin said in Failover GW for non-WAN interface:
@viragomann Thanks for your suggestion. The catch is that gateway group shouldn't be the default gateway. There's already a separate default gateway for all other connections, which is not shown in the diagram I posted.
It looks like I included that part briefly in my original diagram.
-
@eoin
Yes, this is why I suggested to do it with policy routing.