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

    pfsense OpenVPN won't route to static IPs on LAN but will to DHCP IPs

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 2 Posters 773 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.
    • C
      cctl01
      last edited by cctl01

      I'm having an issue reaching devices with static ip set "in" the device over VPN.

      -----My situation-----

      pfSense (2.4.5 p1) runs as a vm in ESXi. Most of my devices have static ip's that are assigned to them via DHCP in pfSense. Three network devices have static ip's configured on the devices since they need to be reachable before pfSense is running (ESXi instance, IPMI and the network switch).

      When configuring devices static I do also add them to the DHCP server static mappings in pfSense (am i supposed to do this?)

      pfSense is running on 10.1.1.1 , the OpenVPN server is 10.1.2.1 and OpenVPN clients 10.1.2.x ESXi is running under 10.1.1.101 .

      -----What I have tried so far-----

      • I completely disabled IPV6 in ESXi, my switch and pfSense.

      • In the firewall rules under the OpenVPN server there is an IPV4 *** rule.

      • When manually configuring the ip address I set the pfSense instance as gateway, i tried with subnet mask both 255.255.255.0 and 255.255.0.0

      • When I go diagnostics > ping and select the openvpn server as source address I CAN NOT ping the desired systems. When I select the LAN side of my network as source I CAN ping the devices.

      • When I go diagnostics > ARP table the devices do show up and are online.

      • list itemWhen ESXi is running and I change it's network configuration from static to DHCP, I can reach it over VPN. (The lan configuration (IP, gateway and subnet) stay's the same for as far as I can see.
        ----EDIT's-----

      This post will be updated as I gather more details based on suggestions made by you.

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

        @cctl01

        The first thing you have to do is determine your network address and size. This will tell you what the subnet mask should be. A /16 gives 65K addresses and a /24, 256. Also, the other end of the VPN has to be a different subnet and you want a 3rd for the tunnel. This one can be a /30.

        Once you've done that, then you can configure everything appropriately.

        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...

        C 1 Reply Last reply Reply Quote 1
        • C
          cctl01 @JKnott
          last edited by

          @jknott
          I did not mention in my 1st post. LAN is setup as 10.1.1.0/24 and OpenVPN as 10.1.2.0/24. I assumed these were separate subnets with no overlap.
          However after reading your comment I changed the VPN network to 192.168.0.0/24 and now everything works as expected.

          Could you elaborate why that is and what I was overlooking?

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

            @cctl01

            I can't say for certain, but I suspect from your description you had a /16 subnet mask, which meant those subnets actually overlapped. With a /16 mask, everything within 10.1.0.0 /16 is one subnet.

            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.