OpenVPN quits on WAN IP change
-
Every once in a while when my ISP decides to restart my line, OpenVPN does not really survive the IP change and simply quits.
Oddly, the error message that OpenVPN logs shows that it is trying to bind to the "old" IP address:
OpenVPN log:
Nov 27 05:13:14 openvpn 93648 /usr/local/sbin/ovpn-linkdown ovpns1 1500 1572 192.168.253.1 192.168.253.2 init Nov 27 05:13:14 openvpn 93648 Exiting due to fatal error Nov 27 05:13:14 openvpn 93648 TCP/UDP: Socket bind failed on local address [AF_INET]94.21.55.69:1194: Can't assign requested address (errno=49) Nov 27 05:13:14 openvpn 93648 Preserving previous TUN/TAP instance: ovpns1 Nov 27 05:13:14 openvpn 93648 Re-using pre-shared static key Nov 27 05:13:14 openvpn 93648 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Nov 27 05:13:09 openvpn 93648 SIGUSR1[soft,ping-restart] received, process restarting Nov 27 05:13:09 openvpn 93648 Inactivity timeout (--ping-restart), restarting
System log just before this:
Nov 27 05:14:30 kernel pid 129 (ntopng), jid 0, uid 0: exited on signal 11 (core dumped) Nov 27 05:13:14 check_reload_status Reloading filter Nov 27 05:13:14 kernel ovpns1: link state changed to DOWN Nov 27 05:12:27 check_reload_status Starting packages ... Nov 27 05:12:14 check_reload_status rc.newwanip starting pppoe0 Nov 27 05:12:14 ppp [wan] 84.236.40.239 -> 10.0.0.1 Nov 27 05:12:14 ppp [wan] IPCP: LayerUp Nov 27 05:12:14 ppp [wan] IPCP: state change Ack-Sent --> Opened Nov 27 05:12:14 ppp [wan] IPADDR 84.236.40.239
Note, OpenVPN tries to bind to
94.21.55.69:1194
while theWAN
interface has the IP84.236.40.239
by then since about a minute ago. Looks like OpenVPN notices the connection down and tries to rebind to the wrong address.Basically I would have two asks:
- Fixing this issue would be nice
If no fix can be developed, some restart logic on the OpenVPN service would be nice that would simply restart the service if it fails- found the watchdog package, this seems to be doing what I need
-
@mcfly9 said in OpenVPN quits on WAN IP change:
Every once in a while when my ISP decides to restart my line, OpenVPN does not really survive the IP change and simply quits.
Hi,
You could try the following:
- Clear all states on WAN IP Change" in the Advanced Settings -> Network Tab, = tick
-OpenVPN client Custom options - ;auth-retry nointeract
BTW:
if not needed, don't share your public IP address, because így most már tudom, hogy magyar vagy és a DIGI a szolgáltatód, hihihihi
+++edit:
Ritkán látok itt magyarokat, senki nem fél a vezetéstől...... - Clear all states on WAN IP Change" in the Advanced Settings -> Network Tab, = tick
-
Hi,
Your log shows :@mcfly9 said in OpenVPN quits on WAN IP change:
84.236.40.239 -> 10.0.0.1
If you're using pppoe, where does this "10.0.0.1" comes from ?
A Modem type WAN device shouldn't offer a RFC1918.@mcfly9 said in OpenVPN quits on WAN IP change:
(ntopng), jid 0, uid 0: exited on signal 11 (core dumped)
ntopng isn't happy neither.
A coredump isn't the normal a process stops.@mcfly9 said in OpenVPN quits on WAN IP change:
to 94.a.b.c:1194 while the WAN interface has the IP 84.e.f.f
Before openvpn restarts, its config file is recreated with the IP of the - typically - WAN interface at that moment.
So, one minute after the WAN IP changed, your GUI > Status > Interfaces > IPv4 address still shows the old IP ?Also, 'packages' like openvpn are restarted when there is a new WAN IP. So when the new WAN IP is in place.
You didn't not show enough info to locate the real problem.
@mcfly9 said in OpenVPN quits on WAN IP change:
found the watchdog package
This packages should only be used as a last resort and other urgent matters.
The issue should be solved properly.Using pppoe and have your WAN IP change every xx hours is quiet known for many pfSense users. I've been using it for years in the past.
True, there was this delay, when the dyndns type url that point to my WAN IP wasn't updated yet - a couple of minutes or so - but it worked well. -
@Gertjan said in OpenVPN quits on WAN IP change:
If you're using pppoe, where does this "10.0.0.1" comes from ?
A Modem type WAN device shouldn't offer a RFC1918.this nonsense is used by the DIGI service provider in Hungary, for example:
Traceroute...
1 <1 ms <1 ms <1 ms 192.168.2.1
2 <1 ms <1 ms <1 ms 192.168.1.1
3 1 ms 1 ms 2 ms 10.0.0.1
4 2 ms 2 ms 5 ms 10.1.129.225
5 3 ms 2 ms 2 ms et-4.dr02.xv.digicable.hu [78.131.4.36]
6 1 ms 1 ms 1 ms xe-0-3-1.cr01.budapest.digicable.hu [78.131.3.56+++edit:
-
@mcfly9 said in OpenVPN quits on WAN IP change:
Every once in a while when my ISP decides to restart my line, OpenVPN does not really survive the IP change and simply quits.
If the server address changes, what is the client supposed to connect to? Are you talking about an address change during a VPN session? Or at some other time? How does the client know about the address? The change?
BTW, OpenVPN has no problem if the client address changes. Several years ago, I deliberately tried that and it continued to work.
-
@JKnott said in OpenVPN quits on WAN IP change:
Are you talking about an address change during a VPN session? Or at some other time?
in my understanding the OP says when the ISP changes the WAN IP address
-
Yes, I saw that. The question is when, in relation to a VPN connection, does it happen? If the address changes, the client has to somehow learn of it. How does that happen? How long does it take? I would expect a server address change to cause problems. In my case, the IPv4 address rarely changes and the host name only when I change hardware. So, in the extremely unlikely chance the address changes during a VPN session, I expect the VPN to fail, until the client makes a DNS call to get the new address.
-
@JKnott said in OpenVPN quits on WAN IP change:
The question is when, in relation to a VPN connection, does it happen? If the address changes, the client has to somehow learn of it.
the problem description is ambiguous, anyway...
it's a stupid dual NAT solution with this provider...
(long ago and in a few places even now, there were distribution networks in the stairwell and there it got the RFC1918 IP for the whole block / building(s))this may be an outbound connection from pfSense to an OpenVPN server, the client is inside pfSense (??)
not a VPN, because these IPs are known Hungarian service provider addresses
-
All the more reason to move to IPv6. This hiding behind NAT, while refusing to move to IPv6 is head in sand stupidity. I first read about IPv6 over 25 years ago and have been running it for over 10. It's time to get with the program people! IPv4 hasn't been adequate since the day it became necessary to use NAT to get around the IPv4 address shortage.
-
@JKnott said in OpenVPN quits on WAN IP change:
All the more reason to move to IPv6. This hiding behind NAT,
Yup...
Opinions vary, in an internal network, we still fit on IPv4
At the ISP level, the situation is different, especially since IoT / 5G is around our necks, etc.My problem is that IPv6 is not as controllable for me as IPv4
but really it's time to switch on the ISP(s) sideby the way, this (DIGI) is not an original Hungarian service provider, it came to the country 5-8 years ago, from neighboring Romania...
with us, they say - cheap meat has dilute juice (sauce)
-
My ISP has provided native IPv6 for about 5 years and via tunnel for a few years before that. They also own the cell network I use and my phone is IPv6 only, so it has to use 464XLAT for IPv4. I also get IPTV from them, which is also IPv6. On the other hand, their main competitor, the local phone company, is still stuck in the sand.
-
@JKnott said in OpenVPN quits on WAN IP change:
My ISP has provided native IPv6 for about 5 years
I have been living in Portugal for 10 years...because of my job :) and last but not least politics (:
In 3 years (2017 - 2020), the whole country has been fitted with optics throughout, in every household it is almost...
-basic package (for 35 EUROS), the two fixed WAN IPs (IPv4 and IPv6) for us GPON 1000/800
so it's just a matter of will
-
Wow, lot of posts in a few hours :) I will try to address each question one by one.
@Gertjan said in OpenVPN quits on WAN IP change:
If you're using pppoe, where does this "10.0.0.1" comes from ?
A Modem type WAN device shouldn't offer a RFC1918.As @DaddyGo has explained, this is some stupid Digi thing. The are using
10.0.0.1
(an address that doesn't even consistently replies to pings...) as the next hop towards the internet.
I am not using double NAT btw, my modem is in "bridge mode" where I can use a PPPoE connection (PPPOE0
defined in pfsense) over thehn1
ethernet interface (that is not assigned).@Gertjan said in OpenVPN quits on WAN IP change:
ntopng isn't happy neither.
A coredump isn't the normal a process stops.Right. So the issue is not that the VPN connection drops. That is totally expected when the WAN IP changes. The issue is that in this process the OpenVPN service quits and is therefore not any more available to accept client connections.
@Gertjan said in OpenVPN quits on WAN IP change:
So, one minute after the WAN IP changed, your GUI > Status > Interfaces > IPv4 address still shows the old IP ?
I am not sure, I was never able to witness this myself as this usually happens between 4am-6am, when the ISP decides to recycle my connection. My statement was based on the log entry of OpenVPN showing OpenVPN trying to bind to the old IP, approx. 1 minute after the WAN connection has received a new IP:
Nov 27 05:13:14 openvpn 93648 TCP/UDP: Socket bind failed on local address [AF_INET]94.21.55.69:1194: Can't assign requested address (errno=49)
and:
Nov 27 05:12:14 ppp [wan] IPADDR 84.236.40.239
@Gertjan said in OpenVPN quits on WAN IP change:
You didn't not show enough info to locate the real problem.
What other logs would you need?
@Gertjan said in OpenVPN quits on WAN IP change:
Using pppoe and have your WAN IP change every xx hours is quiet known for many pfSense users. I've been using it for years in the past.
True, there was this delay, when the dyndns type url that point to my WAN IP wasn't updated yet - a couple of minutes or so - but it worked well.And I have been using this setup for quite a while now and this symptom doesn't happen on all WAN IP changes. I have dyndns update the dns record, and as soon as the client's dns cache expires (300sec) the client will reconnect to the new IP. This is accepted and fine for me - it only happens a few time a month.
What is not expected and is annoying me is that the OpenVPN process dies as part of this WAN disconnection triggered flow of events and I need to manually start OpenVPN to get the server accepting client connections again.@DaddyGo said in OpenVPN quits on WAN IP change:
if not needed, don't share your public IP address, because így most már tudom, hogy magyar vagy és a DIGI a szolgáltatód, hihihihi
+++edit:
Ritkán látok itt magyarokat, senki nem fél a vezetéstől......@JKnott said in OpenVPN quits on WAN IP change:
@mcfly9 said in OpenVPN quits on WAN IP change:
Every once in a while when my ISP decides to restart my line, OpenVPN does not really survive the IP change and simply quits.
If the server address changes, what is the client supposed to connect to? Are you talking about an address change during a VPN session? Or at some other time? How does the client know about the address? The change?
BTW, OpenVPN has no problem if the client address changes. Several years ago, I deliberately tried that and it continued to work.
Clients use DNS to find the server. Whenever the ISP decides to cut my connection, pfsense reconnects wan, restarts OpenVPN, dynamic dns updates DNS records pointing to the server, clients' DNS cache expires and finds the new place to connect to and reconnects - things are happy. This process works fine most of the time. Some times though as part of this process the OpenVPN process dies and is not restarted. One occasion is captured in the logs in my initial post.
@JKnott said in OpenVPN quits on WAN IP change:
Yes, I saw that. The question is when, in relation to a VPN connection, does it happen? If the address changes, the client has to somehow learn of it. How does that happen? How long does it take? I would expect a server address change to cause problems. In my case, the IPv4 address rarely changes and the host name only when I change hardware. So, in the extremely unlikely chance the address changes during a VPN session, I expect the VPN to fail, until the client makes a DNS call to get the new address.
With my ISP (Digi in Hungary) IP address changes with every PPPoE reconnect. As far I have seen the connection usually runs uninterrupted for about a week or so before it gets terminated and pfsense automatically reconnects.
@DaddyGo said in OpenVPN quits on WAN IP change:
it's a stupid dual NAT solution with this provider...
(long ago and in a few places even now, there were distribution networks in > the stairwell and there it got the RFC1918 IP for the whole block / building(s))
this may be an outbound connection from pfSense to an OpenVPN server, the client is inside pfSense (??)not a VPN, because these IPs are known Hungarian service provider addresses
By default they do double NAT. I have asked their customer service to put me in bridge mode and now instead of just using DHCP on the Ethernet port of their modem, I am using PPPoE on that very same port. This way I am not double NAT'ed and see a public IP on my PPPoE connection interface instead of seeing a NAT'ed IP on the ethernet interface.
Digi are still doing FTTB sometimes, when they put a box with GPON and a switch into the stairwell in the building and you only get the Ethernet cable to you. I have FTTH, so I have a GPON in my location with an ethernet interface connected to my pfsense.I have two locations, both on Digi as the ISP and both have pfsense running OpenVPN. I have a site-to-site link between these two. The logs in my initail post are from the server side. I am not experiencing similar behavior (OpenVPN process stopping after a WAN reconnect) on the client side. The link has been running without issues for the past 2 years and in that time I have experienced this behavior (OpenVPN service stopped after WAN reconnect) around 10 times - so far less frequent than the WAN IP address changed.
@JKnott said in OpenVPN quits on WAN IP change:
All the more reason to move to IPv6. This hiding behind NAT, while refusing to move to IPv6 is head in sand stupidity. I first read about IPv6 over 25 years ago and have been running it for over 10. It's time to get with the program people! IPv4 hasn't been adequate since the day it became necessary to use NAT to get around the IPv4 address shortage.
Cannot agree more. Believe me, I have tried. I have re-tried every 1-2 year or so in the past 6+ years. Unfortunately I always had weird, inexplicable issues so I always quit trying
@DaddyGo said in OpenVPN quits on WAN IP change:
with us, they say - cheap meat has dilute juice (sauce)
It's cheap indeed (€10 / month for unlimited fiber based gigabit 1000mbit down / 300mbit up). Apart from the
10.0.0.1
annoyance, I have been happy with them for the past 3-4 years. Downtime is acceptable (max few hours at a time - usually between 1am-3am -, I'd say less than 12h in total for last year), speed is usually decent (never drops below 600mbit). -
@mcfly9 said in OpenVPN quits on WAN IP change:
By default they do double NAT. I have asked their customer service to put me in bridge mode and now instead of just using DHCP on the Ethernet port of their modem, I am using PPPoE on that very same port. This way I am not double NAT'ed and see a public IP on my PPPoE connection interface instead of seeing a NAT'ed IP on the ethernet interface.
Látod, ha pörög a fórum, mi történik...
(jó magyarul írni, bocs :),
Your public IP is virtual, well that's not a good wording, but it is...
I would say supervised...Hmmm, this makes it another CGNAT, no matter how we beautify the thing...
for me, this happens at ExpressVPN, sometimes
the setting which was described above solved the issue by 85%...
(I’m already talking about not coming back to the .... IPs)@gertjan he is a very well trained professional, worth listening to...
try to represent this state with a packets interception and submit the logos here
a short system description would be nothing wrong
You know...
what it connects to and what the point is -
@DaddyGo said in OpenVPN quits on WAN IP change:
Your public IP is virtual, well that's not a good wording, but it is...
I would say supervised...
Hmmm, this makes it another CGNAT, no matter how we beautify the thing...Well, with PPPoE, it's not CGNAT. I get a publicly addressable and routed IP and I am able to accept incoming connections to any port (except tcp/25...).
-
@DaddyGo said in OpenVPN quits on WAN IP change:
the setting which was described above solved the issue by 85%...
I have now enabled this setting (Reset all states if WAN IP Address changes) and will have a look what happens.
-
@mcfly9 said in OpenVPN quits on WAN IP change:
I get a publicly addressable and routed IP
the 25 already, I hope nowhere...
10.0.0.0/8 is an RFC1918 range, so you are NATed -
@mcfly9 said in OpenVPN quits on WAN IP change:
I have now enabled this setting (Reset all states if WAN IP Address changes) and will have a look what happens.
plus this: ;auth-retry nointeract
-
@DaddyGo said in OpenVPN quits on WAN IP change:
the 25 already, I hope nowhere...
10.0.0.0/8 is an RFC1918 range, so you are NATedSo if it would be nat'ed, how would I be able to accept inbound connections to an arbitary UDP port?
This is what I see on the interface:
It's only the default gateway which is RFC1918.
-
@mcfly9 said in OpenVPN quits on WAN IP change:
So if it would be nat'ed, how would I be able to accept inbound connections to an arbitary UDP port?
since
, DIGI a good head and all the ports are forwarded, but yours goes through his NAT