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

    LAN computers can't reach computers behind OpenVPN Server

    Scheduled Pinned Locked Moved OpenVPN
    20 Posts 8 Posters 20.4k 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.
    • B
      Briantist
      last edited by

      @lufu:

      Hello Briantist,

      1. Is the OpenVPN server pfSense or something else?
      It is a OpenSuse Box runnig an OpenVPN Server

      2. Can LAN clients (B) ping LAN clients (A)?
      no they can't. And i would like to keep it that way.
      But i can Ping the IP that the OpenVPN Server has assigned to my pfSense box from LAN B.

      3. Post at least your OpenVPN client config, and if possible, the server config too.
      Authentication method: PKI

      
      client
      dev tun
      proto udp
      remote xx.xx.xx.xx 1194
      resolv-retry infinite
      nobind
      persist-key
      persist-tun
      ca ca.crt
      cert test.crt
      key test.key
      cipher AES-256-CBC
      comp-lzo
      auth SHA1
      
      

      My Goal is that CLients on LAN A can Access Lan Clients B, but LAN Clients B shouldn't be able to have access to the Clients on LAN A.

      LAN A
      192.168.0.0/24
      LAN B
      192.168.200.0/24
      OenVPN LAN
      192.168.1.0/24

      My pfSense Box has got the IP Addresses 192.168.0.50 (LAN A Subnet) and 192.168.1.2 (OpenVPN Subnet) and the OPEN VPN Server 192.168.1.1 (OpenVPN Subnet)

      Let's say i would send a Ping fron LAN A to LAN B.
      1. LAN A Client 192.168.0.10 sends the Ping request to his Gateway 192.168.0.50(pfSense).
      2. Now the pfSense box should send the request via his OpenVPN Subnet IP 192.168.1.2
      3. The Client on LAN B recieves the Ping request and sends the Answer back to the IP 192.168.1.2
      4. Now my pfSense box should route the Ping back to the Client in LAN A.

      Is this possible?

      1. Consider this:  unless you've added a static route to your client on LAN A, it has no idea how to get to LAN B's subnet, so it sends it to its default gateway, which is 192.168.0.50. This is the correct and expected behavior.
      2. It should but if it doesn't have a route that tells it that it can get to LAN B's subnet by using the OVPN subnet, then the packet will not go across the VPN. Let's assume it does have this route.
      3. The client does not send the reply to 192.168.1.2, it sends it to the address of the client on LAN A (192.168.0.X), and it since it has no route to it, it sends it back to its default gateway, 192.168.200.1(?). If that machine has no route to get to 192.168.0.X, then the reply will never reach you even if the original echo request packet got through.
      4. If you get to this point, then yes that is what will happen.

      Focus on 2 and 3. Look at the routing tables on both your pfSense box and on your OpenSUSE box. I see a distinct lack of a route command within your OpenVPN client config. I don't even see the ifconfig directive unless you left it our on purpose. Anyway, in the client you should have something like:

      route 192.168.200.0 255.255.255.0

      The server would have something like:

      route 192.168.0.0 255.255.255.0

      I know you desire not to have LAN B be able to ping LAN A, but you can't do that correctly with routing. You would have to have a firewall blocking the traffic (currently it's kind of buggy to filter an OpenVPN interface in pfSense and it only works in 1.2.3; see other posts for info). First get it working where the traffic flows through; you can try to worry about blocking LAN B after that.

      1 Reply Last reply Reply Quote 0
      • G
        gds
        last edited by

        I think lufu and I want to do the same thing and as I mentioned in my posts above it IS possible to connect to a remote OpenVPN server
        without having to explicitly specify routes on the client.
        On my DD-WRT box this works out-of-the-box (and it even works as lufu wants it to: local LAN (openvpn client) can connect to remote LAN (openvpn server))

        The only issue I'm having is that I need to masquerade the ip addresses of the local clients, otherwise the server will drop the packages.
        But I have no clue how to do this in pfSense.

        So any help on this would be greatly appreciated.

        1 Reply Last reply Reply Quote 0
        • GruensFroeschliG
          GruensFroeschli
          last edited by

          @gds:

          I think lufu and I want to do the same thing and as I mentioned in my posts above it IS possible to connect to a remote OpenVPN server
          without having to explicitly specify routes on the client.
          On my DD-WRT box this works out-of-the-box (and it even works as lufu wants it to: local LAN (openvpn client) can connect to remote LAN (openvpn server))

          The only issue I'm having is that I need to masquerade the ip addresses of the local clients, otherwise the server will drop the packages.
          But I have no clue how to do this in pfSense.

          So any help on this would be greatly appreciated.

          You dont have to create routes on the clients.
          This is why you should add the commands

          in the client you should have something like:
          route 192.168.200.0 255.255.255.0
          The server would have something like:
          route 192.168.0.0 255.255.255.0

          To the OpenVPN-config, so OpenVPN adds the routes for you.

          I'm not sure how you imagine you would want to access an IP-range without ever telling the router where to send the traffic.
          NAT/masquerade wont help with this. You still need a known destination.

          We do what we must, because we can.

          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

          1 Reply Last reply Reply Quote 0
          • G
            gds
            last edited by

            Sorry, I meant specifying a route option on the client, not creating a route on the client.

            But believe it or not, both DD-WRT and Tomato are able to connect to the openvpn server at the office without having to specify this on the client:

            in the client you should have something like:
            route 192.168.200.0 255.255.255.0
            

            And yes all clients on my home LAN can access the pc's on the corporate LAN through this openvpn tunnel.
            But the pc's on the corporate LAN can't access the pc's on my home LAN (which is what I want)

            So the openvpn server does a "push route", but not the client.

            For completeness, this is the config on the server:

            port 1194
            proto udp
            dev tun
            ca keys/ca.crt
            cert keys/office.crt
            key keys/office.key
            dh keys/dh1024.pem
            server 10.1.10.0 255.255.255.0
            push "route 10.0.10.0 255.255.255.0"
            ifconfig-pool-persist poolpersist.dat
            keepalive 120 900
            comp-lzo
            user nobody
            group nobody
            persist-key
            persist-tun
            status openvpn-status.log
            verb 4
            crl-verify /etc/openvpn/crl/crl.pem
            

            By masquerading the ip's from my home LAN, the openvpn server thinks he is talking to my router/firewall (DD-WRT, Tomato, whatever)
            instead of a client behind it.
            It's my home router/firewall who (should) redirects the received packages to the corresponding client on the LAN.
            Or at least that's my understanding of it.

            But as I said I have no idea how I can set up this masquerading on pfsense.
            Or in other words, how can I specify SNAT rules on pfSense ?

            1 Reply Last reply Reply Quote 0
            • GruensFroeschliG
              GruensFroeschli
              last edited by

              Firewall –> NAT --> Outbound.
              But you can currently only specify "real" interfaces.

              I'm not sure if with the changes to allow firewalling of the OpenVPN interface it's now possible to NAT into the tunnel as well.
              What you can try:

              • Update to a recent 1.2.3
              • Enable OpenVPN filter as described here:
                http://blog.pfsense.org/?p=428

              Disable auto-added VPN rules option - added to System -> Advanced to prevent the addition of auto-added VPN rules for PPTP, IPsec, and OpenVPN tun/tap interfaces. Allows filtering of OpenVPN client-initiated traffic when tun/tap interfaces are assigned as an OPT.

              • Add the OPT interface for OpenVPN.
              • Now enable under Firewall –> NAT --> Outbound "manual outbound NAT" and create a new rule.
              • When you create the new rule you should now be able to select as "interface" the OPT interface which represents the virtual OpenVPN tunnel.

              I dont know if this really works.
              In current versions it's not possible to select the OpenVPN interface for manual NAT.
              But worth a try ;)

              We do what we must, because we can.

              Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

              1 Reply Last reply Reply Quote 0
              • G
                gds
                last edited by

                That's what I was afraid for, no SNAT'ing on the vpn interface.

                Thanks for the tip on trying v1.2.3, but how stable is this v1.2.3 ?
                I already switched my entire LAN to pfSense, so I don't want to take any unnecessary risks by upgrading
                to an unstable version and/or creating some experimental rules ;)

                1 Reply Last reply Reply Quote 0
                • GruensFroeschliG
                  GruensFroeschli
                  last edited by

                  1.2.3 is currently an RC.
                  Most people can run the RCs with absolutely no problems.

                  @http://forum.pfsense.org/index.php/topic:

                  Usually the best thing is to watch http://redmine.pfsense.org and http://rcs.pfsense.org if you want to watch things in detail.

                  Interresting to look:
                  https://rcs.pfsense.org/projects/pfsense
                  https://rcs.pfsense.org/projects/pfsense/repos/mainline/logs/RELENG_1_2

                  We do what we must, because we can.

                  Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

                  1 Reply Last reply Reply Quote 0
                  • G
                    gds
                    last edited by

                    thanks for the pointers.

                    I'm still undecided, but probably I'll set up a vmware image with the latest v1.2.3 and use that as a testing platform for the openvpn stuff…

                    1 Reply Last reply Reply Quote 0
                    • G
                      gds
                      last edited by

                      Don't know why I didn't found this before, but I just stumbled upon this post, which describes a temporary workaround (see edit at the end):
                      http://forum.pfsense.org/index.php/topic,6341.msg36590.html#msg36590

                      Adding that rule after having established the openvpn connection does make it work,
                      but as soon as you reboot or even restart the openvpn connection, the rule is gone again.

                      Therefore I opened the file /etc/inc/filter.inc in an editor and added the following 2 lines at the end of the function "filter_nat_rules_generate()":

                      $natrules .= "\n# Custom NAT rule required for OpenVPN client connection\n";
                      $natrules .= "nat on tun0 from 192.168.1.0/24 to any -> (tun0)\n";
                      
                      

                      I know this is probably not supported  ::) , but it does seem to do the job for now…  8)

                      1 Reply Last reply Reply Quote 0
                      • E
                        ermax
                        last edited by

                        @gds:

                        Don't know why I didn't found this before, but I just stumbled upon this post, which describes a temporary workaround (see edit at the end):
                        http://forum.pfsense.org/index.php/topic,6341.msg36590.html#msg36590

                        Adding that rule after having established the openvpn connection does make it work,
                        but as soon as you reboot or even restart the openvpn connection, the rule is gone again.

                        Therefore I opened the file /etc/inc/filter.inc in an editor and added the following 2 lines at the end of the function "filter_nat_rules_generate()":

                        $natrules .= "\n# Custom NAT rule required for OpenVPN client connection\n";
                        $natrules .= "nat on tun0 from 192.168.1.0/24 to any -> (tun0)\n";
                        
                        

                        I know this is probably not supported  ::) , but it does seem to do the job for now…  8)

                        I don't see this function in /etc/inc/filter.inc running 1.2.3-RC1. I also need NAT on tun0. I need a way to automatically add this rule. Why did they bother putting an OpenVPN client in pfSense if they weren't going to run NAT on it?

                        1 Reply Last reply Reply Quote 0
                        • E
                          ermax
                          last edited by

                          Okay, Reply #13 was very helpful. I added tun0 as OPT1 and then added an outbound NAT entry and now LAN traffic is able to go out the OpenVPN client.

                          Thanks GruensFroeschli for that tip.

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