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

    Can't get OpenVPN client to work

    Scheduled Pinned Locked Moved OpenVPN
    12 Posts 2 Posters 1.5k 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.
    • V
      viragomann @wrobelda
      last edited by

      @kultigsptrizigfrisch said in Can't get OpenVPN client to work:

      So the client on my end clearly sets up a route to 10.90.0.1:
      /sbin/route add -net 10.90.0.1 10.90.0.9 255.255.255.255

      If you want to avoid this check "Don't pull routes" in the client settings.

      @kultigsptrizigfrisch said in Can't get OpenVPN client to work:

      I re-enabled route creation on the interface and what now happens is:

      I can see traffic on on VPN_NJ interface, but it is one direction only, e.g:

      11:49:07.564943 IP 10.90.0.6.62126 > 64.6.65.6.53: 18780+ A? app-measurement.com. (37)

      I suppose this is NAT-related.

      The NAT is working on your site as the tcpdump is showing.

      Possibly the remote site is miss-configured. What is it, a VPN provider?

      Consider that the policy routing rule directs any traffic coming in on LAN to the VPN server. Hence you are not able to access any local IP.
      This means, DNS on LAN devices will not work if they are configured to use an internal DNS server like pfSense.
      You to add an additional firewall rule to the top of the LAN rule set to allow access to DNS or other internal IPs.

      W 1 Reply Last reply Reply Quote 0
      • W
        wrobelda @viragomann
        last edited by wrobelda

        @viragomann said in Can't get OpenVPN client to work:

        So the client on my end clearly sets up a route to 10.90.0.1:
        /sbin/route add -net 10.90.0.1 10.90.0.9 255.255.255.255

        If you want to avoid this check "Don't pull routes" in the client settings.

        Sorry, should have made it more clear: I see those routes in my laptop's OpenVPN client. I had "Don't pull routes" in pfSense before, but with that I saw no traffic on the interface at all. I only see the traffic on the interface after disabling that option, i.e. pulling in the routes.

        The NAT is working on your site as the tcpdump is showing.

        Possibly the remote site is miss-configured. What is it, a VPN provider?
        Yes, it is a VPN provider.

        Consider that the policy routing rule directs any traffic coming in on LAN to the VPN server. Hence you are not able to access any local IP.

        I am not able to access Internet IP. LAN works fine. That is, again, with pulling in of the OpenVPN routes enabled. The traffic on the OpenVPN interface is one-direction only, which is why I concluded that something was still wrong with NAT or routing.

        This means, DNS on LAN devices will not work if they are configured to use an internal DNS server like pfSense.

        Let's forget about DNS resolution for now, not even 1.1.1.1 works. Literally nothing.

        You to add an additional firewall rule to the top of the LAN rule set to allow access to DNS or other internal IPs.

        V 1 Reply Last reply Reply Quote 0
        • V
          viragomann @wrobelda
          last edited by

          @kultigsptrizigfrisch said in Can't get OpenVPN client to work:

          Sorry, should have made it more clear: I see those routes in my laptop's OpenVPN client.

          So not clear what you're talking about here. A VPN provider, your laptop connected to the provider directly, or pfSense?

          W 1 Reply Last reply Reply Quote 0
          • W
            wrobelda @viragomann
            last edited by wrobelda

            @viragomann said in Can't get OpenVPN client to work:

            @kultigsptrizigfrisch said in Can't get OpenVPN client to work:

            Sorry, should have made it more clear: I see those routes in my laptop's OpenVPN client.

            So not clear what you're talking about here. A VPN provider, your laptop connected to the provider directly, or pfSense?

            I used an OpenVPN client on my laptop purely for debugging, to make sure that the VPN provider and the service is functional at all. Then I looked into its logs to see what was going on and saw that the upstream server pushes the 10.90.0.1 route.

            W 1 Reply Last reply Reply Quote 0
            • W
              wrobelda @wrobelda
              last edited by

              I tested one more thing: I re-enabled pulling of the routes and tested the VPN connectivity from pfSense shell with

              curl https://www.myip.com
              

              It works just fine, I can see the IP address is as expected. So the VPN connection itself works without issues, it must be the routing and/or NATting that are somehow misconfigured that I can't get the selective routing working for LAN clients.

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @wrobelda
                last edited by

                @kultigsptrizigfrisch
                You have only one NAT rule that applies to any IPv4 traffic. If this one is working from pfSense itself, it should also work for networks behind.
                Also you filter rule is applied the any IPv4 traffic. The only thing to consider here is if you have a Quick floating rule, which could match the LAN traffic.

                So you intend to direct the whole (for now) IPv4 traffic to a VPN provider and you are testing this on your laptop which is connected to LAN as I got it. It doesn't work even if you have NO VPN up on the laptop?
                Maybe something wrong on the laptop. So please post its routing table.

                W 1 Reply Last reply Reply Quote 0
                • W
                  wrobelda @viragomann
                  last edited by wrobelda

                  @viragomann said in Can't get OpenVPN client to work:

                  @kultigsptrizigfrisch
                  You have only one NAT rule that applies to any IPv4 traffic. If this one is working from pfSense itself, it should also work for networks behind.

                  I actually previously updated that rule to only apply to OpenVPN interface, so it's not that. It works from pfSense only when I have openvpn configured to set up the routes – but then I get no LAN to Internet traffic at all, although I see it on the OpenVPN interface, which is why I assume there's something broken with NAT or routing.

                  Also you filter rule is applied the any IPv4 traffic. The only thing to consider here is if you have a Quick floating rule, which could match the LAN traffic.

                  Just a single QoS rule there, nothing of interest:
                  Screen Shot 2022-02-04 at 3.46.58 PM.png

                  So you intend to direct the whole (for now) IPv4 traffic to a VPN provider

                  Yes

                  and you are testing this on your laptop which is connected to LAN as I got it.

                  Yes, but also on other devices – to same results, so nothing specific to my laptop.

                  Let me try to clear one thing up once again: With the pulling of the routes disabled, and the firewall rules configured as instructed and on the screenshots above, which basically dictate to rule all the LAN traffic via the OpenVPN gateway, LAN traffic to the Internet does work – except that traffic is not routed via the OpenVPN and still goes through the main WAN connection. This is the weirdest part, since it appears to be ignoring that rule altogether, or that the gateway that pfSense sets up implicitly is somehow misconfigured. With route pulling enabled, I get the traffic from pfSense itself to route over OpenVPN, but otherwise get no traffic to the Internet on LAN clients.

                  1 Reply Last reply Reply Quote 0
                  • W
                    wrobelda
                    last edited by wrobelda

                    Does anyone have any other idea on how to debug this? Essentially my Firewall LAN pass rule, configured to use OpenVPN gateway is ignored, such that the traffic is still routed through the WAN gateway. What to check here?

                    EDIT: Updated to 2.6.0 today, didn't change anything.

                    W 1 Reply Last reply Reply Quote 0
                    • W
                      wrobelda @wrobelda
                      last edited by

                      Replying myself, again:

                      I realized there is a Gateway Status page in Diagnostics, and in there I see the OpenVPN gateway marked as:
                      Offline, Packetloss: 100%

                      So at this point I am assuming there's something wrong with the Gateway creation.

                      V 1 Reply Last reply Reply Quote 0
                      • V
                        viragomann @wrobelda
                        last edited by

                        @kultigsptrizigfrisch
                        Yeah, if the VPN gateway is offline, the packets are sent out by the default gateway.
                        You can change this behavior by checking System > Advanced > Miscellaneous > Skip rules when gateway is down.

                        Gateway offline basically means that pfSense cannot ping the monitoring IP. The default monitoring IP is the virtual VPN IP of the remote endpoint.
                        That does not necessarily mean that the VPN is not working, just the remote endpoint does not respond to ping.

                        You can set another monitoring IP, which is reachable over the VPN and is responding, or you can disable monitoring if you don't need it in System > Routing > Gateways.

                        1 Reply Last reply Reply Quote 1
                        • W
                          wrobelda
                          last edited by

                          @viragomann Thanks. Came here to report the final solution and I see you had answered with the same. The issue was that the default gateway was not responding to ICMP. Changing the monitoring IP to something else had immediately brought the Gateway up, and the routing now works as expected.

                          This took way longer than it should :o

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