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

    OpenVPN client cannot ping LAN from VPN subnet

    OpenVPN
    2
    5
    5.5k
    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

      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

        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

          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

            
            [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

              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
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.