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

    LAN access from VPN

    Scheduled Pinned Locked Moved
    NAT
    4
    26
    3.3k
    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.
    • G
      ghazel
      last edited by

      Packet capture on the pfSense LAN interface does show the packets from 192.168.2.14 (WG_VPN subnet) destined for 192.168.1.16 (LAN subnet). However, there is no response. Perhaps tellingly, 192.168.1.16 can reach 192.168.2.14 and it does respond. So for example I can ssh from 192.168.1.16 to 192.168.2.14, but not from 192.168.2.14 to 192.168.1.16.

      S J 2 Replies Last reply Reply Quote 0
      • S
        SteveITS Rebel Alliance @ghazel
        last edited by

        @ghazel but there is a rule on the VPN interface allowing access to lan?

        Usually it’s:
        Missing fw rule in arriving interface
        Device fw doesn’t allow different subnet
        Device not using pfSense as gateway

        Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
        Upvote 👍 helpful posts!

        G 1 Reply Last reply Reply Quote 0
        • J
          Jarhead @ghazel
          last edited by

          @ghazel said in LAN access from VPN:

          Packet capture on the pfSense LAN interface does show the packets from 192.168.2.14 (WG_VPN subnet) destined for 192.168.1.16 (LAN subnet). However, there is no response. Perhaps tellingly, 192.168.1.16 can reach 192.168.2.14 and it does respond. So for example I can ssh from 192.168.1.16 to 192.168.2.14, but not from 192.168.2.14 to 192.168.1.16.

          I agree with Steve and my guess would be the gateway.
          You can check by doing the packet capture again but on the WAN instead. You'll probably see the replies being sent out that way.

          1 Reply Last reply Reply Quote 0
          • G
            ghazel
            last edited by

            I don't see reply packets on WAN. I did uncover more detail that is surprising, though:

            Capturing on LAN, I see packets from 192.168.2.14 to 192.168.1.16 as expected. Capturing on the 192.168.1.16 machine, the same packets have the LAN mac address but a source IP of 192.1.68.1.2 -- that's the IP of a Netgear WiFi router running in AP mode (it doesn't run DHCP, and it isn't a gateway), which 192.168.1.16 is connected to. Of course, when 192.168.1.16 responds to 192.168.1.2 it gets ICMP host unreachable responses (with the correct Netgear mac address), and the TCP connection fails.

            V 1 Reply Last reply Reply Quote 0
            • V
              viragomann @ghazel
              last edited by

              @ghazel
              Seem a bit mysterious. Can't really believe.

              Did you check the points already, which @SteveITS mentioned above?
              I also suspect that the access is blocked by the destination device itself. This is the default behavior of an operating systems firewall.

              1 Reply Last reply Reply Quote 0
              • G
                ghazel @SteveITS
                last edited by

                @steveits said in LAN access from VPN:

                @ghazel but there is a rule on the VPN interface allowing access to lan?

                Usually it’s:
                Missing fw rule in arriving interface

                Arriving interface (WG_VPN) has an 'Allow Any' rule.

                Device fw doesn’t allow different subnet

                Device fw is not enabled. (behavior is the same even with it enabled, since the source IP of the packets is 192.168.1.2 -- inside the subnet)

                Device not using pfSense as gateway

                Device is using pfSense 192.168.1.1 as a gateway.

                @viragomann said in LAN access from VPN:

                @ghazel
                Seem a bit mysterious. Can't really believe.

                Maybe the Netgear is still doing source IP rewriting for sources that are outside the subnet?

                I also suspect that the access is blocked by the destination device itself. This is the default behavior of an operating systems firewall.

                Operating system firewall is off. Wireshark is seeing the packets and the responses.

                V 1 Reply Last reply Reply Quote 0
                • V
                  viragomann @ghazel
                  last edited by

                  @ghazel said in LAN access from VPN:

                  Maybe the Netgear is still doing source IP rewriting for sources that are outside the subnet?

                  It can do this only on traffic which passes through it.

                  Operating system firewall is off. Wireshark is seeing the packets and the responses.

                  Can you post this capture and tell us, on which device and NIC it was taken.

                  G 1 Reply Last reply Reply Quote 0
                  • G
                    ghazel @viragomann
                    last edited by ghazel

                    @viragomann said in LAN access from VPN:

                    @ghazel said in LAN access from VPN:

                    Maybe the Netgear is still doing source IP rewriting for sources that are outside the subnet?

                    It can do this only on traffic which passes through it.

                    The traffic is passing through it. Internet > WG_VPN > LAN > Netgear > 192.168.1.16

                    Operating system firewall is off. Wireshark is seeing the packets and the responses.

                    Can you post this capture and tell us, on which device and NIC it was taken.

                    pfSense_LAN.cap
                    192.168.1.16_en6.pcapng

                    Uploaded capture from pfSense on LAN interface 192.168.1.1 90:ec:77:32:cb:ad (which is plugged into the Netgear, 192.168.1.2 3c:37:86💿fc:ae) and capture from target machine en6 192.168.1.16 8c:ae:4c:dd:4a:91 (plugged into that Netgear).

                    V 1 Reply Last reply Reply Quote 0
                    • V
                      viragomann @ghazel
                      last edited by

                      @ghazel
                      Indeed, it's as you said before.

                      Maybe the Netgear is still doing source IP rewriting for sources that are outside the subnet?

                      Obviously that's the case.

                      But it must no do this if it's running in AP mode as you mentioned. In AP mode all traffic through the device is on layer 2 only, no routing or natting / masqerading would be possible.

                      So there must be something wrong with the settings of the Netgear AP. You should re-check this.

                      G 1 Reply Last reply Reply Quote 0
                      • G
                        ghazel @viragomann
                        last edited by

                        @viragomann said in LAN access from VPN:

                        But it must no do this if it's running in AP mode as you mentioned. In AP mode all traffic through the device is on layer 2 only, no routing or natting / masqerading would be possible.

                        So there must be something wrong with the settings of the Netgear AP. You should re-check this.

                        Unfortunately in AP mode there are zero additional settings.

                        I could get a standalone switch for the wired devices to connect to LAN, but the wireless devices would still have the same problem.

                        Would it be practical to force WG_VPN to use a section of the 192.168.1.x range, so that wireguard peers appeared to be on the same subnet as the Netgear?

                        V 1 Reply Last reply Reply Quote 0
                        • V
                          viragomann @ghazel
                          last edited by

                          @ghazel said in LAN access from VPN:

                          Unfortunately in AP mode there are zero additional settings.

                          But there must be something wrong with it. Did you reboot or better reset the device?

                          Replacing the source IP with its own only makes if the wifi device is in router mode and redirects respond packets back to the origin source.

                          Can it operate as a router?
                          This could be a workaround.

                          Would it be practical to force WG_VPN to use a section of the 192.168.1.x range, so that wireguard peers appeared to be on the same subnet as the Netgear?

                          You could masquerade the outgoing traffic on pfSense LAN interface and get the same. But if the switch replaces the source IP anyway, what I think, you win nothing.

                          G 1 Reply Last reply Reply Quote 0
                          • G
                            ghazel @viragomann
                            last edited by ghazel

                            @viragomann said in LAN access from VPN:

                            But there must be something wrong with it. Did you reboot or better reset the device?

                            Rebooted many times (thanks PG&E!). Have not tried a full reset, but will.

                            Can it operate as a router?
                            This could be a workaround.

                            Yes, with the downside of double-NAT. Services that currently work fine with upnp/nat-pmp would stop working.

                            You could masquerade the outgoing traffic on pfSense LAN interface and get the same. But if the switch replaces the source IP anyway, what I think, you win nothing.

                            It seems like the switch does not replace the source IP if it's in the same subnet range (192.168.1.x). So if the wireguard peer got 192.168.1.114 or something like that (instead of 192.168.2.14), maybe that would work?

                            V 1 Reply Last reply Reply Quote 0
                            • V
                              viragomann @ghazel
                              last edited by

                              @ghazel said in LAN access from VPN:

                              It seems like the switch does not replace the source IP if it's in the same subnet range (192.168.1.x).

                              Yes, I had even the same idea. So maybe you could try to masquerade the traffic on pfSense.

                              You can do this with an outbound NAT rule. On the outbound NAT tab enable the hybrid mode first.
                              Then add a rule with this values:
                              interface: LAN
                              source: 192.168.2.0/24
                              destination: any
                              translation: interface address

                              This replaces the source address with pfSense LAN address, so it's inside the subnet. Maybe this works.

                              G 1 Reply Last reply Reply Quote 0
                              • G
                                ghazel @viragomann
                                last edited by

                                @viragomann said in LAN access from VPN:

                                This replaces the source address with pfSense LAN address, so it's inside the subnet. Maybe this works.

                                It does work! Thank you very much!

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post