OpenVPN broken since pfSense 2.1.1
-
Many thanks for the detailed explanation, the TTL is crucial, I understand that fully… When I have a little time I will switch server and client for some tunnels... ;)
-
Update: Yesterday tunnels were stable for 24 hrs (since the last IP change on one tunnel end), no mysterious restarts of packages.
But 3 minutes after successful re-connect yesterday evening (change of IP on the other end of the tunnel), suddenly the Syslog has a
"check_reload_status: updating dyndns WAN_DHCP"
although the IP has NOT changed for this connection and the same second the box restarts IPsec/openVPN tunnels, reloads filters, restarts snort, the full program…
ADD: It was an apinger alarm delay, again…. :-\
Is it possible that there is an additional bug in the dyndns-updating script?
At another pfSense, where the IP does not change frequently I get a daily:
"php:rc.dyndns.update: phpDynDNS (): No change in my IP address and/or 25 days not passed. Not updating dynamic DNS entry"
in the Syslog.
![restart tunnels packages 22.05.2014.JPG](/public/imported_attachments/1/restart tunnels packages 22.05.2014.JPG)
![restart tunnels packages 22.05.2014.JPG_thumb](/public/imported_attachments/1/restart tunnels packages 22.05.2014.JPG_thumb) -
@cmb:
If you don't have any gateway alarms, there is a potential second cause I just fixed. Edit /etc/rc.newwanip and find where it has curnwanip in there. Replace that with curwanip (just remove the n), save, might want to reboot afterwards just to be 100% sure nothing is using the old code. Be careful when editing any code like that. That made things think your WAN IP had changed in cases where it hadn't, so it did things like restart VPNs where it was unnecessary.
I just tried reverting the latency settings for the gateway back to default and applying the change to /etc/rc/newwanip
Looks like that setting alone is not enough to fix the problem.
I'll add the latency settings back to the gateway.
-nb![DSL1 still choking.jpg](/public/imported_attachments/1/DSL1 still choking.jpg)
![DSL1 still choking.jpg_thumb](/public/imported_attachments/1/DSL1 still choking.jpg_thumb) -
It looks like i'm in the same boat as you guys … Keep loosing my VPN tunnel ... I'll try to change the latency settings + edit that file...
Will see how it goes...
-
Just to add something… It looks like the tunnel drop each hours for me ... When it drops, I need to restart the OpenVPN instance ... I'll post some logs later, Maybe I have another issue....
-
Hello!
Same for me - if I remember right - the problem started with 2.1.1 - OpenVPN-Tunnles crash on heavy throughput.
openvpn[13066]: event_wait : Interrupted system call (code=4)
Bye,
eweri -
I'm still having occasional problems with bandwidth over OpenVPN links, even after applying the update to rc.newwanip and increasing my latency thresholds to 1000/2000ms.
Ugh.
I'll have to start digging around through logs again next week.
-
Check if you have the same MTU on both ends.
Maybe you should lower MTU a bit, perhaps the route between the two ends caps the package size, and fragmentation occurs, and it gets unhandled properly. -
What I noted earlier in this thread, and here:
https://forum.pfsense.org/index.php?topic=76975.msg426742#msg426742will fix the "event_wait : Interrupted system call". specifics discussed there.
-
I believe I'm also having this issue. I was seeing the same Interrupt messages until I put in the latency fix mentioned earlier. Now I see the below in the logs. What I don't understand is why are both of my OpenVPN Client Gateways showing an IP address (that they should get from the OpenVPN server), and yet, both gateways show as down under STATUS>OpenVPN? I'm running 2.1.4 i386. Thanks!
Aug 3 18:27:36 openvpn[94132]: UDPv4 link remote: [AF_INET]OpenVPN_Server:1194 Aug 3 18:27:36 openvpn[94132]: UDPv4 link local (bound): [AF_INET]WAN_IP Aug 3 18:27:36 openvpn[94132]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 3 18:27:36 openvpn[94132]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Aug 3 18:27:34 openvpn[67441]: UDPv4 link remote: [AF_INET]OpenVPN_Server:1194 Aug 3 18:27:34 openvpn[67441]: UDPv4 link local (bound): [AF_INET]WAN_IP Aug 3 18:27:34 openvpn[67441]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 3 18:27:34 openvpn[67441]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Aug 3 18:27:34 openvpn[94132]: SIGUSR1[soft,ping-restart] received, process restarting Aug 3 18:27:34 openvpn[94132]: [UNDEF] Inactivity timeout (--ping-restart), restarting Aug 3 18:27:32 openvpn[67441]: SIGUSR1[soft,ping-restart] received, process restarting Aug 3 18:27:32 openvpn[67441]: [UNDEF] Inactivity timeout (--ping-restart), restarting