Openvpn issues since 1.0RC3
-
Hi,
Since upgrading to RC3 I have firewalling issues with OpenVPN.
My setup is pretty simple (didn't managed to get dual wan+openvpn+ipsec+ftp - so I have 2 boxes for now) - I have a Wan and Lan (172.16.18.0/23) interface and an openvpn connection to a remote subnet (172.16.8.0/24).
The openvpn subnet being on 172.16.9.0/24.This morning, the openvpn connexion was up (tunnel status was ok according to the logs on both ends) but no traffic was going through it, everything was blocked by the firewall :
Oct 6 10:53:12 vpn pf: 193911 rule 323/0(match): block out on tun0: 172.16.9.14.57710 > 172.16.8.11.21: S 146483516:146483516(0) win 65228
According to the monitoring I had in place, everything stopped going through that link at 4h10AM - which is the log rotation time it seems.
Stopping and restarting the openvpn tunnel brought everything back up.
This morning, we had to reboot as pfsense locked (due to bad memory it seems - bad luck is with us) - and after the reboot the tunnel was up again, but all the traffic was locked out by the firewall. Stopping and restarting openvpn fixed the issue.
Here are the corresponding logs (openvpn connected fine - the issue is a fw issue - see previous log quote) :
Oct 6 10:52:12 vpn openvpn[282]: OpenVPN 2.0.6 i386-portbld-freebsd6.1 [SSL] [LZO] built on Apr 6 2006
Oct 6 10:52:12 vpn openvpn[282]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Oct 6 10:52:12 vpn openvpn[282]: WARNING: file '/var/etc/openvpn_client0.key' is group or others accessible
Oct 6 10:52:12 vpn openvpn[282]: WARNING: file '/etc/tls_auth.key' is group or others accessible
Oct 6 10:52:12 vpn openvpn[282]: Control Channel Authentication: using '/etc/tls_auth.key' as a OpenVPN static key file
Oct 6 10:52:12 vpn openvpn[282]: LZO compression initialized
Oct 6 10:52:12 vpn openvpn[283]: UDPv4 link local: [undef]
Oct 6 10:52:12 vpn openvpn[283]: UDPv4 link remote: 213.y.y.y:1194
Oct 6 10:52:13 vpn openvpn[283]: [remote-vpn] Peer Connection Initiated with 213.y.y.y:1194
Oct 6 10:52:14 vpn openvpn[283]: gw 62.x.x.x
Oct 6 10:52:14 vpn openvpn[283]: TUN/TAP device /dev/tun0 opened
Oct 6 10:52:14 vpn openvpn[283]: /sbin/ifconfig tun0 172.16.9.14 172.16.9.13 mtu 1500 netmask 255.255.255.255 up
Oct 6 10:52:14 vpn openvpn[283]: /etc/rc.filter_configure tun0 1500 1558 172.16.9.14 172.16.9.13 init
Oct 6 10:52:14 vpn openvpn[283]: Initialization Sequence Completed
Oct 6 10:55:34 vpn openvpn[283]: event_wait : Interrupted system call (code=4)
Oct 6 10:55:34 vpn openvpn[283]: /etc/rc.filter_configure tun0 1500 1558 172.16.9.14 172.16.9.13 init
Oct 6 10:55:35 vpn openvpn[283]: SIGTERM[hard,] received, process exiting
Oct 6 10:55:45 vpn openvpn[1361]: OpenVPN 2.0.6 i386-portbld-freebsd6.1 [SSL] [LZO] built on Apr 6 2006
Oct 6 10:55:45 vpn openvpn[1361]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Oct 6 10:55:45 vpn openvpn[1361]: WARNING: file '/var/etc/openvpn_client0.key' is group or others accessible
Oct 6 10:55:45 vpn openvpn[1361]: WARNING: file '/etc/tls_auth.key' is group or others accessible
Oct 6 10:55:45 vpn openvpn[1361]: Control Channel Authentication: using '/etc/tls_auth.key' as a OpenVPN static key file
Oct 6 10:55:45 vpn openvpn[1361]: LZO compression initialized
Oct 6 10:55:45 vpn openvpn[1362]: UDPv4 link local: [undef]
Oct 6 10:55:45 vpn openvpn[1362]: UDPv4 link remote: 213.y.y.y:1194
Oct 6 10:55:46 vpn openvpn[1362]: [remote-vpn] Peer Connection Initiated with 213.y.y.y:1194
Oct 6 10:55:47 vpn openvpn[1362]: gw 62.x.x.x
Oct 6 10:55:47 vpn openvpn[1362]: TUN/TAP device /dev/tun0 opened
Oct 6 10:55:47 vpn openvpn[1362]: /sbin/ifconfig tun0 172.16.9.14 172.16.9.13 mtu 1500 netmask 255.255.255.255 up
Oct 6 10:55:47 vpn openvpn[1362]: /etc/rc.filter_configure tun0 1500 1558 172.16.9.14 172.16.9.13 init
Oct 6 10:55:47 vpn openvpn[1362]: Initialization Sequence CompletedNB : forgot to dump pf rules before and after the restart - wanted to bring the link back up fast … next time :)
-
Please read up on the forum. This has been discussed in datail. You MUST NOT assign the tun interface for openvpn. There's a bug in the documentation. Filtering on openvpn tunnels is not supported in version 1.0. Don't assign the tun interface.
-
Oh and just a comment on those who did in RC2 (or earlier) and upgraded to RC3:
My steps were:
- disable OVPN Interface (tun0)
- delete it afterwards
- update to RC3 (rc3a, b, c, d, e)
- looking for OpenVPN - seems up BUT:
- PF had many "blocks" on TUN0
- check of rules.debug shows no rule for tun0 or TUN0 at all - modified some rule on the LAN interface (just entered edit mode on the default one)
- saved it (without changing anything, so rules.debug gets rewritten by the new rc3 version)
- reloaded the filter rules
- checked rules.debug -> two entries for tun0 showed up with a "pass all" type kind of rule
- everything works smooth again
just my 0,02 from this mornings upgrade session :)
-
hoba : I will check what I did, but I did not follow the documentation at all.
The steps I followed are those :- Install RC2
- Install the openvpn package
- Configure openvpn client configuration (endpoints, keys, certificats)
- add a few custom options
tls-auth /etc/tls_auth.key 1;ns-cert-type server;nobind;resolv-retry infinite;ns-cert-type server;
- upload my tls_auth
- Everything worked smoothly
- Upgrade to RC3 and started to have issues
The only interfaces configured in the webif are wan and lan.
-
Well guys, we played a lot with openvpn by now and there are NO problems when upgrading from RC2 to RC3,
the documentation is just a bit useful, but it's much easier than that:just follow the web-gui with it:
use PKI ;D for a server when more clients shall connect or use PSK >:( when only one shall…
After that you follow the instructions on the software-side of openvpn (on windows read the readme.txt in easy-rsa-dir)
Have an eye on: Port 1194 UDP from any -> WAN-Adress, for the client to reach the pfsense and it should work without problems...
-
just follow the web-gui with it:
use PKI ;D for a server when more clients shall connect or use PSK >:( when only one shall…The server I'm connecting to is running a regular BSD and I have a PKI to manage all the clients.
The openvpn running on pfsense is just a client, all I did to set it up was through the webif (as mentionned earlier) : paste CA certificate, Client certificate, Client key, set the crypto options, add the custom options mentionned earlier and the tls-auth file.
The issue is not in openvpn itself (which works like a charm - connexion was established) but in the firewall which blocked all the openvpn lan<->lan traffic on the last startup and after a log rotation at 4 AM this morning.
Each time restarting openvpn cleared the issue (this morning I was connected remotely, restarted the server - and on the second time I restarded openvpn on the pfsense box)It seems I had the issue Grey mentionned earlier, it's as if the pass all rule on tun0 was not set for some reason.
For now I have my second box running like a charm (almost same setup) - and I checked the one with issues : there is no rule regarding tun0 in rules.debug.
It could be because the box is not connected and the vpn is down though - not sure when those rules are added (will go check svn for that) -
After some investigations, it seems there is a race condition somewhere.
When the openvpn tunnel is down, there is no tun interface created.
The firewall update scripts look for tun interfaces to create firewalling rules.
In the case of slow vpn startup for some reason, the tun interface could not be up yet, and firewall rules be applied … without the proper pass all rules on tun interfaces.For now I forced tun0 rule creation in the loop - which seems to have fixed the issue (had a reboot due to a major power failure, everything came back up as expected)
-
After the openvpn tunnel comes up, openvpn launches our script that reloads the filter rules, then it notices tun0 and sets everything up.
