OpenVPN quits on WAN IP change
-
@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.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...)
