Another "Cant Route LAN Traffic" post - My apologies
-
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.254I'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
-
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.
-
i just make the default gateway in the firewall under the openvpn tab correct? what's the static routes way?
-
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.
-
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.
-
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.
-
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.
-
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?
-
If the packets are routed out to the WAN maybe your LAN interface setting is wrong. Check if the network mask is set correctly.
-
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.
-
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.
-
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 re0Those 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!
-
The 172.33.range address you are using are public addresses which could be on-line or off-line. Duplicate ip address.
-
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.
-
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!
-
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.