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

OpenVPN client cannot ping LAN from VPN subnet

Scheduled Pinned Locked Moved OpenVPN
5 Posts 2 Posters 5.6k 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.
  • D
    dougs
    last edited by Feb 28, 2013, 12:20 AM

    Hello-

    I'm new to pfsense thus this message. I've operated OpenVPN on a linux router for at least ten years so it's a challenge adapting to pfsense's OpenVPN methodology!  :)

    I've set up keys the way they should be and can accomplish a successful handshake between a Windows 7 client and the OpenVPN server running on pfsense. However, I cannot get past the pfsense router. I can ping pfsense but nothing out in the LAN. The docs says that routing is automatically added by pfsense when an OpenVPN server is set up in pfsense version 2.0.x. Is that true?

    If so, what am I doing wrong? I've added a rule in the OVPN tab allowing TCP/UDP/ICMP traffic inbound into the OpenVPN interface as follows:

    pass in quick on openvpn proto tcp all flags S/SA keep state label "USER_RULE: allow TCP/UDP traffic into VPN tunnel"
    pass in quick on openvpn proto udp all keep state label "USER_RULE: allow TCP/UDP traffic into VPN tunnel"
    pass in quick on openvpn inet proto icmp all keep state label "USER_RULE: allow ICMP traffic into VPN tunnel"
    pass in quick on openvpn inet from any to 192.168.101.0/24 flags S/SA keep state label "USER_RULE"

    Do I need to add rules elsewhere?

    If pfsense doesn't automatically add routing, what steps do I need to allow clients into the LAN?

    ~Doug

    1 Reply Last reply Reply Quote 0
    • ?
      A Former User
      last edited by Feb 28, 2013, 12:25 AM

      Go to the OpenVPN Server Settings and add this:

      Advanced configuration:

      push "route 192.168.101.0 255.255.255.0";

      fixed this issue for me.

      1 Reply Last reply Reply Quote 0
      • D
        dougs
        last edited by Feb 28, 2013, 1:32 AM

        Umm.

        Now I cannot seem to do a proper handshake anymore. I do seem to get an initial packet from [AF_INET]<wan address="">:1194 but then it times out after 60 secs. The server openvpn.log is filled with "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

        Now I see that the WAN card seems to ahve issues. For example I cannot ping www.google.com successfully. I'm wondering if OpenVPN causes problems with name resolution on the WAn card when a connection is attempted between an OpenVPN client and the server? Has anyone seen this issue before?

        ~Doug</wan>

        1 Reply Last reply Reply Quote 0
        • D
          dougs
          last edited by Feb 28, 2013, 5:30 PM

          
          [2.0.2-RELEASE][admin@pfsense.dawnsign.com]/root(13): /etc/rc.banner ; ifconfig ; ping -c 3 8.8.8.8 ; ping -c 3 www.google.com ; netstat -r -n
          *** Welcome to pfSense 2.0.2-RELEASE-pfSense (i386) on pfsense ***
          
            WAN (wan)                 -> vx0        -> 69.xxx.xxx.xxx 
            LAN (lan)                 -> fxp0       -> 192.168.101.253 
            OPT1 (opt1)               -> xl0        -> NONE 
          
          vx0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                  ether 00:a0:24:78:61:ce
                  inet6 fe80::2a0:24ff:fe78:61ce%vx0 prefixlen 64 scopeid 0x1 
                  inet 69.xxx.xxx.xxx netmask 0xfffffff0 broadcast 69.198.101.223
                  nd6 options=43 <performnud,accept_rtadv>xl0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                  options=80009 <rxcsum,vlan_mtu,linkstate>ether 00:10:5a:85:91:11
                  inet6 fe80::210:5aff:fe85:9111%xl0 prefixlen 64 scopeid 0x2 
                  nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
                  status: active
          fxp0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                  options=2049 <rxcsum,vlan_mtu,polling,wol_magic>ether 00:1c:c0:75:5c:26
                  inet6 fe80::21c:c0ff:fe75:5c26%fxp0 prefixlen 64 scopeid 0x3 
                  inet 192.168.101.253 netmask 0xffffff00 broadcast 192.168.101.255
                  nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
                  status: active
          pfsync0: flags=0<> metric 0 mtu 1460
                  syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
          pflog0: flags=100 <promisc>metric 0 mtu 33200
          enc0: flags=0<> metric 0 mtu 1536
          lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
                  options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000 
                  inet6 ::1 prefixlen 128 
                  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 
                  nd6 options=43 <performnud,accept_rtadv>PING 8.8.8.8 (8.8.8.8): 56 data bytes
          
          --- 8.8.8.8 ping statistics ---
          3 packets transmitted, 0 packets received, 100.0% packet loss
          PING www.google.com (74.125.239.20): 56 data bytes
          
          --- www.google.com ping statistics ---
          3 packets transmitted, 0 packets received, 100.0% packet loss
          Routing tables
          
          Internet:
          Destination        Gateway            Flags    Refs      Use  Netif Expire
          default            69.198.101.209     UGS         0      118    vx0
          69.xxx.xxx.xxx/28  link#1             U           0      415    vx0
          69.xxx.xxx.xxx     link#1             UHS         0        0    lo0
          127.0.0.1          link#7             UH          0       75    lo0
          192.168.101.0/24   link#3             U           0      535   fxp0
          192.168.101.253    link#3             UHS         0        0    lo0
          208.67.220.220     69.198.101.209     UGHS        0       16    vx0
          208.67.222.222     69.198.101.209     UGHS        0       16    vx0
          
          Internet6:
          Destination                       Gateway                       Flags      Netif Expire
          ::1                               ::1                           UH          lo0
          fe80::%vx0/64                     link#1                        U           vx0
          fe80::2a0:24ff:fe78:61ce%vx0      link#1                        UHS         lo0
          fe80::%xl0/64                     link#2                        U           xl0
          fe80::210:5aff:fe85:9111%xl0      link#2                        UHS         lo0
          fe80::%fxp0/64                    link#3                        U          fxp0
          fe80::21c:c0ff:fe75:5c26%fxp0     link#3                        UHS         lo0
          fe80::%lo0/64                     link#7                        U           lo0
          fe80::1%lo0                       link#7                        UHS         lo0
          ff01:1::/32                       fe80::2a0:24ff:fe78:61ce%vx0  U           vx0
          ff01:2::/32                       fe80::210:5aff:fe85:9111%xl0  U           xl0
          ff01:3::/32                       fe80::21c:c0ff:fe75:5c26%fxp0 U          fxp0
          ff01:7::/32                       ::1                           U           lo0
          ff02::%vx0/32                     fe80::2a0:24ff:fe78:61ce%vx0  U           vx0
          ff02::%xl0/32                     fe80::210:5aff:fe85:9111%xl0  U           xl0
          ff02::%fxp0/32                    fe80::21c:c0ff:fe75:5c26%fxp0 U          fxp0
          ff02::%lo0/32                     ::1                           U           lo0
          [2.0.2-RELEASE][admin@pfsense.dawnsign.com]/root(14):</performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></promisc></full-duplex></performnud,accept_rtadv></rxcsum,vlan_mtu,polling,wol_magic></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,vlan_mtu,linkstate></up,broadcast,running,simplex,multicast></performnud,accept_rtadv></up,broadcast,running,simplex,multicast> 
          

          I've observed that upon rebooting each time, most times I'm able to ping 8.8.8.8 within 30 seconds and then I'm unable to ping anymore. In very few instances, I cannot even ping successfully upon rebooting.

          I suspected a flaky NIC and replaced a 3Com 509b card with a 3Com 595 card to no effect. I replaced the switch but no dice. It appears that the issue is within pfsense. I disabled pf ('pfctl -d') and still am unable to ping 8.8.8.8 successfully.

          Is pfsense borked? What steps can I take to investigate this further?

          ~Doug

          1 Reply Last reply Reply Quote 0
          • D
            dougs
            last edited by Feb 28, 2013, 6:56 PM

            I restored from a previous backup that didn't contain any configuration information for OpenVPN. Ping now works. And doesn't stop working after 30 seconds of being up. So far so good.

            I imported the pfsense certificate authority certificate and key (ca.crt & ca.key) into the Cert Manager CA Authority tab from our older Linux-based router which used easyrsa to generate those certificates/keys. Then I went to the client certificate tab and imported Firewall.crt & Firewall.key from our Linux-based router to a 'Firewall' certificate entry. I also imported a client certificate and key into a new client certificate entry called DougSampson.

            I went to the OpenVPN configuration and imported the contents of the ta.key into the TLS-Authentication box. For the Peer Certificate Authority I chose the Firewall Certificate Authority certificate (ca.crt in this case) and for the Peer Certificate Revocation List I chose the Firewall Certificate Authority entry (we didn't employ a CRL list on our Linux-based router). For the Server Certificate, I chose the Firewall server certificate (in this case, the Firewall.crt) for the Server Certificate box. I chose 1024 bits for the DH Parameter Length. We had a dh1024.pem file from our Linux-based router but didn't know where to put it- there's no box for selecting the dh1024.pem file. It currently sits in the /root/easyrsa4pfsense/keys folder. POSTSCRIPT: I now notice 'dh /etc/dh-parameters.1024' in server1.conf. Should I replace the contents of that file with the contents from the /root/easyrsa4pfsense/keys/dh1024.pem?

            The contents of server1.conf is as follows:

            
            dev ovpns1
            dev-type tun
            dev-node /dev/tun1
            writepid /var/run/openvpn_server1.pid
            #user nobody
            #group nobody
            script-security 3
            daemon
            keepalive 10 60
            ping-timer-rem
            persist-tun
            persist-key
            proto udp
            cipher BF-CBC
            up /usr/local/sbin/ovpn-linkup
            down /usr/local/sbin/ovpn-linkdown
            local 69.xxx.xxx.xxx
            tls-server
            server 10.0.8.0 255.255.255.0
            client-config-dir /var/etc/openvpn-csc
            tls-verify /var/etc/openvpn/server1.tls-verify.php
            lport 1194
            management /var/etc/openvpn/server1.sock unix
            max-clients 5
            push "route 192.168.101.0 255.255.255.0"
            push "dhcp-option DOMAIN dawnsign.com"
            push "dhcp-option DNS 192.168.101.1"
            push "dhcp-option DNS 192.168.101.4"
            push "dhcp-option DNS 192.168.101.7"
            push "dhcp-option DNS 192.168.101.254"
            push "dhcp-option NTP 192.168.101.254"
            push "dhcp-option NTP 192.168.101.4"
            push "dhcp-option WINS 192.168.101.4"
            client-to-client
            ca /var/etc/openvpn/server1.ca 
            cert /var/etc/openvpn/server1.cert 
            key /var/etc/openvpn/server1.key 
            dh /etc/dh-parameters.1024
            crl-verify /var/etc/openvpn/server1.crl-verify 
            tls-auth /var/etc/openvpn/server1.tls-auth 0
            comp-lzo
            passtos
            persist-remote-ip
            float
            push "route 192.168.102.0 255.255.255.0"
            
            

            Content of client.ovpn:

            
            client
            dev tun
            proto udp
            remote 69.xxx.xxx.xxx 1194
            resolve-retry infinite
            nobind
            persist-key
            persist-tun
            ca ca.crt
            cert DougSampson.crt
            key DougSampson.key
            tls-auth ta.key 1
            comp-lzo
            verb 3
            
            

            The client config file worked just fine with our existing Linux-based router running OpenVPN.

            Now when I try to connect, it fails with a TLS handshake error. Here is what the openvpn.log spits out:

            
            Feb 28 10:07:05 pfsense openvpn[11729]: event_wait : Interrupted system call (code=4)
            Feb 28 10:07:05 pfsense openvpn[11729]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1542 10.0.8.1 10.0.8.2 init
            Feb 28 10:07:05 pfsense openvpn[11729]: SIGTERM[hard,] received, process exiting
            Feb 28 10:07:05 pfsense openvpn[48656]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug  6 2012
            Feb 28 10:07:05 pfsense openvpn[48656]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
            Feb 28 10:07:05 pfsense openvpn[48656]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
            Feb 28 10:07:05 pfsense openvpn[48656]: TUN/TAP device /dev/tun1 opened
            Feb 28 10:07:05 pfsense openvpn[48656]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
            Feb 28 10:07:05 pfsense openvpn[48656]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.255 up
            Feb 28 10:07:05 pfsense openvpn[48656]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1542 10.0.8.1 10.0.8.2 init
            Feb 28 10:07:05 pfsense openvpn[50174]: UDPv4 link local (bound): [AF_INET]69.xxx.xxx.xxx:1194
            Feb 28 10:07:05 pfsense openvpn[50174]: UDPv4 link remote: [undef]
            Feb 28 10:07:05 pfsense openvpn[50174]: Initialization Sequence Completed
            Feb 28 10:08:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 Re-using SSL/TLS context
            Feb 28 10:08:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 LZO compression initialized
            Feb 28 10:09:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
            Feb 28 10:09:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 TLS Error: TLS handshake failed</ovpn></ovpn></ovpn></ovpn> 
            

            Moreover, the pfsense server stops being able to ping! After rebooting, I'm unable to ping at all.

            It looks like there is a misconfiguration error somewhere in there and I cannot figure it out. Can anyone spot any errors? I notice that in the server1.conf file, the cipher is specified but it is not specified in the client config file. Is this an error? Are there any other errors?

            ~Doug

            1 Reply Last reply Reply Quote 0
            5 out of 5
            • First post
              5/5
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
              This community forum collects and processes your personal information.
              consent.not_received