Bug #5952
closed
dpinger doesn't start at times on OpenVPN interfaces
Added by Dmitriy K over 8 years ago.
Updated over 8 years ago.
Description
Hello.
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: 8.8.8.8. That's why there a static route appears when gw ip is set.
Files
- 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.
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.
Maybe there is a way to turn on nice debug logs in pfSense which I could provide to you?
Just updated 2nd router to latest snapshot and ran into the same issue. it's 100% reproducible on both routers.
- 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.
- 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.
Well, this happens not only during boot. You can create a ovpn client in any time and you'll get the same result without rebooting: No gw ip in gw entry till it is not disabled. Are you sure this issue is a dpinger related?
Tested on 2.3.b.20160311.1315 x64: Issue is not fixed, unfortunately;
I have yet another an ovpn TLS TCP TUN net30 client connection and everything works fine. So TAP doesn't work and TUN does work.
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.
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?
I turned this into something different from where it started having seen the same "pending" status on a couple other systems. Dmitriy's issue looks to be related to pushed gateway IPs on tap interfaces. I'll investigate that further.
- Status changed from Feedback to Resolved
The issue I turned this into is fixed.
Dmitriy: your issue is #5981, fix for that coming on that ticket momentarily.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by