VPN -> LAN (OK) | LAN -> VPN (OFF) need both working
-
OK so no ICMP packets at all there. But those were all inside 0.2 seconds so maybe it wasn't running long enough?
What IP address on LAN were you pinging from?
What we can see there though is that OpenVPN clients are able to connect to hosts on the LAN and they are able to reply. And importantly that there is no NAT. The OpenVPN tunnel IPs appear directly on the LAN.
-
@stephenw10 This test I showed you is from the packet capture of PFSENSE itself for the IP that my clientOPENVPN is getting 50.50.50.2
-
So you didn't try to ping from LAN host?
Repeat the capture but try to ping from a host on the LAN.
Pings from pfSense itself never go through the LAN interface to reach the VPN so would not appear in the pcap.
-
@stephenw10 It's in Portuguese, but it causes 100% packet loss
-
Ok and what does the packet capture show on LAN whilst that is running?
What IP address in the LAN are you pinging from?
What is 50.50.50.2 there? Another client device?
By the way 50.50.50.0/24 is a public subnet belonging to Frontier Communications. You should really use a private subnet for the tunnel.
Steve
-
@stephenw10 But packet capture where? in pfsense? You told me to use ping elsewhere, I don't understand
50.50.50.2 is another client device that
50.50.50.0/24 But the tunnel already uses a private subnet, doesn't it? -
You are saying that you need to be able to connect to OpenVPN clients from hosts in the LAN subnet and it is not working.
We are trying to find out why it's failing.
So to test that we are trying send ping traffic from a host in the LAN to a VPN client and then looking to see where it goes.
The first place it should hit is the pfSense LAN interface.
So the test is to start a packet capture on the pfSense LAN interface. Then run the ping and make sure it arrives there.
If it doesn't arrive then the issue is on the LAN host.
-
50.50.50.0/24 is a public subnet that should not be used here. BUT that is not the cause of the problem. It only means you could not connect to that subnet if you ever had to which is very unlikely.
-
@stephenw10 I pinged directly from my machine to an OPENVPN client and captured the packets from my PFSENSE LAN interface, with these settings:
Try ping 50.50.50.2:
-
Ok great. So the ping packets are arriving in the correct place. The client is not responding so either it can't respond (it's blocking them) or it never sees the pings.
Next try running the packet capture on the openvpn interface to make sure the pings are leaving the correct way.
You can also check the state table while that ping is running so make sure pfSense is open states on the correct interfaces.
Can I assume that if you ping the other way, from 50.50.50.2 to 192.168.140.57, it works?
-
If I am capturing ICMP packets from my OpenVPN Server interface, the same log that I sent you appears.
Yes, if I try to ping ip 50.50.50.2 to 192.168.140.57 it works normally
-
Ok if you see the pings leaving the OpenVPN interface the packets are almost certainly being blocked at the VPN client. A local software firewall on 50.50.50.2.
-
@stephenw10 But what could this be blocking? my rules allow everything
-
Its almost certainly blocked on the client device directly. So like Windows firewall, if it's a Windows device.
