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

    OpenVPN for road warriors (=remote client) - unable to access LAN clients

    Scheduled Pinned Locked Moved OpenVPN
    17 Posts 2 Posters 11.0k 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.
    • S
      srizzi72
      last edited by

      In my first post i have reported all rules that are set on pfSense. All rules are with the "log" enabled.
      When I try to access a machine in LAN network, no record are written in Status -> System logs -> Firewall matching involved IPs….
      There is a way to monitor/see packages reaching my pfSense in order to understand where are going?? Seem they are lost inside pfSense box....

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        You can use Diagnostics > Packet Capture in the GUI, or tcpdump from the shell.

        The LAN rules would only be triggered when connections were made from the LAN to elsewhere. They would not be triggered for incoming VPN traffic from OpenVPN.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • S
          srizzi72
          last edited by

          Thak you jimp for your reply.

          The LAN rules would only be triggered when connections were made from the LAN to elsewhere. They would not be triggered for incoming VPN traffic from OpenVPN.

          Does this means that my two rules from/to LANnet/VPNnet are not needed?

          As I'm suspecting that the problem is not only just related to OpenVPN I have created a NAT (Port Forwarding) to verify if packets are able to walk from Internet to machines on my LAN. Parameters are:

          If      Proto  Ext.port range    NAT IP                                        Int. port range
          WAN  TCP    80 (HTTP)        192.168.49.2 (ext.: 192.168.5.10)  80 (HTTP)

          the result is a timeout… As shown in the System log->Firewall and in Packet Capture the package is received by the pfSense but is not sent to the LAN interface.
          All rules are logging. The System log->Firewall report 1 row with:
          Act=green IF=WAN Source=my internet ip Destination=192.168.49.2:80 Proto= TCP:S
          No other rows form/to my internet ip and ip of the machine exposed with NAT (192.168.49.2).

          With Packet Capture on WAN: one package from my internet ip to 192.168.5.10 port 80 and no other packages. (192.168.5.10 is the IP of WAN if)
          With Packet Capture on LAN: no packages.

          So, packages not generated on LAN (coming from WAN or from OpenVPN) are stopped. Note that LAN clients are able to navigate in internet...

          What I can check to verify if exists something blocking packages that instead (rules that i mentioned before) should walk through pfSense?

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            Does this means that my two rules from/to LANnet/VPNnet are not needed?

            Correct. The rules going "to" the VPN might be needed but (a) they are underneath the more general allow rule so the rule would be skipped, and (b) your allow all rule would allow that anyhow. First match wins with firewall rules and many others.

            Your port forward and VPN comparison is apples-and-oranges. One likely has very little to do with the other.

            Do you have "block private networks" unchecked on Interfaces > WAN? That may be part of the issue, otherwise, try these things:
            http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

            As for the VPN, the port forward test is not indicative of any potential issue. You'd have to do a packet capture on LAN to see if the traffic made it out, and a packet capture on tun0 to see if the traffic is even coming in from the client.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • S
              srizzi72
              last edited by

              Thank you jimp

              Correct. The rules going "to" the VPN might be needed but (a) they are underneath the more general allow rule so the rule would be skipped, and (b) your allow all rule would allow that anyhow. First match wins with firewall rules and many others.

              Rules cleaned!

              Do you have "block private networks" unchecked on Interfaces > WAN? That may be part of the issue, otherwise, try these things:
              http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

              My provider is Fastweb and is using NAT over his network, the Fasweb router has IP 192.168.5.1 and the WAN ip must be 192.168.5.10. So i have left unchecked the "block private networks". Correct?

              I have checked NAT and rules and are ok as specified in the link that you have sent me.

              As for the VPN, the port forward test is not indicative of any potential issue. You'd have to do a packet capture on LAN to see if the traffic made it out, and a packet capture on tun0 to see if the traffic is even coming in from the client.

              using tcpdump on tun0 when i try to open an http connection to the WebServer on my LAN via OpenVPN (ip: 192.168.49.2) the only line that is shown related to this connection is:

              15:43:57.239205 IP 192.168.98.6.4416 > 192.168.49.2.http: S 1323696919:1323696919(0) win 64512 <mss 1118,nop,nop,sackok="">all other lines are related to ssh connection i have opened to run tcpdump command.

              using tcpdump on re0 (LAN) when i try to open an http connection to the WebServer on my LAN via OpenVPN (ip: 192.168.49.2) no lines are shown. all other lines are related to lan traffic vs internet.

              using tcpdump on xl0 (WAN) when i try to open an http connection to the WebServer on my LAN via internet the only line that is shown related to this connection is:

              15:48:02.673469 IP 134.128.87.72.4442 > 192.168.5.10.http: S 2497132998:2497132998(0) win 64512 <mss 1460,nop,nop,sackok="">all other lines are related to lan traffic vs internet and UDPs packet vs OpenVPN.

              using tcpdump on re0 (LAN) when i try to open an http connection to the WebServer on my LAN via internet no lines are shown. all other lines are related to lan traffic vs internet.

              Others things to check?</mss></mss>

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                There must be some other internal routing issue then.

                Can you post the output of the following shell commands?

                ifconfig -a

                netstat -rn

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • S
                  srizzi72
                  last edited by

                  ifconfig -a

                  xl0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
                          options=8 <vlan_mtu>ether 00:10:4b:af:c7:63
                          inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255
                          inet6 fe80::210:4bff:feaf:c763%xl0 prefixlen 64 scopeid 0x1
                          media: Ethernet autoselect (100baseTX <full-duplex>)
                          status: active
                  xl1: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
                          options=8 <vlan_mtu>ether 00:60:08:7b:f8:90
                          media: Ethernet autoselect (none)
                          status: no carrier
                  xl2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
                          options=8 <vlan_mtu>ether 00:60:08:7b:f1:67
                          media: Ethernet autoselect (none)
                          status: no carrier
                  re0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                          options=3898 <vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic>ether 00:1a:92:34:89:8a
                          inet 192.168.49.1 netmask 0xffffff00 broadcast 192.168.49.255
                          inet6 fe80::21a:92ff:fe34:898a%re0 prefixlen 64 scopeid 0x4
                          media: Ethernet autoselect (100baseTX <full-duplex>)
                          status: active
                  lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
                          inet 127.0.0.1 netmask 0xff000000
                          inet6 ::1 prefixlen 128
                          inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
                  enc0: flags=0<> metric 0 mtu 1536
                  pfsync0: flags=41 <up,running>metric 0 mtu 1460
                          pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128
                  pflog0: flags=100 <promisc>metric 0 mtu 33204
                  tun0: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
                          inet6 fe80::210:4bff:feaf:c763%tun0 prefixlen 64 scopeid 0x9
                          inet 192.168.98.1 –> 192.168.98.2 netmask 0xffffffff
                          Opened by PID 392

                  netstat -rn

                  Routing tables

                  Internet:
                  Destination        Gateway            Flags    Refs      Use  Netif Expire
                  default            192.168.5.1        UGS        0    11175    xl0
                  127.0.0.1          127.0.0.1          UH          0        0    lo0
                  192.168.5.0/24    link#1            UC          0        0    xl0
                  192.168.5.1        00:03:6f:e0:13:90  UHLW        2      170    xl0  1148
                  192.168.49.0/24    link#4            UC          0        0    re0
                  192.168.49.2      00:13:21:c9:18:89  UHLW        1    2926    re0  1064
                  192.168.49.36      00:23:ae:b0:b8:73  UHLW        1    3191    re0  1065
                  192.168.49.37      00:25:64:bc:f5:1d  UHLW        1    1906    re0    444
                  192.168.49.50      00:1d:92:3a:60:b1  UHLW        1      129    re0  1193
                  192.168.49.55      00:0b:82:15:46:df  UHLW        1        1    re0  1004
                  192.168.98.0/24    192.168.98.2      UGS        1    6008  tun0
                  192.168.98.2      192.168.98.1      UH          1        0  tun0

                  Internet6:
                  Destination                      Gateway                      Flags      Netif Expire
                  ::1                              ::1                          UHL        lo0
                  fe80::%xl0/64                    link#1                        UC          xl0
                  fe80::210:4bff:feaf:c763%xl0      00:10:4b:af:c7:63            UHL        lo0
                  fe80::%re0/64                    link#4                        UC          re0
                  fe80::21a:92ff:fe34:898a%re0      00:1a:92:34:89:8a            UHL        lo0
                  fe80::%lo0/64                    fe80::1%lo0                  U          lo0
                  fe80::1%lo0                      link#5                        UHL        lo0
                  fe80::%tun0/64                    link#9                        UC        tun0
                  fe80::210:4bff:feaf:c763%tun0    link#9                        UHL        lo0
                  ff01:1::/32                      link#1                        UC          xl0
                  ff01:4::/32                      link#4                        UC          re0
                  ff01:5::/32                      ::1                          UC          lo0
                  ff01:9::/32                      link#9                        UC        tun0
                  ff02::%xl0/32                    link#1                        UC          xl0
                  ff02::%re0/32                    link#4                        UC          re0
                  ff02::%lo0/32                    ::1                          UC          lo0
                  ff02::%tun0/32                    link#9                        UC        tun0

                  xl1 (OPT1) and xl2 (OPT2) are not used/connected and are configured to use DHCP.</up,pointopoint,running,multicast></promisc></up,running></up,loopback,running,multicast></full-duplex></vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_ucast,wol_mcast,wol_magic></up,broadcast,running,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></full-duplex></vlan_mtu></up,broadcast,running,promisc,simplex,multicast>

                  1 Reply Last reply Reply Quote 0
                  • jimpJ
                    jimp Rebel Alliance Developer Netgate
                    last edited by

                    That all looks correct. It's a bit of a mystery where that traffic is going then if it's not being blocked and also not coming out LAN.

                    It appears as though it should route properly based on what I see in the interface and route config you attached.

                    Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                    Need help fast? Netgate Global Support!

                    Do not Chat/PM for help!

                    1 Reply Last reply Reply Quote 0
                    • S
                      srizzi72
                      last edited by

                      Hello jimp!
                      This weekend I have re-installed pfSense and then was working well, problem solved… until... until I have enabled Captive Portal! CAPTIVE PORTAL is the Mistery in my pfSense :-/
                      I can assure that enabling Captive Portal I'm no more able to access LAN clients... disabling Captive portal the LAN network is visible again...
                      Even if I set the ip of the LAN client that I want to access, when Captive Portal is enable that IP and the rest of the LAN network is no more visible. There is the option to "Disable MAC filtering" but doesn't solve the problem...

                      1 Reply Last reply Reply Quote 0
                      • jimpJ
                        jimp Rebel Alliance Developer Netgate
                        last edited by

                        That could definitely be an issue there. I didn't know CP was involved at all.

                        You might need to make two internal LANs, one of clients protected by CP, and another for systems which need to be accessed from remote locations by VPN or port forwards.

                        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                        Need help fast? Netgate Global Support!

                        Do not Chat/PM for help!

                        1 Reply Last reply Reply Quote 0
                        • S
                          srizzi72
                          last edited by

                          oh… is not a best solution for me, btw, i will investigate a bit... and then will decide what to do.

                          Thank you so much for your help, your support and your time!
                          Stefano.

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