Bug #13585
closed
Multiple VPN Gateways will not completely start a boot.
Added by Keith Townsend about 2 years ago.
Updated about 2 years ago.
Category:
Gateway Monitoring
Description
This issue was discussed at forum thread [[https://forum.netgate.com/topic/175376/strange-gateway-issues-with-2-7-0-development-builds]].
Running a system two policy routed OpenVPN client gateways. It appears that upon boot a bad state is establish resulting in the second VPN connection being established but the second gateway never coming online. This gateway remains Offline and does not recover automatically. If the gateway service is restarted (dpinger) The second gateway does appear to come online but with high latency recorded across both VPN interfaces causing gateway group failovers. The only way for both gateways to work properly is to kill the single state that is established to the second gateways monitor IP. This allows the gateway to recover properly and latency levels and functions returns to normal. It appears that at boot a bad state is being created prior to the VPN being fully established. This issue is not present on any builds prior to 2.7.0
Files
Discovered a workaround for this issue. Enabling the "Do not add Static Routes" in the Gateway monitoring options in System/Advanced/Miscellaneous allows both gateways to come up properly.
after rebooting, I see a latency in both GW VPN and then after while the GW status will be normal (online)
2.7.0.a.20221028.0600
Yes, The delay during initialization would be expected. But the second gateway not coming up at all unless the "Do not add static Route" option is selected? That leads me to believe that packets may be leaving the wrong interface at some point during boot.
It would be helpful to have the output of pfctl -vvss
, pfctl -vvsr
, and netstat -rn4
while the bad state exists.
Outputs of Commands pfctl -vvss, pfctl -vvsr, and netstat -rn4 as requested
- Status changed from New to Closed
Thanks! I posted a response on the forum. I'm not able to reproduce this and I don't believe there's an issue with pfSense itself here. I'll close this out for now and keep the discussion on the forum at least until more details are available that indicate an actual bug rather than a configuration issue.
Also available in: Atom
PDF