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

    Client connects, but no access to LAN. Take a peek at my configs? :)

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 3 Posters 6.1k 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
      rokken55
      last edited by

      Hey everyone,

      I've spent a good deal of time on this but am a bit new to pFsense and OpenVPN.  Any help is greatly appreciated.

      I can connect a client to the OpenVPN server, and I can ping the default gateway, but cannot ping or access any other LAN resources.  I have ensured that firewall rules are allowing traffic through the VPN.  Here are my configs:

      Server:
      dev ovpns1
      dev-type tun
      tun-ipv6
      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 AES-256-CBC
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      client-connect /usr/local/sbin/openvpn.attributes.sh
      client-disconnect /usr/local/sbin/openvpn.attributes.sh
      local (our WAN IP is here)
      tls-server
      server 172.16.31.0 255.255.255.0
      client-config-dir /var/etc/openvpn-csc
      username-as-common-name
      auth-user-pass-verify /var/etc/openvpn/server1.php via-env
      tls-verify /var/etc/openvpn/server1.tls-verify.php
      lport 1194
      management /var/etc/openvpn/server1.sock unix
      push "route 172.16.0.0 255.255.0.0"
      push "dhcp-option DOMAIN ourdomain.local"
      push "dhcp-option DNS 172.16.0.2"
      push "dhcp-option DNS 172.16.0.3"
      ca /var/etc/openvpn/server1.ca
      cert /var/etc/openvpn/server1.cert
      key /var/etc/openvpn/server1.key
      dh /etc/dh-parameters.2048
      tls-auth /var/etc/openvpn/server1.tls-auth 0
      comp-lzo
      persist-remote-ip
      float

      Client:
      dev tun
      persist-tun
      persist-key
      cipher AES-256-CBC
      auth SHA1
      tls-client
      client
      resolv-retry infinite
      remote (our WAN IP) 1194 udp
      lport 0
      verify-x509-name "OurServerCert" name
      auth-user-pass
      pkcs12 firewall-udp-1194-testvpnuser.p12
      tls-auth firewall-udp-1194-testvpnuser-tls.key 1
      ns-cert-type server
      comp-lzo

      What am I doing wrong here?

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        That all looks OK. I also use a summarised route in the "Local Network/s" field that points to all my internal network space behind the server, so I believe 172.16.0.0/16 should work OK, even though the tunnel is inside that at 172.16.31.0/24
        I would do "route print" on the (Windows?) client and make sure the 172.16.0.0/16 route is there.
        Then check that the device in the LAN does not have a firewall blocking you (e.g. some Windows firewall settings will allow access by other systems in the same subnet, but not from outside).
        Then start doing packet capture at each point to see where the packets appear and disappear (Diagnostics menu).

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

          Thank you Phil,

          Yes, I am testing this with a Windows client.  I have disabled the Windows firewall for testing purposes.

          A screenshot of the IPV4 routes are attached.  It says that there is a route for 172.16.0.0 but points it to the gateway of 172.16.31.5.  Shouldn't this gateway be the pfsense (172.16.0.1)?

          Also, when you say that you use a summarized route, do you mean that you explicitly define each subnet of your internal network in that field?  EG: 172.16.0.0/16, 172.16.1.0/24, 172.16.2.0/24 et cetera?

          Finally, when I am looking at packet captures on the pfsense side of things, should I be looking at packets coming over the WAN, or the OpenVPN tunnel itself?

          ipv4routes.PNG
          ipv4routes.PNG_thumb

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            The gateway from the client side should be an address at the other end of the tunnel network. You would think 172.16.31.1, but OpenVPN internally chops up the tunnel into /30 pieces (chunks of 4 addresses). The first client gets ".6" and talks back to ".5" like in your route print output.

            By "summarised route" I mean that 172.16.0.0/16 covers all the addresses from 172.16.0.0 to 172.16.255.255 in one go. If you have lots of LAN subnets inside that then it saves you bothering to list them all separately.

            I didn't ask at first - what is your actual LAN subnet/s?
            Because you can't use the whole of 172.16.0.0/16 on LAN then also reuse part of it, 172.16.31.0/24 again as a tunnel network.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

              I see what you mean about the gateway.  I am currently using 172.16.0-30 for our LAN subnets.  So I picked the next in line available for the OpenVPN range.  It shouldn't be conflicting with anything else on the network.

              After running wireshark on the windows client, and packet capture via pfsense for the OpenVPN tunnel and WAN it appears that traffic is flowing through to the LAN okay.  However, when I look at the ARP table on pfsense, it is unaware of the OpenVPN client's IP or MAC.

              Do I need to do something related to Proxy ARP here?

              1 Reply Last reply Reply Quote 0
              • D
                doktornotor Banned
                last edited by

                If you are confused, why don't you simply disable the /30 nonsense? (I don't even know why that topology 30 BS is the default.)

                And no, you do NOT need any proxy ARP or similar nonsense either.

                P.S. Would strongly suggest to move the whole OVPN subnet out of the 172.16/12 range used on LAN. Use 10/8 or 192.168/16 instead.

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

                  Well, that was it.  After switching the OVPN subnet to an arbitrary 192.168.xxx.0/24 subnet the traffic is flowing properly.  Thank you so much for your help.

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