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

    [Solved] Only partial LAN access!?

    Scheduled Pinned Locked Moved OpenVPN
    15 Posts 5 Posters 4.6k 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
      cmb
      last edited by

      No need to reinstall.

      The difference between most PPTP and OpenVPN deployments in this regard is OpenVPN clients don't have IPs within the LAN subnet (and really shouldn't, arguably with PPTP as well). That means systems that are missing a default gateway, or have a wrong subnet mask aren't going to be able to communicate with OpenVPN clients while they would with PPTP because no routing is involved. That's the likely cause.

      1 Reply Last reply Reply Quote 0
      • C
        CryoGenID
        last edited by

        Thansk for your reply :-)

        Ok, what could I check to see if everything is ok?

        As stated in the first post, the LAN has a 10.0.2.0/24, the OpenVPN-Clients get a 10.0.5.XXX-IP (local lan setting in openVPN is also 10.0.2.0/24).
        In the PPTP-Settings the clients get a 10.0.8.XXX-IP…

        The OpenVPN-Client can still only reach some internal servers if I force all network traffic through the openVPN tunnel ...

        Thanks a lot for any help :-)

        Best regards,

        Chris

        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

          The states you posted pretty much guarantee the SYNs are getting passed out and getting no reply. To verify, start a constant ping to one of the IPs that isn't responding, packet capture on LAN filtering on that host's IP. See the traffic leaving there? Then it's going to the host and it isn't responding, or it is responding but gets misrouted (wrong/missing default gateway, wrong subnet mask, routing table entry in error).

          1 Reply Last reply Reply Quote 0
          • C
            CryoGenID
            last edited by

            cmb,

            thanks a lot for your reply.

            I have done as asked:

            
18:09:09.758726 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 5, length 40
18:09:09.764685 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:10.764674 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:11.764682 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:12.078479 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 6, length 40
18:09:16.993667 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 7, length 40
18:09:16.994667 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:17.994676 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:18.994691 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:21.997608 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 8, length 40
18:09:22.004738 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:23.004697 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:24.004703 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:26.999189 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 9, length 40
18:09:27.004724 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:28.004726 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:29.004732 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:31.999711 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 10, length 40
18:09:32.004755 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:33.004750 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:34.004756 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:36.994537 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 11, length 40
18:09:37.004819 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:38.004779 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:39.004779 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:41.998769 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 12, length 40
18:09:42.004802 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:43.004789 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:44.004807 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:47.006118 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 13, length 40
18:09:47.014858 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:48.014833 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:49.014842 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:52.001018 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 14, length 40
18:09:52.004852 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:53.004850 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:54.004840 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:56.993105 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 15, length 40
18:09:56.994870 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:57.994876 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:58.994883 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:01.994307 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 16, length 40
18:10:01.994895 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:02.994898 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:03.994903 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:06.998067 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 17, length 40
18:10:07.004923 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:08.004926 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:09.004932 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:11.999210 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 18, length 40
18:10:12.004953 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:13.004948 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:14.004954 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:17.000189 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 19, length 40
18:10:17.005008 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:18.004972 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:19.005007 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:21.998514 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 20, length 40
18:10:22.005014 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:23.005006 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:24.005031 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46

            Whereas 10.0.8.6 is the openVPN Client-IP, 10.0.2.121 is the server…

            I have then done the same with the PPTP-Connection:

            
18:13:19.242341 IP 10.0.9.16 > 10.0.2.121: ICMP echo request, id 1, seq 27, length 40
18:13:19.242662 IP 10.0.2.121 > 10.0.9.16: ICMP echo reply, id 1, seq 27, length 40
18:13:20.251534 IP 10.0.9.16 > 10.0.2.121: ICMP echo request, id 1, seq 28, length 40
18:13:20.251830 IP 10.0.2.121 > 10.0.9.16: ICMP echo reply, id 1, seq 28, length 40
18:13:21.259660 IP 10.0.9.16 > 10.0.2.121: ICMP echo request, id 1, seq 29, length 40
18:13:21.259953 IP 10.0.2.121 > 10.0.9.16: ICMP echo reply, id 1, seq 29, length 40

            Whereas 10.0.9.16 is the PPTP Client-IP, 10.0.2.121 is the server…

            This is the network config of the server:

            IP Address:      10.0.2.121
            Subnet Mask:  255.255.255.0
            Gateway:        10.0.2.1
            DNS Server IP: 10.0.2.1

            Any clues what might go wrong here?

            Thanks a lot for any help :-)

            Best regards,

            Christian

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              Good, that's very telling. The ARP request that's being issued (ARP, Request who-has 10.0.8.6 tell 10.0.2.121) means the host has a wrong subnet mask (not actually 255.255.255.0) or just a plain broken network stack. ARP requests are issued only for IPs that are local on the same subnet. Since 10.0.2.121 is issuing an ARP request for 10.0.8.6, it thinks that is on its local subnet. If it were only configured with 10.0.2.121 with a /24 (255.255.255.0) mask, it would never ARP anything other than 10.0.2.x, and would ARP its default gateway for anything outside that subnet.

              That clearly shows 10.0.2.121 is what's broken, it doesn't tell as clearly why. An errant IP alias on 10.0.8.x, a wrong routing table entry, hard to tell for sure.

              1 Reply Last reply Reply Quote 0
              • C
                CryoGenID
                last edited by

                cmb,

                thanks a lot for your analysis :-)

                But what I still don't understand:
                The problem doesn't only affect one server, I just picked that one for testing purposes…

                And why does it work perfectly OK with PPTP? The PPTP-Client-IP is also not on the 10.0.2.0/24 network, but on 10.0.9.0/24...

                So the server itself can talk from 10.0.2.121 -> 10.0.9.6 without any issues, but not to 10.0.8.6 or 10.0.5.6 (I tested these two network ranges with openVPN) ?

                Couldn't it be some kind of problem in the config/setup of the pfSense itself? It bet that it would work if I also set the PPTP-Range to 10.0.8.0/24 ;-)

                Thanks again a lot for your help!!

                Best regards,

                Chris

                1 Reply Last reply Reply Quote 0
                • C
                  cmb
                  last edited by

                  The firewall has absolutely no control or influence over what hosts on your internal network will ARP. There is 0 possibility for the firewall to cause a device to ARP an IP it should never ARP. I'm sure if you change your PPTP range to 10.0.8.x it'll do the exact same thing (unless mpd proxy ARPs PPTP IPs in that circumstance, I think it'll only do that when they're on the LAN subnet though I'm not 100% sure off the top of my head).

                  If you want to work around it without fixing that particular broken device on your network, add a proxy ARP VIP range for 10.0.8.0/24 on LAN. That'll at least work around the broken host that's ARPing things it shouldn't, but I wouldn't, I'd fix the problem on the actual host rather than working around its brokenness. Look at its routing table, and any IP aliases configured.

                  Alternatively, change your OpenVPN tunnel network to something in 172.16.0.0/12 and it likely won't pose an issue either, depending on exactly how that device is broken.

                  1 Reply Last reply Reply Quote 0
                  • C
                    CryoGenID
                    last edited by

                    cmb,

                    thanks A LOT! You are the life saver, that worked :-)

                    Using the Proxy ARP, I can now connect to all servers in the 10.0.2.0/24-network without any problems :-)

                    Now the only thing I have to figure out is how the openVPN-Clients can also access 10.0.1.0/24 and 10.0.3.0/24 … That also worked "out of the box" with PPTP...

                    Any hints here for me? Perhaps I am mentally still so "locked" the previous problem that I don't see the (possibly completely easy) solution at the moment g

                    Thanks A LOT again and best regards,

                    Chris

                    1 Reply Last reply Reply Quote 0
                    • M
                      Metu69salemi
                      last edited by

                      have you tried push route as pfsense suggest you to use?

                      1 Reply Last reply Reply Quote 0
                      • C
                        CryoGenID
                        last edited by

                        Thanks a lot for your reply  :)

                        That did it, now everything works as expected, again a big THANKS to all of you who helped me out here  :)

                        Have a nice week!

                        Best regards,

                        Chris

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