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

    OpenVPN vs. Client LAN

    Scheduled Pinned Locked Moved OpenVPN
    11 Posts 4 Posters 2.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.
    • D
      doktornotor Banned
      last edited by

      @XaserII:

      Is the only way to do this to change for example the pfSense LAN to 192.168.1.3/24 ?

      192.168.1.3/24 is still the same subnet like 192.168.1.0/24.

      1 Reply Last reply Reply Quote 0
      • X
        XaserII
        last edited by

        whups sorry, twister, ofc I meant 192.168.3.1/24

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

          Yes, choose another piece of private address space for pfSense LAN.
          Anybody who installs a system that has any chance of ever needing remote VPN connections coming in, should use "random"  bits of private address space for their LANs…
          In fact, even if you are not going to have VPN coming in, you might want to do VPN out from a client on your pfSense LAN to someone else who has a "default" LAN on 192.168.1.0/24 or 192.168.0.0/24... so you also want to have picked different private address space.
          There has to be some installation default, but IMHO 99% of people should change it.

          10.x.y.0/24
          172.[16-31].y.0/24
          are options away from any of 192.168..

          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
          • X
            XaserII
            last edited by

            Thanks for the answers and sorry for the late reply:

            I divided the class C subnet into 2 subnets, Home-LANs (192.168.0.0 - 192.168.127.254) and Server-LANs (192.168.128.0 - 192.168.254.254).
            Certainly not the best solution for big cooperate VPNs, however sufficient and comfortable for my case.

            ADIT: Another solution would be to use "dirty NAS tricks" as described here:
            http://www.nimlabs.org/dirtynat.html
            http://serverfault.com/questions/548888/connecting-to-a-remote-server-through-a-vpn-when-the-local-network-subnet-addres

            However I still don't have access to Server-Side LAN clients when connected via OpenVPN. I'm going to investigate / research this further.
            In the mean time If you have any hints, please let me know.

            Regards

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

              @XaserII:

              I divided the class C subnet into 2 subnets, Home-LANs (192.168.0.0 - 192.168.127.254) and Server-LANs (192.168.128.0 - 192.168.254.254).

              How many hosts are you having and realistically expecting to have in each of those two subnets :o ???

              1 Reply Last reply Reply Quote 0
              • X
                XaserII
                last edited by

                @doktornotor:

                How many hosts are you having and realistically expecting to have in each of those two subnets :o ???

                Well each LAN won't need need more than a /24 subnet (i.e. in this case the Home-LAN clients will all be in 192.168.1.0/24 and the Server-LAN clients will be in 192.168.128.0/24)

                But I thought it would be nice to split the Class C Subnet exactly in half.

                I also added a few Links for a Dirty NAS Tricks workaround in my previous post.

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

                  I divided the class C subnet into 2 subnets, Home-LANs (192.168.0.0 - 192.168.127.254) and Server-LANs (192.168.128.0 - 192.168.254.254).

                  There is no such thing any more as class A,B.C stuff. You can split your subnets at whatever CIDR bit count you like. According to the addresses you have typed, it seems you have split the whole of 192.168.0.0/16 into 2 /17 pieces.
                  That is (128*256)-2=32766 clients in each subnet.
                  That should be enough for any reasonable corporate subnet! If you have anywhere near that many clients in the same layer 2 broadcast domain, it is going to be swamped with the broadcast traffic.

                  Maybe you don't realise the numbers you have put in?

                  And that has not got you away from 192.168.0.0/24 and 192.168.1.0/24

                  If you really want private subnets with lots of addresses then go to 10 or 172 networks, like:
                  10.42.0.0/16
                  10.43.0.0/16

                  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
                  • D
                    doktornotor Banned
                    last edited by

                    @XaserII:

                    Well each LAN won't need need more than a /24 subnet (i.e. in this case the Home-LAN clients will all be in 192.168.1.0/24 and the Server-LAN clients will be in 192.168.128.0/24)

                    Yes… So, instead you have basically killed OpenVPN for any client that needs to connect remotely from 192.168/16 subnet.

                    1 Reply Last reply Reply Quote 0
                    • X
                      XaserII
                      last edited by

                      @phil.davis:

                      According to the addresses you have typed, it seems you have split the whole of 192.168.0.0/16 into 2 /17 pieces.
                      That is (128*256)-2=32766 clients in each subnet.
                      That should be enough for any reasonable corporate subnet! If you have anywhere near that many clients in the same layer 2 broadcast domain, it is going to be swamped with the broadcast traffic.

                      Maybe you don't realise the numbers you have put in?

                      And that has not got you away from 192.168.0.0/24 and 192.168.1.0/24

                      If you really want private subnets with lots of addresses then go to 10 or 172 networks, like:
                      10.42.0.0/16
                      10.43.0.0/16

                      huh?^^ Yea that's exactly what I did, and I'm totally happy with it^^ as you guys said correctly, VPN doesn't allow the Clients and the Servers subnet to be the same, so you recommended to move the Servers LAN to a different subnet.

                      All I said that is that, from all the possible subnets I could have assigned for the server LAN, I chose to split the 192.168.0.0/16 subnet into two /17 subnets because its nicely symmetric and stuff and assign the server LAN to 192.168.128.0/24. I should emphasize that this is a "virtual boundary", i.e. it does NOT mean that my home LAN is the whole /17 subnet and the server is the whole /17 subnet. They have a /24 subnet each in their respective /17 subnet.
                      It would have sufficed to move the Server LAN to 192.168.2.0/24 or something but this way I know that when I see a IP from the second half of the /16 subnet that this is a Server-Side Client. And I thought that 192.168.2.0/24 was to close to the default 192.168.1.0/24 LAN and might cause collisions when connecting from the Uni, Hotel or other public LAN.

                      So the choice to split the /16 into exactly 2 was completely arbitrary and works and I'm happy with it.

                      The only issue I have left that I still can't access the LAN Clients in the Server 192.168.128.0/24 net when connected via OpenVPN, I'm still investigating this.

                      Yes… So, instead you have basically killed OpenVPN for any client that needs to connect remotely from 192.168/16 subnet.

                      What do you mean by that? AFAIK it will only collide now if the VPN client is in the 192.168.128.0/24 net, which (in my case) is sufficiently unlikely.

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by

                        What you have done is to guarantee an IP space collision with anyone else you have to connect to who happens to be on 192.168.X.X.  This is, essentially, everyone.

                        Want to set up OpenVPN so you can VPN in from the road?  It'll break from any LAN using 192.168.X.X which is, essentially, everywhere.

                        Here are some random suggestions:

                        10.162.93.0
                        172.19.80.0
                        192.168.232.0

                        172.19.80.0 is perfect.  I'd use 172.19.80.0/20.  Give your segments 172.19.80.0/24, 172.19.81.0/24, 172.19.82.0/24 … 172.19.95.0/24

                        ETA: It looks like we're misreading you and you assigned /24s.  You are better off keeping the address space you occupy as small as possible while reasonably anticipating all future needs at the site.  Notice that the scheme I recommend lets you cover the entire network with one route: 172.19.80.0/20, and gives you 16 /24 networks to work with.  The odds of you ever colliding with anyone else (who didn't do something idiotic like use 172.16.0.0/12) are very minimal.  If you think there is no way you'll ever need 16 subnets, by all means allocate out of a /21 or /22.  Or just go from 80 to 81 to 82, etc and it'll get as big as it gets.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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