Navigation

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

    OpenVPN avoiding same subnets

    OpenVPN
    3
    7
    955
    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.
    • E
      Erravandrhel last edited by

      Hello

      I want to connect two customers to my network .

      first have IPsec that works

      my network: 10.10.10.0/24
      customer netowrk 192.168.1.0/24

      second that i want to connect via openVPN

      my network 10.10.20.0/24
      customer network 192.168.1.0/24

      i cant change customers network addresses

      there is the problem with the connection to the networks and now i want to make NAT 1:1 over VPN but i need to know how and on which side i should do it.

      I think it should be done like this:

      on second client side nat 1:1

      for example:

      this subnet 192.168.1.0/24 ->nat->192.168.200.0/24 ->tunel vpn -> 10.10.20.0/24

      unfortunetly there is a problem cause i tried to configure this and it failed.

      firewall is set to alow any any at openvpn and ipsec.

      At logs of VPN i have error: freebsd route add external 1

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

        The first step is to assign an interface to the OpenVPN instance.  That is where the NAT should occur.

        Second is to create a 1:1 NAT for 192.168.200.0/24 on that interface to 192.168.1.0/24.

        To reach the new customer network you would connect to 192.168.200.X.  They will see a connection to 192.168.1.X.

        You should not need to NAT in the other direction or on the other VPN unless for some reason the customers need to communicate directly with each other.

        Those are the admittedly sparse steps but it's all I can do right now.  I'd have to build it myself to give more detail. I can't remember all the steps necessary regarding OpenVPN local and remote networks, etc.  I know that jimp did a gold hangout about 6 months ago that covered this and other OpenVPN NAT topics if you have access.

        Why are your networks (10.10.10.0 and 10.10.20.0) different for each customer?

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

          So i can't use interface OpenVPN and i need to create new interface for example OVPNNAT ?

          Do i need to configure something at the outbound traffic?

          May u tell me what to write directly to the NAT 1:1 config?

          Interface: OVPNNAT

          External Subnet IP: 192.168.200.0/24

          Internal Subnet IP: 192.168.1.0/24

          Destination: tunel network for example 172.29.35.0/24

          So in this config when i will use an address: 192.168.200.12 on my computer (10.10.20.2)i should communicate directly to the 192.168.1.12.

          correct me if im wrong and misunderstand how to configure it.

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

            Search on pfsense openvpn assigned interface

            No, you can't NAT on OpenVPN.  It's an interface group, not an interface.  Assign an interface to the openvpn instance and put the NAT on that.

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

              You can NAT on OpenVPN, it works fine, depending on what you're doing.

              When trying to avoid a subnet conflict, the site with the conflicting subnet must do the NAT, however.

              In your example the firewall at the customer side would have to perform the NAT. For example, on the customer firewall NAT 192.168.1.0/24 to something else, say 10.192.1.0/24, and then on your end of OpenVPN, you'd route to and talk to 10.192.1.0/24 to reach the customer.

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

                I thought that was only true if the two sites that had the conflicting subnets needed to communicate with each other.

                I'm sure if I thought about it I would see that you're right and the "hub" pfSense would still need two routes to the same subnet.

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

                  The hub can't see the same subnet twice. To avoid the conflict, the remote sites have to do NAT. No way around it.

                  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