OpenVPN quits on WAN IP change
-
@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.1is simply link-local destination on thepppoe0interface (not thehn1interface). This means that - as10.0.0.1is the default route configured in pfsense - all packets destined towards the default route are forwarded on thepppoelink 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 thepppoe0link), 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)
-
@mcfly9 said in OpenVPN quits on WAN IP change:
the multi tier connection flips over to the WAN2 interface and OpenVPN trying to bind to the wrong interface..?
maybe,.... "bingo" (but not) when the connection drops on WAN1 generates a switch between WANs,....
but the connection change (ISP),.... must be followed by OpenVPN... (due to the failover behavior)BTW:
one more question:
you say that, your port 25 (only 25) are filtered, well what does that do with a pure PPP connection?who has a connection without NAT (dual / CG, etc), pure ISP,, ... - without silly RFC1918 gateway....(? ):), there is no port filtering
+++edit:
your job / task is to protect your ports, this is a pure game from the ISP side....or not..
so whether there is NAT or not, this is an interesting question
my bet is....., I'll put it on the first statement (red number 7)
-
@mcfly9 said in OpenVPN quits on WAN IP change:
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..?
Having thought about this, this seems to be a wrong theory. The OpenVPN log approx 1 minute after the WAN IP change clearly says it is trying to bind to the old IP address of the WAN interface (and not the WAN2 which has a different static IP:
192.168.8.2). Also to me it seems that the OpenVPN tunnel is not disconnected by the WAN change event but simply due to no packets received (inactivity).I am also seeing no relevant entry in the routing logs about a potential WAN->WAN2 switch. I believe the WAN reconnection is happening fast enough for the tiered gateway to not notice.
What process is responsible for regenerating the OpenVPN config? And will that process kill existing OpenVPN processes before starting it new?
@DaddyGo said in OpenVPN quits on WAN IP change:
one more question:
you say that, your port 25 (only 25) are filtered, well what does that do with a pure PPP connection?I have never said that the PPP was filtered. The other end of the PPPoE connection is at the ISP. At that point, before forwarding packets to the public internet, they can filter whatever they want.
Not blaming them btw for the filtering (not happy about the fact that they are not willing to disable filtering for residential customers - but this is an other story) - 99.999% of the people won't need inbound TCP25, and most of them won't need outbound TCP25 either nowadays.
-
@mcfly9 said in OpenVPN quits on WAN IP change:
Having thought about this, this seems to be a wrong theory.
Yes, that is
@mcfly9 "What process is responsible for regenerating the OpenVPN config? "
others struggle with something similar:
https://forum.netgate.com/topic/144275/openvpn-reconnect-on-wan-dhcp-renewmy opinion is that..
any traffic passing through an RFC1918 address is surely identifiable...
otherwise, this step would not be necessary...so this public IP allocation strategy, method, is, to put it mildly, suspicious, as "Gertjan" indicated immediately
-
@DaddyGo said in OpenVPN quits on WAN IP change:
others struggle with something similar:
https://forum.netgate.com/topic/144275/openvpn-reconnect-on-wan-dhcp-renewI'd beg to differ on that. The issue in the thread you have linked is that the VPN connection disconnects on WAN DHCP renew. I have to stress again, I have no problem with my VPN dropping and reconnecting by itself when my WAN connection reconnects (and my client finds my server on the new IP after a DNS record update and DNS cache expiry), I am totally expecting that.
My issue is that the OpenVPN process sometimes gets killed in the process of the WAN disconnect-reconnect and after that obviously my site-to-site VPN won't reconnect by itself. I need to go into the "server" pfsense services section and manually start the openvpn instance.
-
@mcfly9 said in OpenVPN quits on WAN IP change:
My issue is that the OpenVPN process sometimes gets killed in the process of the WAN disconnect-reconnect
it gets complicated :)
(like I said we do this with the ExpressVPN interfaces, (OpenVPN))so I'm starting to understand ...
does the OpenVPN process die or not after the ISP IP change? OK- run an interface status monitor script, say F.E. something PING based...
- and then something like that:
#!/bin/sh
WAN_IP=/sbin/ifconfig vmx0 | /usr/bin/grep inet | /usr/bin/grep -v inet6 | /usr/bin/awk '{print $2}'
PUBLIC_IP=$(/usr/local/bin/curl -s https://api.ipify.org)
if [ "$WAN_IP" = "$PUBLIC_IP" ]
then
/usr/local/sbin/pfSsh.php playback svc restart openvpn client 1
fi+++edit:
attention it depends on your configuration - client 1- IPv4 / IPv6 -(inet6) and vmx...)
-
@DaddyGo said in OpenVPN quits on WAN IP change:
it gets complicated :)
Honestly, it does not.
As I mentioned in my initial post, I can work around the issue by running the watchdog package and just starting the server if it fails. The reason I am still on this thread is to find out whether any logs or any other info would help the developers to diagnose the WHY.
You suggested a few settings - I have implemented them, and we are waiting for the magic to happen.
Till now, nobody in this thread meaningfully commented on why OpenVPN would want to bind to an IP address that is not present any more on the system.
So to recap
My setup
- two locations, same ISP, both locations have pfsense
- one location (server) running dynamic dns to update a DNS record with the current WAN IP
- other location (client) using this DNS record to find the server
- OpenVPN site to site link defined, working good since 2+ years, routing traffic between the sites without issues
- site-to-site link most of the time reconnecting just fine after a WAN IP change on the server side or the client side
- pfsense on the server side is configured with two internet connections, WAN (PPPoE) and WAN2 (LTE) in a tiered configuration to fall back on WAN2 if WAN is not available.
Issue
Initial state on the server side:
Nov 20 05:12:09 ppp [wan] IPADDR 94.21.55.69A week later the ISP disconnects my pppoe link, pfsense automatically reconnects, receives a new IP on the
pppoe0interface. A minute later OpenVPN process exits and never gets restarted.Nov 27 05:12:14 ppp [wan] IPADDR 84.236.40.239 ... 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 Exiting due to fatal errorAfter this the OpenVPN server service instance shows in stopped state and therefore an automatic reconnection of the client is not possible.
I need to go into the admin interface and manually start the instance. After that client will connect.
Gateway logs are not showing a fallback in the time period above, only the following (no other log entries in the gateway log +/- 1h to the WAN IP change). From this, I believe that the backup WAN2 link does not have anything to do with the issue.Nov 27 05:12:16 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 8.8.8.8 bind_addr 84.236.40.239 identifier "WAN_PPPOE " Nov 27 05:12:16 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 8.8.4.4 bind_addr 192.168.8.2 identifier "WAN2GW " -
Complete logs for the time period:
System: https://gist.github.com/andrasg/a94d880b4b157180ddcd9469de7d9fa5
OpenVPN: https://gist.github.com/andrasg/f9f004dd97dfbb0de9b97c045d099594
Gateway: https://gist.github.com/andrasg/a9f97496db50887ab5b2a8bc233c6454Happy to provide any other info if it helps diagnosing the cause.
-
@mcfly9 said in OpenVPN quits on WAN IP change:
Honestly, it does not.
I don't know, how knows that
the "watchdog" is a forced solution, it means something that you fear(ed) will not work properly
yes it has already been described by "@Gertjan "
the end will be, if you are a serious provider, buy fixed IP, hihihihihhi
BTW:
there are pfSense instances in our park, that only need to be restarted, ... on updates... (OS, FW, or etc.)and / or if OpenVPN does not pick up the IP(s) it's a joke...(:
they work for months (pfSense + Open VPN servers / clients) without any problems, in this regrettable situation when our employees work from home...
the OpenVPN + pfSense works with more than 450 -550 users (in 4 countries, on 28 radio stations)
