Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Openvpn issues since 1.0RC3

    OpenVPN
    5
    8
    4930
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      MathieuMa last edited by

      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 Completed

      NB : forgot to dump pf rules before and after the restart - wanted to bring the link back up fast … next time :)

      1 Reply Last reply Reply Quote 0
      • H
        hoba last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • JeGr
          JeGr LAYER 8 Moderator last edited by

          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 :)

          Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

          If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

          1 Reply Last reply Reply Quote 0
          • M
            MathieuMa last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • T
              trendchiller last edited by

              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...

              1 Reply Last reply Reply Quote 0
              • M
                MathieuMa last edited by

                @trendchiller:

                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)

                1 Reply Last reply Reply Quote 0
                • M
                  MathieuMa last edited by

                  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)

                  1 Reply Last reply Reply Quote 0
                  • S
                    sullrich last edited by

                    After the openvpn tunnel comes up, openvpn launches our script that reloads the filter rules, then it notices tun0 and sets everything up.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post