openvpn client can ping LAN but cannot TCP connect
-
I followed this guide: https://www.wundertech.net/how-to-set-up-openvpn-on-pfsense/
I have two clients that can connect via a mobile hotspot. Prior to connection they can't ping 192.168.6.anything (LAN subnet) or 10.0.8.1 (the openVPN subnet). I then connect and they can ping both, so the VPN part is working nicely.
I cannot make any TCP connections from an openVPN client to a LAN client. I've enabled the firewall rules to allow this in the wizard and they are shown in the firewall rule listing.
When I test a TCP connection and then look at the firewall logs I see errors like this one:
Default deny rule IPv4 (1000000103) 192.168.6.5:8123 10.0.8.2:48124 TCP:FA
I've tried the "automatic fix" recommended here: https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html#automatic-fix it did not work
I've tried the manual fix on the allow all IPv4 rule on my LAN firewall interface where I allow all TCP states and "Sloppy", that didn't fix it.
I've tried having the openVPN be assigned the OPT2 interface, that didn't seem to resolve it. I did that like this https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/assign.html#interface-assignment-and-configuration
Strangely I don't see the client listed in the openVPN connections list even though they ping other LAN IP addresses well....
What am I missing here?
-
@bmbouter said in openvpn client can ping LAN but cannot TCP connect:
What am I missing here?
There are thousands of web sites out there talking about 'how to'.
I advise you to start with the one made by the authors of pfSense.
You can find them here : https://www.youtube.com/@NetgateOfficialYou'll find also the Configuring OpenVPN Remote Access in pfSense Software
which explains how to set up, from a default pfSEnse, a working VPN access in less then 5 minutes.Again : can't tell if the video you used is good, or no good (I won't test them all ^^)
When you activate a VPN server, you wind up having a system created "OpenVPN" interface :
Leave that one empty.
Create your own OPENVPN (pick any name), and assign the openvpn server to it :
and then add the rules that will work fine :
Note that I defined Gateways, that's normally not need - just create pass rules and you'll be fine.
Note that I used IPv4 and IPv6 as my OpenVPN server setup supports both, because ... why not.When I test my OpenVPN access, I can see that the states are changing == the rule is used.
Btw : what is you pfSense version ?
Do you know what openvpn server version you use ? Hint : as always, check the openvpn server the logs ^^
Now, check you openvpn client software : it is based on what version ?For example, it's ok to use the 2.5.x version on the pfSense side, and a 2.4 (ancient) client openvpn on the other, but then you have to go through all the details of the release differences - seen here : https://openvpn.net/community-downloads/
-
I finally got a chance to test this. I totally remove the setup I had before, and I followed the video you linked to (thanks) exactly. However, I get the same result only now my openVPN subnet is 192.168.80.0/24.
The vpn itself is working fine. Any device I want can connect and get a 192.168.80.0/24 address. Any 192.168.80.0/24 IP can ping a 192.168.6.0/24 and vice versa, so the connectivity is there.
I'm using pfsense 22.05-RELEASE, openvpn server is OpenVPN 2.6_git armv7-portbld-freebsd12.3 (what came with my pfsense). I've used several clients for example latest openvpn android, and OpenVPN 2.5.8 on linux.
-
When I try to http connect for example between 192.168.80.2 (the vpn client) and a 192.168.6.0/24 address, I see these messages show up in the firewall around that time with the port numbers of the 192.168.6.0/24 I'm trying to tcp connect to:
That is extremely strange because I have this in my LAN firewall:
Why is the traffic being dropped?
-
@bmbouter said in openvpn client can ping LAN but cannot TCP connect:
Why is the traffic being dropped?
The traffic dropped on the LAN interface is traffic initiated by a LAN device, on the LAN network.
edit : but wait, see below.Your LAN interface is 192.168.6.1/24, right ?
The firewall rule show a connection from a LAN (source) 192.168.6.5 device port 443 ( ? ) to 192.168.80.2 device, the device you use to connect to the OpenVPN server.
Normally, it's the other way around.
I use my phone or portable PC to connect to the pfSense OpenVPN server, so I can connect to the pfSEnse GUI or my NAS, or printers to do some maintenance task.
You have your device connect, and the you initiate a connection he other way around ?And yes, I confirm, your LAN firewall rules permit any outgoing traffic.
The blocked TCP:A means to me : the TCP ACK packet send back doesn't make it back and is blocked, like it its not part of the a current state, initiated from an openvpn connect client (which would explained the reverse source destination).The state-full firewall isn't state-full anymore ?
What rules do you have to the OpenVPN network ?
Remember : the OpenVPN is like a LAN interface : it should have (TCP and UDP) pass rules, or no devices connected to it can use the OpenVPN interface == OpenVPN access. -
@gertjan There are several very strange aspects to this. Here is what I've observed.
The testing in this case is always initiated by the openVPN client. For example I would use an android device via LTE (openVPN connecting to the WAN IP) to receive the openvpn assigned IP of 192.168.80.2. Using an android network utility app, I can successfully ping various hosts on 192.168.6.0/24. I can also port scan 192.168.6.0/24 hosts and receive the expected results in every case. I can also run use telnet to TCP connect to an http webserver on 192.168.6.5 port 8123 and I receive response headers ... but I receive no body in the payload.....
When I use a web browser from 192.168.80.2 to connect to https://192.168.6.5 the page doesn't load and the firewall shows those dropped TCP:A packets. So the connection is initiated from the openVPN client, hence the destination port of 443.
Yes 192.168.6.1/24 is my LAN address.
My OpenVPN firewall rules were auto-created, but then I made it both IPv4 and IPv6 while troubleshooting it. Here's a screenshot.
It's like the statefulness of this firewall is totally screwed up. What's especially strange is I run pfsense on official netgate hardware, it's a SG-3100 MAX. I also only ever run the software provided by netgate.
I can see my client listed in the openVPN connections, see this screenshot.
Also I can see some stateful connections being created in the openVPN firewall...
-
One more thing, I can confirm all the same behavior on my laptop acting as the 192.168.80.2 openvpn client. It's connecting via the WAN through a hotspot LTE connection.
Here's a screen shot of some pings, ifconfig, ip route, and then the telnet demo
-
@gertjan said in openvpn client can ping LAN but cannot TCP connect:
The traffic dropped on the LAN interface is traffic initiated by a LAN device
no that is ack trafffic - looks like asymmetrical or the states were cleared on pfsense.
-
I think it's got to be some sort of asymmetric issue. What would I look at to investigate that?
I think it's not a pfsense firewall being cleared during testing because a) I'm not clearing it and I'm theonly admin and b) if I try the test a few hours later I get the same results. Just before retrying the test later I confirm the openVPN has no sessions on it. That being said maybe I should try clearing the sessions of both the LAN and WAN? I do have my clients when testing on my LAN just before disconnecting and joining the openVPN over the WAN.