Navigation

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

    OpenVPN tunnel network overlapping LAN network

    OpenVPN
    3
    14
    95
    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.
    • H
      henrymatthews97 last edited by

      Hi.
      My pfSense LAN network is 10.20.47.0/24
      The VPN provider I use as OpenVPN Client (to Policy Route traffic with Firewall Rules) is using random /16 tunnel networks out of the 10.0.0.0/9 range.
      So sometimes after reconnecting I get 10.20.0.0/16 as tunnel network and now it is overlapping my LAN range.
      Could that lead into any problems?

      Thanks.

      JKnott bingo600 2 Replies Last reply Reply Quote 0
      • JKnott
        JKnott @henrymatthews97 last edited by

        @henrymatthews97
        Yes. Since they give you random addresses in 10.0.0.0, put your LAN in one of the other RFC1918 ranges.

        1 Reply Last reply Reply Quote 0
        • H
          henrymatthews97 last edited by

          Thanks for your answer.
          There is really no way without changing my LAN network?
          What I really don't understand...when they assign me 10.20.0.0/16 everything seems working fine? The OpenVPN gateway stays online and I can policy route traffic out the VPN?!

          JKnott bingo600 2 Replies Last reply Reply Quote 0
          • JKnott
            JKnott @henrymatthews97 last edited by

            @henrymatthews97

            There are 256 subnets in 10.0.0.0 /16. So you have a 1 in 256 chance of being on the same subnet as the VPN. Most of the time you're fine, but on that one time when you're on the same subnet it will fail. The easiest way to deal with this problem is to avoid it, by not using something in 10.0.0.0 for your LAN.

            1 Reply Last reply Reply Quote 0
            • bingo600
              bingo600 @henrymatthews97 last edited by

              @henrymatthews97 said in OpenVPN tunnel network overlapping LAN network:

              Thanks for your answer.
              There is really no way without changing my LAN network?
              What I really don't understand...when they assign me 10.20.0.0/16 everything seems working fine? The OpenVPN gateway stays online and I can policy route traffic out the VPN?!

              Your 10.20.47.0/24 is more specific than the 10.20.0.0/16 , and will have precedence

              /Bingo

              1 Reply Last reply Reply Quote 0
              • H
                henrymatthews97 last edited by

                So there is only a problem if they assign 10.20.47.x/16 to me?
                I need to recheck. Mostly I have seen 10.20.0.x/16, for example 10.20.0.3/16 or 10.20.0.5/16

                bingo600 1 Reply Last reply Reply Quote 0
                • bingo600
                  bingo600 @henrymatthews97 last edited by bingo600

                  @henrymatthews97 said in OpenVPN tunnel network overlapping LAN network:

                  So there is only a problem if they assign 10.20.47.x/16 to me?
                  I need to recheck. Mostly I have seen 10.20.0.x/16, for example 10.20.0.3/16 or 10.20.0.5/16

                  A /24 beats any /16 ... More specific

                  10.20.0.x/16 actually covers 10.20.47.x , but the /24 (defined by pfSense IF) in the route table wins

                  JKnott 1 Reply Last reply Reply Quote 0
                  • H
                    henrymatthews97 last edited by

                    Okay, say they would assign me 10.20.47.3/16 as tunnel network IP.
                    It would break my OpenVPN connectivity but the LAN network would be fine?

                    bingo600 1 Reply Last reply Reply Quote 0
                    • bingo600
                      bingo600 @henrymatthews97 last edited by

                      @henrymatthews97 said in OpenVPN tunnel network overlapping LAN network:

                      Okay, say they would assign me 10.20.47.3/16 as tunnel network IP.
                      It would break my OpenVPN connectivity but the LAN network would be fine?

                      Yup ...
                      That would be an issue , as pfSense packets to 10.20.47.3 would go to the local lan .. No route beats a "Connected network"

                      1 Reply Last reply Reply Quote 0
                      • JKnott
                        JKnott @bingo600 last edited by

                        @bingo600 said in OpenVPN tunnel network overlapping LAN network:

                        10.20.0.x/16 actually covers 10.20.47.x , but the /24 (defined by pfSense IF) in the route table wins

                        Traffic for the local LAN won't even hit the routing table. The transmitting device will look at the interface address, destination address & subnet mask to determine that it's on the local LAN and then send directly to the destination MAC. What happens if the destination is through the VPN, but has an address that would normally be on the LAN? An arp request will be made, get no response and the connection will then fail or it may connect to a device on the LAN, rather than through the VPN.

                        The way to deal with this problem is to avoid it entirely, by using a different RFC1918 address block, as I mentioned above. Any other "solution" is nonsense.

                        1 Reply Last reply Reply Quote 0
                        • bingo600
                          bingo600 @henrymatthews97 last edited by bingo600

                          @henrymatthews97 said in OpenVPN tunnel network overlapping LAN network:

                          e 10.0.0.0/9 range.

                          If they use 10.0.0.0/9 you could put your lan in the "high half" of the /8

                          JKnott 1 Reply Last reply Reply Quote 0
                          • JKnott
                            JKnott @bingo600 last edited by

                            @bingo600

                            If they are in fact using /9 and not /8, then use the other half. Regardless, it's still best to use different addresses. What happens if the ISP decides to go with /8? I have done a lot of networking in business environments. I have learned there are commonly used subnets, which should be avoided to prevent collisions. That includes 10. and 192.168 subnets. So, I put my networks on 172.16 to avoid problems.

                            BTW, this is just one example of many as to why we should move entirely to IPv6. These sorts of problems are caused entirely by using NAT to share addresses. Even with IPv6 Unique Local Addresses, the equivalent of IPv4 RFC1918, you're supposed to use a random number, out of a huge range, to select the ULA prefix. This is on top of the unbelievably huge Global Unique Address block, which eliminates the need for NAT. There are enough GUA addresses for every person on earth to have over 4000 /48 prefixes. That's 4000 x 2^72 or 4.72236648287e+21 addresses each!

                            bingo600 1 Reply Last reply Reply Quote 0
                            • H
                              henrymatthews97 last edited by

                              I was afraid that the best option is to put my LAN in another range, but this would be a lot of work for me.
                              I also do not like the idea to have a VPN provider force me to change the range. Say I put my LAN network to 172.20.20.0/24
                              Now in a few months they choose to push 172.20.0.0/16 ... or I use a different VPN provider and they use 172.20.0.0/16 as tunnel net maybe.
                              Weird they push big ranges like /16 anyway....

                              1 Reply Last reply Reply Quote 0
                              • bingo600
                                bingo600 @JKnott last edited by bingo600

                                @jknott said in OpenVPN tunnel network overlapping LAN network:

                                @bingo600

                                If they are in fact using /9 and not /8, then use the other half. Regardless, it's still best to use different addresses. What happens if the ISP decides to go with /8? I have done a lot of networking in business environments. I have learned there are commonly used subnets, which should be avoided to prevent collisions. That includes 10. and 192.168 subnets. So, I put my networks on 172.16 to avoid problems.

                                IMHO that's pure lottery
                                I have been using 172.16.x.x/12 ranges lots of times too.

                                The OP mentioned 10.0.0.0/9 , not me

                                I think i see something similar w. my ExpressVPN aka. they use RFC1918 for link addresses.

                                Here's a "snip" from a DEB10 VM , that is connected via them.

                                vpn-01:~$ sudo route 
                                Kernel IP routing table
                                Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
                                ...SNIP...
                                0.0.0.0         10.141.0.35     128.0.0.0       UG    0      0        0 tun0
                                default         10.xxx.zzz.1    0.0.0.0         UG    0      0        0 ens192
                                10.141.0.1      10.141.0.35     255.255.255.255 UGH   0      0        0 tun0
                                10.141.0.35     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
                                85.www.22.65    10.xxx.zzz.1    255.255.255.255 UGH   0      0        0 ens192
                                128.0.0.0       10.141.0.35     128.0.0.0       UG    0      0        0 tun0
                                ...SNIP...
                                vpn-01:~$
                                
                                

                                IMHO the OP could just as well use the high 10.x.x.x/9

                                Or take the chance with the existing network, until proven otherwise.

                                Btw: Neat trick with the 0.0.0.0/1

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post

                                Products

                                • Platform Overview
                                • TNSR
                                • pfSense
                                • Appliances

                                Services

                                • Training
                                • Professional Services

                                Support

                                • Subscription Plans
                                • Contact Support
                                • Product Lifecycle
                                • Documentation

                                News

                                • Media Coverage
                                • Press
                                • Events

                                Resources

                                • Blog
                                • FAQ
                                • Find a Partner
                                • Resource Library
                                • Security Information

                                Company

                                • About Us
                                • Careers
                                • Partners
                                • Contact Us
                                • Legal
                                Our Mission

                                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                Subscribe to our Newsletter

                                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                © 2021 Rubicon Communications, LLC | Privacy Policy