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

    Can't ping LAN hosts on both sides of the tunnel

    Scheduled Pinned Locked Moved OpenVPN
    9 Posts 3 Posters 4.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
      jan.gestre
      last edited by

      Hi Guys,

      I have several vpn tunnels setup on my pfSense box, most are road warrior clients and I added a new site2site tunnel and I see from the logs that they are connected however I can't ping any hosts on both sides of the tunnel and I always see this in the logs on both client and server using the WAN interface of pfSense.

      openvpn[383]: Initialization Sequence Completed
      openvpn[320]: WARNING: 'ifconfig' is used inconsistently, local='ifconfig 10.10.10.1 10.10.10.2', remote='ifconfig 192.168.9.1 192.168.9.2'

      my address pool is 10.10.10.0/24
      server ip 192.168.1.0/24
      client ip 192.168.9.0/24
      protocol tcp
      port 21194

      Any idea what's wrong?

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

        You missconfigured either the client or the server.
        Can you show screenshots of the configs? (i cannot say on which you did the missconfig out of the infos you gave.)

        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
        • J
          jan.gestre
          last edited by

          @GruensFroeschli:

          You missconfigured either the client or the server.
          Can you show screenshots of the configs? (i cannot say on which you did the missconfig out of the infos you gave.)

          Attached herewith are the screenshots of the vpn server and client respectively

          ![vpn server.jpg](/public/imported_attachments/1/vpn server.jpg)
          ![vpn server.jpg_thumb](/public/imported_attachments/1/vpn server.jpg_thumb)
          ![vpn client.jpg](/public/imported_attachments/1/vpn client.jpg)
          ![vpn client.jpg_thumb](/public/imported_attachments/1/vpn client.jpg_thumb)

          1 Reply Last reply Reply Quote 0
          • Z
            Zanotti
            last edited by

            Maybe you haven't correctly configured your PC's with the right gateway in both LAN..

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

              Think of the OpenVPN tunnel as a cable between your two pfSense's.

              I hope you understand that they have to have an IP out of the same subnet to be able to communicate with each other.
              (If you dont understand that i suggest you start reading wikipedia on how TCP/IP networks work).

              Right now it is configured:
              Server-IP: 10.10.10.1/24 (Address-Pool field)
              Client-IP: 192.168.9.2/24 (Interface IP field)
              They have to be in the same subet.

              You should read the notes next to the fields more closely:

              This is the address pool to be assigned to the clients. Expressed as a CIDR range (eg. 10.0.8.0/24). If the 'Use static IPs' field isn't set, clients will be assigned addresses from this pool. Otherwise, this will be used to set the local interface's IP.

              it might be a bit confusing, but if you have a "shared key" setup the field "Use static IPs" gets disabled
              –> you have to set static IP's ina shared key setup.

              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
              • J
                jan.gestre
                last edited by

                @GruensFroeschli:

                Think of the OpenVPN tunnel as a cable between your two pfSense's.

                I hope you understand that they have to have an IP out of the same subnet to be able to communicate with each other.
                (If you dont understand that i suggest you start reading wikipedia on how TCP/IP networks work).

                Right now it is configured:
                Server-IP: 10.10.10.1/24 (Address-Pool field)
                Client-IP: 192.168.9.2/24 (Interface IP field)
                They have to be in the same subet.

                You should read the notes next to the fields more closely:

                This is the address pool to be assigned to the clients. Expressed as a CIDR range (eg. 10.0.8.0/24). If the 'Use static IPs' field isn't set, clients will be assigned addresses from this pool. Otherwise, this will be used to set the local interface's IP.

                it might be a bit confusing, but if you have a "shared key" setup the field "Use static IPs" gets disabled
                –> you have to set static IP's ina shared key setup.

                I thought they should not be in the same subnet because it will not work, right? I just followed the howto in the Sticky. I had a working site to site tunnel before using the same config and it did not generate those warning messages.

                If I understand correctly from what you're saying is that the local subnet and remote subnet should be on the same network, this goes against the basic routing rule when setting up a vpn tunnel, right? or I completely misunderstood what you're trying to say.

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

                  Your local subnet and remote subnet have to be different.
                  But you also need a third subnet as a kind of a "transfer-subnet" whgich has to be different as well.

                  The "interface IP" and "address-pool" fields are there to define the virtual IP's of this "transfersubnet".

                  It might be that i missunderstood where you want which subnet.

                  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
                  • J
                    jan.gestre
                    last edited by

                    @GruensFroeschli:

                    Your local subnet and remote subnet have to be different.
                    But you also need a third subnet as a kind of a "transfer-subnet" whgich has to be different as well.

                    The "interface IP" and "address-pool" fields are there to define the virtual IP's of this "transfersubnet".

                    It might be that i missunderstood where you want which subnet.

                    The local and remote subnet are of different network:

                    local is 192.168.1.0/24
                    remote is 192.168.9.0/24
                    address pool is 10.10.10.0/24

                    There shouldn't be any conflicts here right? The tunnel is up according to the logs which says "Initialization Sequence Complete" but that same logs also says that Warning I mentioned.

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

                      The conflict is that you DIDN'T set the virtual interface IP to a 10.10.10.0/24 IP but to a 192.168.9.0/24 IP
                      –>"Interface IP" field on the client

                      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
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.