dpinger doesn't start at times on OpenVPN interfaces
I have an openvpn TLS UDP TAP subnet client connection in pfSense 2.3.b.20160305.0255. After successful connection the server pushes the following options:
PUSH: Received control message: 'PUSH_REPLY,route-gateway 172.22.1.1,ping 5,ping-restart 30,ifconfig 172.22.1.2 255.255.255.252'
but there is no gateway assigned to according gateway entry.
Actually, if I disable according gw entry the magic happens and gw ip is being set!
See attached pfsn2.3ovpn_gw_bug.mp4.
P.S: In "General Setup" I've specified WAN_AMS2_VPNV4 gateway for DNS Server 1: 188.8.131.52. That's why there a static route appears when gw ip is set.
Doesn't seem to be any reason rc.newwanip should skip things while the system is booting. Ticket #5952
#1 Updated by Chris Buechler over 3 years ago
- Subject changed from Incorrect gateway entry update to dpinger issue on OpenVPN interfaces
- Status changed from New to Confirmed
- Assignee set to Chris Buechler
ran into this on Friday, there is some kind of issue with dpinger on OpenVPN interfaces. I haven't had a chance to look far into it yet.
At least I believe that's the same root cause.
#2 Updated by Chris Buechler over 3 years ago
This isn't as easily replicable as I figured. I know it exists in some form, from OP's description, another forum report, and jporter's system did it Friday and Monday post-reboot. But I've been through a variety of circumstances, and am not seeing any problems. The only scenario I can find here that doesn't work post-boot is SLAAC-assigned interfaces ("DHCPv6" type minus a DHCPv6 server), as SLAAC on its own doesn't trigger rc.newwanipv6 (which is OK).
Renato: no need to pick up here, I'll need to replicate on jporter's system and find the root cause.
#5 Updated by Chris Buechler over 3 years ago
- Status changed from Confirmed to Feedback
This issue happens when OpenVPN instances aren't yet connected at the time setup_gateways_monitor runs during boot. Then when they connect, rc.newwanip skips a chunk of what it does including setup_gateways_monitor if the system is booting. There doesn't appear to be any reason it needs to skip all those things while booting. Commit message where it was added ~6 years ago just said something like "skip during boot" without any explanation as to why. We've moved that check down further in the file since then to fix similar types of issues. On several systems tested, removing the booting checks from rc.newwanip had no negative impact on anything. And that does fix this issue.
Pushed that change. Reviewing rc.newwanipv6 for whether same should be done there.
Dmitriy: the next snapshot past the time of this comment will have that change and should work for you. You're on a new enough snapshot that you can just gitsync to master if you'd like.
#6 Updated by Chris Buechler over 3 years ago
- Subject changed from dpinger issue on OpenVPN interfaces to dpinger doesn't start at times on OpenVPN interfaces
this looks to be working in all cases now, and the changes didn't result in any regressions that I can find. It also fixes a range of other potential problems on dynamic interfaces that may be a bit slow to come up during boot.
#11 Updated by Dmitriy K over 3 years ago
Jim Pingle wrote:
Does that tun actually get a gateway sent by the far side?
In lots of tun or topology subnet configs the server sends no gateway so pfSense has no way to tell what it is.
I mean the IP field itself isn't empty. If I recall correctly I always saw local endpoint IP as GW IP. Dynamic? never heard of.
I don't understand why pushed gw ip is not set properly? Maybe it's a ovpn-linkup script bug?