OpenVPN quits on WAN IP change
-
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
-
@mcfly9 said in OpenVPN quits on WAN IP change:
It's only the default gateway which is RFC1918.
don't trust them
+++edit:
this is very simple, what is the modem LAN or mng. IP and what is...... 10.0.0.1? -
@DaddyGo said in OpenVPN quits on WAN IP change:
this is very simple, what is the modem LAN or mng. IP and what is...... 10.0.0.1?
Now I think we are confusing layers. The
hn1
(Ethernet) interface in pfsense does not have an IP address. The modem does not need an IP address either as communication happens in a lower layer (PPPoE - "layer 2.5").
In the data-link layer, PPPoE is running encapsulated in Ethernet to provide a logical link. In a layer above that (network layer) you have IPv4/IPv6 and that's where you have IP addresses.10.0.0.1
is simply link-local destination on thepppoe0
interface (not thehn1
interface). This means that - as10.0.0.1
is the default route configured in pfsense - all packets destined towards the default route are forwarded on thepppoe
link towards10.0.0.1
. It's the ISP's - in my view questionable - practice to utilize a non-public IP address for the default route, but it's totally irrelevant I believe in the question whether the connection is NAT'ed or not.As for the NAT question. I believe there's no NAT. NAT would mean address translation: you have an IP address on your device that does not match the public IP address that is used to communicate your packets towards the public internet.
In my case, as the internet is seeing my packets with the same IP address as what I am seeing on the end of my link (eg: checkmyip shows the same IP as my IP on thepppoe0
link), it does not make sense to talk about address translation, imho.(this thread got quickly out of hands, happy to launch a different one for the rather academic discussion on NAT or not NAT)
-
@DaddyGo said in OpenVPN quits on WAN IP change:
plus this: ;auth-retry nointeract
Thanks for pointing this out. Added it to the client config.
-
@mcfly9 said in OpenVPN quits on WAN IP change:
Well, with PPPoE, it's not CGNAT.
One has nothing to do with the other. PPPoE is how your ISP delivers your Internet connection. CGNAT is what an ISP uses when they don't have IPv4 addresses to hand out. PPPoE can equally well hand out NAT or public addresses.
-
@mcfly9 said in OpenVPN quits on WAN IP change:
It's only the default gateway which is RFC1918.
That doesn't make sense. The gateway has to be within the same subnet as your LAN.
-
@JKnott said in OpenVPN quits on WAN IP change:
One has nothing to do with the other. PPPoE is how your ISP delivers your Internet connection. CGNAT is what an ISP uses when they don't have IPv4 addresses to hand out. PPPoE can equally well hand out NAT or public addresses.
True. What I meant was that in case of my ISP, when the modem is in bridge mode (and I have to use PPPoE to get a connection), the ISP hands out non-NAT'ed IP's (to the PPPoE interface).
When in default mode, it typically (but not always) hands out IP addresses from a private range through DHCP. -
@JKnott said in OpenVPN quits on WAN IP change:
@mcfly9 said in OpenVPN quits on WAN IP change:
It's only the default gateway which is RFC1918.
That doesn't make sense. The gateway has to be within the same subnet as your LAN.
I have been amazed too. It's simply how they are doing it. It is like that on my other location with Digi too.
(BTW, if you have a /32 mask, everything is outside of your subnet...)
Here's the routing table (I have reconnected, my IP changed):
-
That's a bit different. I see those link#10 connections. This means you're using the interface as the default route. I see you also have 2 different IP addresses as a gateway, along with pppoe. On point to point links, an interface is all you need.
-
I have a WAN2 backup over 4G, that’s why the multiple gateways. The 8.8.4.4 ip is the connectivity monitor IP on the backup link.
-
And now that I think about it a little more, this might be the cause: the multi tier connection flips over to the WAN2 interface and OpenVPN trying to bind to the wrong interface..?
(The OpenVPN server is configured on the TieredGW)