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

    Trouble Getting Traffic from pfsense OpenVPN Client to OpenVPN Server (SOLVED)

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 2 Posters 1.4k Views
    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.
    • R
      ragnor
      last edited by

      I've been running a OpenVPN server on Debian for a while now. No problems. Server config follows.

      port 1194
      proto udp
      dev tun
      ca ca.crt
      cert server.crt
      key server.key
      dh dh.pem
      topology subnet
      server 10.8.0.0 255.255.255.0
      client-config-dir ccd
      keepalive 10 120
      comp-lzo
      persist-key
      persist-tun
      status openvpn-status.log
      verb 3
      crl-verify /etc/openvpn/easy-rsa/pki/crl.pem
      mssfix 1432

      Extract from client config follows.

      client
      dev tun
      proto udp
      remote xxx.xxx.xxx.xxx 1194
      resolv-retry infinite
      nobind
      persist-key
      persist-tun
      remote-cert-tls server
      comp-lzo
      verb 3
      redirect-gateway def1
      dhcp-option DNS xxx.xxx.xxx.xxx
      dhcp-option DNS xxx.xxx.xxx.xxx

      It has worked well for both "on-site" and "off-site" clients passing all Internet traffic through the VPN and out into the wild via the US.

      Our local network was behind a Mac mini running OS X. This routing all local traffic through the VPN. It was a bit of a house of cards but it worked.

      I've dumped OS X for pfsense but am having trouble with OpenVPN. I can setup an OpenVPN client and get it to connect but I cannot for the life of me get traffic to route through it. I've read everything I can and been experimenting for days but no luck. I'm feeling like a bit of an idiot.

      Local subnet is 10.11.12.0/24.

      Attached are screenshots of my client config in pfsense, and NAT & firewall rules.

      The output from the OpenVPN log when restarting follows:

      Dec 14 23:37:06  openvpn[28670]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1541 10.8.0.3 255.255.255.0 init
      Dec 14 23:37:06  openvpn[28670]: SIGTERM[hard,] received, process exiting
      Dec 14 23:37:06  openvpn[11670]: OpenVPN 2.3.8 amd64-portbld-freebsd10.1 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Aug 21 2015
      Dec 14 23:37:06  openvpn[11670]: library versions: OpenSSL 1.0.1l-freebsd 15 Jan 2015, LZO 2.09
      Dec 14 23:37:06  openvpn[11777]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
      Dec 14 23:37:06  openvpn[11777]: Initializing OpenSSL support for engine 'rdrand'
      Dec 14 23:37:06  openvpn[11777]: UDPv4 link local (bound): [AF_INET]xxx.xxx.xxx.xxx
      Dec 14 23:37:06  openvpn[11777]: UDPv4 link remote: [AF_INET]yyy.yyy.yyy.yyy:1194
      Dec 14 23:37:09  openvpn[11777]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1542'
      Dec 14 23:37:09  openvpn[11777]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
      Dec 14 23:37:09  openvpn[11777]: [server] Peer Connection Initiated with [AF_INET]yyy.yyy.yyy.yyy:1194
      Dec 14 23:37:11  openvpn[11777]: TUN/TAP device ovpnc1 exists previously, keep at program end
      Dec 14 23:37:11  openvpn[11777]: TUN/TAP device /dev/tun1 opened
      Dec 14 23:37:11  openvpn[11777]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
      Dec 14 23:37:11  openvpn[11777]: /sbin/ifconfig ovpnc1 10.8.0.3 10.8.0.1 mtu 1500 netmask 255.255.255.0 up
      Dec 14 23:37:11  openvpn[11777]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1541 10.8.0.3 255.255.255.0 init
      Dec 14 23:37:11  openvpn[11777]: Initialization Sequence Completed

      And the routing table.

      default  xxx.xxx.xxx.xxx  UGS  26209  1492  pppoe0
      10.8.0.0/24  10.8.0.3  UGS  0  1500  ovpnc1
      10.8.0.1  link#10  UH  0  1500  ovpnc1
      10.8.0.3  link#10  UHS  324  16384  lo0
      10.11.0.0/16  link#1  U  28090  1500  em0
      10.11.12.1  link#1  UHS  0  16384  lo0
      yyy.yyy.yyy.yyy  link#8  UHS  0  16384  lo0
      127.0.0.1  link#6  UH  52  16384  lo0
      172.16.0.0/30  link#2  U  2035  1500  em1
      172.16.0.2  link#2  UHS  0  16384  lo0
      172.16.1.0/30  link#3  U  2035  1500  em2
      172.16.1.2  link#3  UHS  0  16384  lo0
      xxx.xxx.xxx.xxx  link#8  UH  2040  1492  pppoe0

      I don't think the appropriate route is being setup properly but I don't how or where. If anyone has any idea what I'm missing it'd be very much appreciated. I'm feeling like a real idiot at the moment.  :(
      1.png
      1.png_thumb
      2.png
      2.png_thumb
      3.png
      3.png_thumb
      4.png
      4.png_thumb

      1 Reply Last reply Reply Quote 0
      • D
        divsys
        last edited by

        Do you have an allow any-any rule under the OpenVPN tab?

        Have you tried the typical pings tests - try and reach the Debian OpenVPN server  from the client and vice versa then move outward to LAN devices on each net?

        -jfp

        1 Reply Last reply Reply Quote 0
        • R
          ragnor
          last edited by

          I have solved my problem.

          I had the following warnings in my OpenVPN log.

          WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1542'
          WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lao'

          Fixed up the compression warning, mtu disappeared, and everything is now working.

          1 Reply Last reply Reply Quote 0
          • D
            divsys
            last edited by

            Glad your up and running  :)

            You might want to update the subject of your first message to include  "(SOLVED)".
            It's helpful for people checking in the future.

            -jfp

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.