Project

General

Profile

Bug #5952

dpinger doesn't start at times on OpenVPN interfaces

Added by Dmitriy K about 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
OpenVPN
Target version:
Start date:
03/05/2016
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.3
Affected Architecture:

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.

pfsn2.3ovpn_gw_bug.mp4 (1.24 MB) pfsn2.3ovpn_gw_bug.mp4 Dmitriy K, 03/05/2016 06:10 AM

Associated revisions

Revision 80d3cf1c (diff)
Added by Chris Buechler about 3 years ago

Doesn't seem to be any reason rc.newwanip should skip things while the system is booting. Ticket #5952

Revision ccdb9c3b (diff)
Added by Chris Buechler about 3 years ago

Don't exit if the system is booting, should always be unnecessary. related to Ticket #5952

History

#1 Updated by Chris Buechler about 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 about 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.

#3 Updated by Dmitriy K about 3 years ago

Maybe there is a way to turn on nice debug logs in pfSense which I could provide to you?

#4 Updated by Dmitriy K about 3 years ago

Just updated 2nd router to latest snapshot and ran into the same issue. it's 100% reproducible on both routers.

#5 Updated by Chris Buechler about 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 about 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.

#7 Updated by Dmitriy K about 3 years ago

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?

#8 Updated by Dmitriy K about 3 years ago

Tested on 2.3.b.20160311.1315 x64: Issue is not fixed, unfortunately;

#9 Updated by Dmitriy K about 3 years ago

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.

#10 Updated by Jim Pingle about 3 years ago

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.

#11 Updated by Dmitriy K about 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?

#12 Updated by Chris Buechler about 3 years ago

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.

#13 Updated by Chris Buechler about 3 years ago

  • 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