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

    Can't ping subnet from remote via openvpn [RESOLVED]

    Scheduled Pinned Locked Moved General pfSense Questions
    16 Posts 6 Posters 1.7k 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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      I think you mean the local network is in conflict not the tunnel.

      192.168.0.0/24 (your clients local subnet) is inside 192.168.0.0/22 (the subnet passed to client to access over the VPN). You won't be able to access anything inside .0/24 at the server end.

      Steve

      1 Reply Last reply Reply Quote 0
      • T
        T.Soprano
        last edited by

        Thanks for your answers i will try to reply all 3 of you.
        Gertjan it's clearly written in my original question which subnet i want but can't ping. Maybe you read carefully?

        johnpoz i tried to change my local subnet now it's 192.168.4.0/24 which doesnt overlap anymore with the pfsense remote 192.168.1.0/22, but i still can not ping 192.168.3.1. which is my Esxi server.

        Probably it has something to do with the esxi management port which is 192.168.3.1/22,
        Esxi use a static ip, while all other devices use pfsense dhcp.
        Probably this is the part dont let vpn reach esxi.
        I wonder why from office lan i can access .3.1 and not from vpn this has no sense to me.
        From vpn i can reach any office pc but not that specific one.

        The only difference it's esxi is outside pfsense dhcp, but i can not setup esxi to get ip from pfsense cause pfsense is a vm of esxi.

        it's quite damned tricky! i think the only "dirty solution" is to access virtual desktop of any office pc then access esxi through it, which i know will work.

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          Can you hit any host in the 192.168.3.X subnet?
          If it's just that one host it's probably missing a default route on that host or blocking traffic from the tunnel subnet specifically.

          Steve

          1 Reply Last reply Reply Quote 0
          • T
            T.Soprano
            last edited by

            yes i can ping all others.
            i will chk on esxi firewall but i think it has no rules set. let's update after vacation :)
            thanks

            1 Reply Last reply Reply Quote 0
            • johnpozJ
              johnpoz LAYER 8 Global Moderator
              last edited by

              Doesn't have to be firewall - if it not pointing back to pfsense as its gateway, then no you would not be able to talk to it from another network.

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 24.11 | Lab VMs 2.8, 24.11

              1 Reply Last reply Reply Quote 0
              • L
                lfoerster
                last edited by lfoerster

                And its not very intelligent to use the billion used 192.168.x.y for the local LANs. If you are in one of these networks with your client there will be of course no VPN connectivity anymore.
                Its a bit more intelligent to then use some "exotic" networks for local LANs in the dumb 192.168 range like 192.168.273.0 or so or better go to the 172.16-31 range. That avoids address doubling in the 192.168range with the VPN client which every dummie in the world uses.
                To make all your 2 LANs reachable you need to propagate both networks into the client routing table at VPN dialin with the "push route" option in the server.config file:
                push "route 192.168.x.0 255.255.255.0"

                Its of course NOT working in your case as you can see by yourself that you are using a 22bit subnet mask 255.255.252.0 on you local lan which includes the .3.x address range.
                You local subnet reaches here from address .2.1 to .3.254. and that means you can NOT use the .3.0 as a separate subnet. This is basic IP subnetting and wrong subnet IP address design by yourself in that case !!!
                On the other hand it makes too no sense to have 1022 possible clients in a layer 2 broadcast domain.
                Conclusion:
                Set both of your local LANs to a 24 bit subnet mask 255.255.255.0 and set the sever push route command to 22 bits
                push "route 192.168.2.0 255.255.252.0"
                and that will do the trick !
                If your client is a Winblows OS type "route print" when the client VPN is established and that way you can check if the routes are corretly distributed to the client by your server.

                T 1 Reply Last reply Reply Quote 1
                • johnpozJ
                  johnpoz LAYER 8 Global Moderator
                  last edited by

                  @lfoerster said in Can't ping subnet from remote via openvpn:

                  range like 192.168.273.0

                  that would be a good trick ;) And nobody else for sure would be using that ;) heheheh since not possible to use .273

                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                  If you get confused: Listen to the Music Play
                  Please don't Chat/PM me for help, unless mod related
                  SG-4860 24.11 | Lab VMs 2.8, 24.11

                  1 Reply Last reply Reply Quote 1
                  • T
                    T.Soprano @lfoerster
                    last edited by

                    @lfoerster i found bad attitude to call others decision "not intelligent" especially if you ignore the intentions and background. Learn this lesson.

                    Second who cares if bilion of people use that subnet? We have our office rules and subnet scheme and we did it on purpose.

                    Third you dont even know our company subnet scheme but you judge this decision as not intelligent, what you don't know is we have 138 different locations around the globe and the range 192.168.0.0/22 is assigned to hongkong facility, all others are taken already.

                    Thanks for your tips i will apply this, will let you know if will work.

                    1 Reply Last reply Reply Quote 0
                    • T
                      T.Soprano
                      last edited by

                      Ok tests has done. The electrician made a mistakes with lan cables and switches this is the reason why from VPN i can not ping 192.168.3.0/24, but i can ping 192.168.2.0/24 and 192.168.1.0/24.

                      Now without add or change any config on pfsense i can ping esxi on 192.168.3.1 because the cable now is in the right switch.

                      Before from office i can because in office my pc is connected with 2 ethernet cards on both layer2 subnets.

                      Thanks for all your tips.

                      JKnottJ 1 Reply Last reply Reply Quote 0
                      • JKnottJ
                        JKnott @T.Soprano
                        last edited by

                        @T-Soprano

                        Rule of thumb, always suspect cables and connectors. I have a simple continuity tester, which I carry in my computer bag, just for testing cables at customer sites. This is just a simple go/no go test, not performance certification.

                        PfSense running on Qotom mini PC
                        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                        UniFi AC-Lite access point

                        I haven't lost my mind. It's around here...somewhere...

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