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

    Fresh install of 2.0.1 from 1.2.3 - OpenVPN clients can't pass traffic to LAN

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 6 Posters 3.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.
    • J
      jhboricua
      last edited by

      Just upgraded my Alix embedded unit to 2.0.1. It was previously running 1.2.3 without issues. I didn't go the 'upgrade path'. Rather, I did a full install of 2.0.1 and recreated my configuration from scratch using screenshots I've had taken from my 1.2.3 setup and text captures of my OpenVPN server setup.

      My pfsense box IS the gateway on my home network, I'll get that out of the way right now.

      My problem is that after setting up the OpenVPN server back up, using the same CA and Server Cert and settings as it was on 1.2.3, my OPVPN clients are able to connect no problem, but I can't pass traffic to anything on my home network.

      My interfaces are as follows:

      WAN: static public IP
      LAN: 192.168.10.0/24
      OpenVPN network: 192.168.11.0/24

      My OPVPN client machine connects without errors on the openvpn client logs. The routes for the 192.168.10.0 and 192.168.11.0 get added to it just as before the 2.0.1 install.

      Pings to anything in the 192.168.10.0 network time out.

      Pings to the OpenVPN server interface (192.168.11.1) time out

      Pings to the OpenVPN client interface - good.

      The default allow rule on the OpenVPN interface to any is present on the pfsense router.

      The default allow rule on the LAN interface to any is present on the pfsense router.

      Running wireshark on a windows server inside my home network and trying to ping from my OpenVPN client while its connected revealed no packets hitting the windows server.

      Doing a packet capture on the OpenVPN interface from pfsense produced no output.

      Removed the allow all rule on the OpenVPN interface and went to check the logs while trying to connect from a vpn client to an internal device. The logs don't show anything being blocked from the openvpn interface.

      Remember this vpn client was not altered and it was connecting fine when the Alix was running 1.2.3

      As a last resort, wiped OpenVPN server config and the imported certs on my pfsense box and created a new CA cert and Server cert from scratch and a new OpenVPN config from scratch. Exported client settings to my vpn client machine and tried connecting.  Same behavior, client connects with no errors, traffic to home LAN network doesn't reach destination.

      Not sure where to go from here and not finding much hint on other threads I've searched. This should be pretty straightforward. Any help is appreciated.

      1 Reply Last reply Reply Quote 0
      • P
        podilarius
        last edited by

        If you create a OpenVPN rule or any rules you will notice that the protocol defaults to TCP. If you are trying only to ping, it might be working and you are just blocking ping. So, when you created the rule, did you change the protocol? If not, are you testing any other TCP based protocol?
        Check the machine that you are using to connect with. Is it in the same network or include the same subnet as you home LAN?

        It seems like everything else is okay since you are able to create the VPN tunnel.

        1 Reply Last reply Reply Quote 0
        • M
          marvosa
          last edited by

          Sounds like a routing issue.  A few things:

          1.  On your openvpn server, what do you have entered (and/or checked) under tunnel settings, client settings and advanced configuration?

          2.  Post the ovpn log from the client side from the connection.

          3.  Post the routing table from the client when you're connected.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            there is also a bug in the 2.0 and 2.0.1 upgrade code for OpenVPN - if you did not have compression enabled before, it would show enabled after the upgrade. Disable compression, save, and reconnect.

            Compression being mismatched isn't enough for the connection to fail, but it will stop traffic from being passed.

            [Even if you re-create it by hand it would be easy to miss]

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • F
              fisher64
              last edited by

              While we wait for him to give us more information, may I offer a link to this thread? I believe I have the exact same issue, and I posted screenshots of the settings as they are in 1.2.3 and 2.0.1.

              http://forum.pfsense.org/index.php/topic,46096.0.html

              EDIT: Never mind, I solved it.

              1 Reply Last reply Reply Quote 0
              • D
                Darkk
                last edited by

                @jimp:

                there is also a bug in the 2.0 and 2.0.1 upgrade code for OpenVPN - if you did not have compression enabled before, it would show enabled after the upgrade. Disable compression, save, and reconnect.

                Compression being mismatched isn't enough for the connection to fail, but it will stop traffic from being passed.

                [Even if you re-create it by hand it would be easy to miss]

                Thank you!!! Took me several tries to get this stupid traffic pass working.  I togged the compression setting and volia it worked.

                Now everything is working like it should.

                Darkk

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