Converstion of backup file from 2220 to 4100
-
It's very unlikely to be a hardware issue. Anything in hardware wouldn't present like this.
It's much more likely to be a different pfSense version where the config behaves slightly differently. For your porposes the SG-2220 and the 4100 are very similar. I would expect a config conversion to be very simple there. In fact I wouldn't expect a conversion to be necessary really. You should be able to import the old config and it will ask you to reassign WAN and LAN and then boot into it.
Do you have the ticket number this was done on so I can review the config?
Steve
-
@stephenw10 I don't see a ticket number mentioned in any of the emails that have gone back and forth. I can tell you that Georgiy was the one that converted and sent the file. Another name in the emails from Netgear TAC was Lev Prokofev who did seem to be working with me, but then another got involved and the conversation turned... one of the last comments was that this wasn't supported in Lite and I'd have to buy a better support package. That would be fine if I thought I'd done something to mess it up, but its clearly not working the way it should.
The 4100 was bought with Order SO22-44374 if that helps
thanks, Larry
-
Ok, let me look for it....
Edit: Found it. For reference your ticket ID was: 1036190288
Checking it now...
-
@stephenw10 There were two tickets open when they initially were trying to help me get the 2220 working 1029506379 and 1036190288. I think the 2nd one may have been for hte conversion
-
@stephenw10 FYI - Just sent a new email to support with an explanation of what's happened from the beginning. It got ticket 1078056888
-
Yes, OK the issue here is that old config from the 2220 was from a much older version. 2.4.3p1 from 2018.
There's no real problem with importing a config that old but since then the WAN failover handling has changed significantly.
Looking through your config there is one key setting you don't appear to have.
In Sys > Adv > Misc set 'Skip rules when gateway is down'.
Without that is both OpenVPN gateways show as down then your policy routing rule on LAN will be created without a gateway set and traffic will just leave via the default route, the WAN.
Steve
-
@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.
