• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Dec 16, 2015, 10:25 AM Dec 14, 2015, 12:47 PM

    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 Dec 14, 2015, 5:03 PM

      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 Dec 15, 2015, 12:30 AM

        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 Dec 15, 2015, 11:47 AM

          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
          4 out of 4
          • First post
            4/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received