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

    Another "Cant Route LAN Traffic" post - My apologies

    Scheduled Pinned Locked Moved OpenVPN
    16 Posts 4 Posters 2.3k 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.
    • B
      bignick0
      last edited by

      Let me preface by saying that I'm relatively new to this technology, however English IS my first language. That said, I take full responsibility for any miscommunication resulting from my ignorance.

      I have the OpenVPN server configured and am able to connect to it using my Win10, administrator installed client, which I deployed through the Client Export tool.

      I am assigned the correct IP address (10.0.10.2) based on my tunnel network preferences. After some fooling around, I am now able to ping the tunnel gateway (10.0.10.1) correctly, and even ping and connect via HTTP to my PFSense box using the LOCAL LAN network IP address (172.33.17.13). Unfortunately I am not able to get any response from other devices on that same subnet.

      I've checked the firewall logs, and I cannot see any BLOCK entries related to my client IP. I have the auto-generated rules in place that the wizard built in my firewall "WAN" and "OpenVPN" tabs. The client settings look correct to me:

      IPv4 Address: 10.0.10.2 (Preferred)
      Subnet Mask: 255.255.255.0
      Default Gateway: 10.0.10.1
      DHCP Server: 10.0.10.254

      I'm at a loss as to where to check for next steps. Please let me know if there are any other details I can share that might help with getting some guidance on this.

      Thanks!

      EDIT: one thing I found interesting, maybe it's normal, when I do a traceroute to one of the internal LAN resources that I can't access, from the connected client, the first hop it tries is the public-facing IP of the pfsense box. Is that normal?

      Also some more detail:

      IPv4 Route Table

      Active Routes:
      Network Destination        Netmask                    Gateway      Interface        Metric
      0.0.0.0                          0.0.0.0                      192.168.0.1  192.168.0.45    50
      10.0.10.0                      255.255.255.0            On-link        10.0.10.2        291
      10.0.10.2                      255.255.255.255        On-link        10.0.10.2        291
      10.0.10.255                  255.255.255.255        On-link        10.0.10.2        291
      127.0.0.0                      255.0.0.0                    On-link        127.0.0.1        331
      127.0.0.1                      255.255.255.255        On-link        127.0.0.1        331
      127.255.255.255            255.255.255.255        On-link        127.0.0.1        331
      172.33.17.0                  255.255.255.0            10.0.10.1      10.0.10.2        35
      192.168.0.0                  255.255.255.0            On-link        192.168.0.45    306
      192.168.0.45                255.255.255.255        On-link        192.168.0.45    306
      192.168.0.255              255.255.255.255        On-link        192.168.0.45    306
      224.0.0.0                      240.0.0.0                    On-link        127.0.0.1        331
      224.0.0.0                      240.0.0.0                  On-link          192.168.0.45    306
      224.0.0.0                      240.0.0.0                  On-link          10.0.10.2        291
      255.255.255.255          255.255.255.255        On-link          127.0.0.1      331
      255.255.255.255          255.255.255.255        On-link          192.168.0.45    306
      255.255.255.255          255.255.255.255        On-link          10.0.10.2        291

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

        A typical reason for this behavior is that pfSense isn't the default gateway in the LAN.
        If you want to drive a VPN server this way, you have to either add static routes for the tunnel subnet to the LAN devices or do NAT on pfSense.

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

          i just make the default gateway in the firewall under the openvpn tab correct? what's the static routes way?

          1 Reply Last reply Reply Quote 0
          • B
            bignick0
            last edited by

            Thanks for the information. When you say "pfSense isn't the default gateway in the LAN" are you referring to the entire LAN environment? In my case pfSense is being used as the gateway for the entire LAN. All of the LAN devices that I am trying to reach through OpenVPN have their default gateway set as the pfSense box (172.33.17.13) and they are on the same (172.33.17.x) network.

            Within pfSense under "System->Routing: Gateways" I have a default configured called WANGW which points to my external IP address (66.x.x.x).

            Does this seem to answer your question as to whether pfSense is behaving as the primary gateway? I think that it is.

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

              Yes, that's what I was thinking about.

              You may also check if the firewalls on the LAN devices block access from other subnets. E.g. Windows firewall blocks such access by default.

              1 Reply Last reply Reply Quote 0
              • B
                bignick0
                last edited by

                That was a good thought, except I have 100 or more devices; a mixture of linux, windows, printers, NAS, etc. None of them are providing any response.

                I keep poking around but none of my changes seem to get me any closer and I'm not sure where to look next.

                Thanks.

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

                  So go to troubleshooting.

                  Do a packet capture on LAN interface in the pfSense Diagnostic menu.
                  Select LAN at interface, ICMP protocol and enter the LAN device you're trying to ping, then start the capture and start the ping at the VPN client.

                  You should see ICMP requests and replys, then do a capture on OpenVPN interface, here you should see the same packets.

                  1 Reply Last reply Reply Quote 0
                  • B
                    bignick0
                    last edited by

                    Thank you for this.  ;D

                    I ran the capture on the LAN interface and saw nothing. I then ran it on the WAN interface and saw the requests coming from my public IP to my destination internal LAN IP. Finally I ran it on the OpenVPN interface and again I saw the requests, this time coming from my tunnel IP address (10.0.10.2) to my internal LAN IP. At no time do I ever receive a ping response.

                    I'm not certain what this proves, except that my requests are passing through the WAN interface and hitting the OpenVPN interface. Does this mean that there is some routing problem between the OpenVPN interface and the local LAN interface?

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

                      If the packets are routed out to the WAN maybe your LAN interface setting is wrong. Check if the network mask is set correctly.

                      1 Reply Last reply Reply Quote 0
                      • B
                        bignick0
                        last edited by

                        If I understand correctly, I'm checking this in the "Interfaces–>Lan" settings. The IPv4 address is currently set to the IP address of the pfSense box (172.33.17.13) with a /24 netmask.

                        This box has been operating with these same settings for years. Basically it's functioning just like we want, except for the OpenVPN functionality.

                        I tried to do a traceroute with pfSense diagnostics to one of my internal IP addresses using OpenVPN server as the Source Address. The output only generated * * *  for each of 18 hops. Should the traceroute from the OpenVPN source be able to get to local LAN destinations?

                        Thank you again, for your assistance.

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

                          @bignick0:

                          I tried to do a traceroute with pfSense diagnostics to one of my internal IP addresses using OpenVPN server as the Source Address. The output only generated * * *  for each of 18 hops.

                          That's normal if the destination host does not respond.

                          Do you have any policy routings? Please post firewall rules on OpenVPN interface and also floating rules.
                          Also post the IPv4 routing tables of pfSense and the destination host.

                          1 Reply Last reply Reply Quote 0
                          • B
                            bignick0
                            last edited by

                            Lets see if I can answer your questions adequately… :-D

                            -I don't believe I have any policy-based routing in place. In System-->Gateways I have only a single entry for WAN which is my external IP address. There is nothing defined in the Routes or Groups tabs. Is there somewhere else to look for policy-based routing?

                            -The firewall rule for the OpenVPN interface is the default rule created by the wizard: Pass IPV4 any any any any any none. There are no "Floating Rules" defined; that tab is blank.

                            -Here is the IPV4 table for the pfSense box:
                            Internet:
                            Destination        Gateway            Flags      Netif Expire
                            default              66.X.X.X      UGS        re0
                            10.0.10.0/24      10.0.10.1          UGS      ovpns1
                            10.0.10.1          link#20            UHS        lo0
                            10.0.10.2          link#20            UH      ovpns1
                            10.1.1.0/24        link#2            U          igb1
                            10.1.1.2          link#2            UHS        lo0
                            10.2.2.0/24        link#1            U          igb0
                            10.2.2.2          link#1            UHS        lo0
                            66.X.X.X/29  link#4            U          re0
                            66.X.X.X      link#4            UHS        lo0
                            127.0.0.1          link#8            UH          lo0
                            172.33.17.0/24    link#3            U          bge0
                            172.33.17.13      link#3            UHS        lo0
                            207.X.X.X    66.X.X.X      UGHS        re0
                            208.X.X.X      66.X.X.X      UGHS        re0

                            Those bottom two entries are used for routing to other established IPSec tunnels.

                            I just discovered something crazy when I was trying to get one of the unresponsive hosts routing tables....  I can actually connect to SOME of my internal LAN destinations. But it seems to be random. I am actually getting DNS resolution! I can connect to SOME windows hosts; 2 out of 3 vmware boxes, 2 of the 5 printers.

                            This is a much better scenario than I thought. It seems like the tunnel is working after all. But how do I figure out why some destinations are unreachable?

                            Thanks!

                            1 Reply Last reply Reply Quote 0
                            • R
                              Robert1956
                              last edited by

                              The 172.33.range address you are using are public addresses which could be on-line or off-line. Duplicate ip address.

                              1 Reply Last reply Reply Quote 0
                              • B
                                bignick0
                                last edited by

                                Robert - that is an interesting thought, however; why would my VPN tunnel be routing outside for some addresses (and finding them offline) versus successfully connecting to some internal LAN addresses successfully? I believe all of my 172.33.17.X subnet requests should be routed to my LAN.

                                Or perhaps there is something fundamental that I am not understanding about how this works.

                                :-D

                                Thanks for the feedback.

                                1 Reply Last reply Reply Quote 0
                                • B
                                  bignick0
                                  last edited by

                                  okay - Thanks for everyone's input on this. I think the VPN tunnel is working fine now. I was able to reach one of my unreachable LAN destinations by adding a route back to the gateway (172.33.17.13) for all 10.0.10.x traffic. So, my packets were getting to the destination on the LAN fine, but there was no return path for them. This MUST be the case for various other devices on my LAN. I guess I'll have to address them one-by-one to see why their routing tables aren't consistent.

                                  I am having one outstanding issue though..  I am connecting to the VPN with a Windows 10 laptop. When I my laptop is connected via WIFI to my home network I am able to get the DNS server assignment from OpenVPN just fine and I can resolve remote LAN IP addresses. When I connect my laptop via ethernet, the OpenVPN DNS server setting seems to be ignored and all DNS lookups are going through my ISP.

                                  When I check the ipconfig the settings for TAP-Windows Adapter v9 look the same each time; ie., the DNS server LOOKS to be set correctly. It's just that when I am ethernet connected, the DNS setting on this adapter is ignored, and instead the DNS server on my Wired Ethernet Adapter is used.

                                  Is there some way to force Windows to use the DNS settings for the TAP Adapter?

                                  Maybe this is more of a Widows-related question.

                                  Thanks for any input!

                                  1 Reply Last reply Reply Quote 0
                                  • B
                                    bignick0
                                    last edited by

                                    Update: Finally I fixed all the outstanding issues. I had to correct some gateways for a few Esxi hosts, add some static routes to multi-NIC servers, adjust some workstation windows firewall rules, and now I can get to all of my LAN destinations.

                                    Thank you for your help with this!

                                    Also, after updating the OpenVPN client version on my Windows 10 box to 2.4 and adding the "block-outside-dns" parameter, I am getting local LAN DNS resolution instead of my ISP's.

                                    I was also able to get my Linux box connected to the VPN with DNS resolution working there also.

                                    Functionally this is all that I was looking for and it's working perfectly. Very stable.

                                    Ok that's it. Just wanted to say thanks for all of the invaluable knowledge on this board from the contributors in this thread and the many others that I read through as I worked through my issues.

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