OpenVPN broken since pfSense 2.1.1

I've tried pfSense 2.1.1, 2.1.2 and 2.1.3 but whenever I'm trying to copy data across the VPN tunnel the OpenVPN deamon dies with "event_wait : Interrupted system call (code=4)" error message. Its a site to site VPN with a pfSense 2.1 box at the other end.
When running pfSense 2.1 at both ends its rock stable.

Maybe the pfSense team should start using two branches of updates, one with ONLY security fixes and one with both security and bug/improvement fixes a la how VMware does it.

Not being able to plug the serious security holes as of late due to other fixes/improvements that seems to have broken the OpenVPN functionality is not an optimal solution.

Was this clean install, upgrade? Are you am64 or i386? What hardware are you running on.

How is anyone suppose to help you find the source of your problem without any details? Maybe users should actually post information that can help them when they first post, because having to ask for it is not an optimal method ;)

Was this clean install, upgrade? Are you am64 or i386? What hardware are you running on.

How is anyone suppose to help you find the source of your problem without any details? Maybe users should actually post information that can help them when they first post, because having to ask for it is not an optimal method ;)

While I do agree with you completely about posting the required information (I really do ;) ), if I may add: it would be handy if the powers that be, together with the other powers that be (you know who you all are, fine forum members without whom etc 8) ) would compile and sticky a post with required information. I am an economist by education and profession, and I tried to at least tell something about my hardware in my sig. But for me, as a non-technical man, it is guessing what kind of information I would need to provide.

In my career I have worked for some huge companies (yes, Big Blue was one of them, I was over at ICG ;D ), and in there they had simple checklists for customers who required support: 'please provide us with the following information to speed up processing your ticket'.

I am sure the great powers & powers can easily make a list of CLI-outputs and such which will satisfy every need.

Have you tried adjusting the Gateway Latency Thresholds (System->Routing->Gateways(edit gateway)->Advanced) to try and stop the delays from getting triggered at all?

It might be worth a try at least for test purposes to set the Latency triggers up to 750 and 950 (ms) to eliminate any possibility of a trip. You might look at the RRD graphs around the time that you max out the VPN link to see what your max latency actually shows.

Historically I've run into similar problems, but always with very poor ADSL connections that show 500ms-850ms of latency :P

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.

Have you tried adjusting the Gateway Latency Thresholds (System->Routing->Gateways(edit gateway)->Advanced) to try and stop the delays from getting triggered at all?

It might be worth a try at least for test purposes to set the Latency triggers up to 750 and 950 (ms) to eliminate any possibility of a trip. You might look at the RRD graphs around the time that you max out the VPN link to see what your max latency actually shows.

Historically I've run into similar problems, but always with very poor ADSL connections that show 500ms-850ms of latency :P

Well, this seems to have fixed the problem. I set my ping threshold for this connection (which is only 768kbps upstream DSL) to 750/1000ms. My offsite backup is working again. I also haven't seen the OpenVPN message "event_wait : Interrupted system call (code=4)" since. And while it will spike up momentarily, it seems to have a nominal ping of around 300ms during this transfer. I'm running RDP simultaneously and it seems OK.

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.

Looks veeery much like the real culprit to your (and perhaps others' problems). That being said, I think it's important to keep your changes down to one at a time. So my suggestion is to leave it run with the "latency fix" for tonight/tomorrow (whatever you feel "proves" the fix) and then back the latency fix out (reset the values back to nothing/default).

Then apply the "rc.newwanip" fix and see if the problem stays away. If so I think that would be a great indication that you've isolated out an insidious little bug :-\

Perhaps cmb (or someone appropriate) could be talked into turning this into a patch?

Since it is catching issues on the regular WAN as well, I think I need to apply the /etc/rc.newwanip fix and see what happens. I think my few problems were just internet latency issues (ISP, traffic, whatever)… but I'd like to try the other solution separately to see the result.

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.

Early indications (meaning: I applied this fix and rebooted, so exactly one data point) are that this fixed the EADDRINUSE bug that was causing my Openvpn (and that of others) to show up as "not running" in the gui even though it was (because somehow the pid in the pid file was wrong).

…what really is unpleasant is the time till the pfSense starts to use the new IP from DynDNS to re-establish the tunnel after a new IP has been given by the provider.

Right now, the new IP was at the DynDNS service at 21:49:18, but the box on the other side tried 6 times with the old IP to establish the tunnel and only at the 7th time (at 21:54:24, i.e. about 5 minutes after the update of the IP at the DynDNS) the tunnel came back...

…what really is unpleasant is the time till the pfSense starts to use the new IP from DynDNS to re-establish the tunnel after a new IP has been given by the provider.

Right now, the new IP was at the DynDNS service at 21:49:18, but the box on the other side tried 6 times with the old IP to establish the tunnel and only at the 7th time (at 21:54:24, i.e. about 5 minutes after the update of the IP at the DynDNS) the tunnel came back...

OpenVPN will attempt reconnect once a minute, and will succeed as soon as its DNS lookup obtains the new IP. That's dependent on the TTL of your dyndns provider, and whether or not the DNS servers you're using obey the TTL to being with. OpenVPN will successfully reconnect within 1 minute at most of your DNS record's TTL expiring. From that, it sounds like you have a 5 minute TTL on your dyndns.

The best case scenario is the DNS TTL plus up to 1 minute. Cases where up to a ~2 minute outage in the case of an IP change server-side aren't acceptable shouldn't be using dynamic IPs on the server side (doesn't matter client-side). You can get it faster than 6 minutes for sure, but potentially up to 2 minutes is the best case scenario.

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)

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!