Converstion of backup file from 2220 to 4100
-
@stephenw10 So I want this checked on?
Skip rules when gateway is down
Do not create rules when gateway is down By default, when a rule has a gateway specified and this gateway is down, the rule is created omitting the gateway. This option overrides that behavior by omitting the entire rule instead. -
Yes. Otherwise it creates the rule but without any gateway set which passes it out the WAN.
-
@stephenw10 Got an email from Kris saying that I deserve Professional level support, sorry I wasn't getting it, and instructions to let them come in and review my 4100. I think your fix will keep my raw ip from leaking out, but I would like to know why I was seeing that flicker which hasn't happened in a while now
Thank you very much for your assistance
-
No worries let me know how it goes.
The only way you could have been seeing that is if the firewall was opening connections to the WAN directly. And the only way that could happen, with the rules you have, is if the failover gateway group ended up with no on-line gateways.
You could have hit that in in 2220 but just never did. That could be for a number of reasons but probably the gateway monitoring changes that have gone in since then have made it more likely.That gateway setting change should prevent it happening again but if for some reason it does not there are a few other things we an add to stop it.
Steve
-
@stephenw10 In my reply I, of course, gave you credit for the find.
I don't understand the dithering between addrs... If the connection thru both VPNs were up continuously, why would it flip between them? Is there some condition where the interface is up, but the 4100 thinks there is something wrong?
-
This post is deleted! -
If the gateway monitoring stops seeing reply pings it will show as down even if the tunnel is up.
You can tune how it detects that and what it monitors in the gateway settings:
https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html#advanced-gateway-settingsThe WAN which is considered the 'primary' is set by assigning the tiers in the gateway group. The lowest tier gateway is preferred:
https://docs.netgate.com/pfsense/en/latest/routing/gateway-groups.html#tier-priority-exampleSteve
-
@stephenw10 Ah! So the pings on the primary exceeded the threshold, it flipped over to the secondary, then when the pings worked again on the prim it switches back. Right? The "evil" scenario was the pings stopped on prim, then also stopped on secondary, so went out raw and that was when my real IP showed. Am I catching on?
-
Yes, exactly. dpinger, the gateway monitor, would have to mark both VPN gateways as down. If that happened the gateway group would have no valid gateways and the rule would be created without a gateway set allowing traffic to leave the WAN directly.
Given that both VPNs share the same WAN link it's not that unlikely that congestion on the WAN would cause both to show as down.Steve
-
@stephenw10 I think its good now. I've only seen one flicker in about a day and a half and it was this:
Started Fri Aug 26 07:58:56 PM EDT 2022 IP=194.36.111.30 Sat Aug 27 06:34:37 AM EDT 2022 194.36.111.30 -> Sat Aug 27 06:34:37 AM EDT 2022 -> 194.36.111.30]The printout is "From_IP -> To_IP" so for about a second I had no IP, which I would assume means nothing went out or in.
Again, thank you for your help
Larry -
Yes, it could have failed to return an IP if both VPN gateways went down. Which is correct.
