Inbound OpenVPN port forward no response
-
Hi all - I've got an inbound port forwarding problem that I believe may be caused by asymmetric routing. However, I don't know how to solve that so am hoping someone here can guide me.
I have a port forward configured at my VPN Provider (OVPN) on port 51203. I have created a NAT port forward on pfsense listening on port 51203, and forwarding to 192.168.4.226 on port 51203 (for simplicity), with an auto-created firewall rule on the LAN interface. I'm running a simple Python web server there that listens on port 51203 (python -m SimpleHTTPServer 51203).
Outbound traffic from my network to my VPN provider is controlled by policy-based routing, using an Alias group and a firewall rule on LAN to route all traffic from hosts in that group to the VPN gateway.
I am testing whether the port is open using https://portchecker.co/ and the IP public IP given to me by the VPN provider (obtained by running curl -4 http://icanhazip.com).
Portchecker says port 51203 is 'closed', and I do not see any logging from the Python web server.
Based on my Wireshark analysis, I believe that packets ARE making it into the network and hitting 192.168.4.226, but that the responses are not being correctly routed over the outbound VPN gateway. I have seen mention of this elsewhere as 'asymmetric routing', and it perhaps being due to an 'overly broad' firewall rule under the OpenVPN tab. I do have an OpenVPN server configured on my pfsense to give myself access to the network when I am not at home.
Screenshots of the above are in this imgur album
Any help would be greatly appreciated!
-
This post is deleted! -
@endian675 said in Inbound OpenVPN port forward no response:
I have created a NAT port forward on pfsense listening on port 51203, and forwarding to 192.168.4.226 on port 51203 (for simplicity), with an auto-created firewall rule on the LAN interface. I'm running a simple Python web server there that listens on port 51203 (python -m SimpleHTTPServer 51203).
You have added the port forwarding to the WAN interface, but you need it on the specific VPN interface for this provider. Since you have set up multiple OpenVPN interfaces, I don't know which , guess OVPNAMS.
So move the NAT rule to this interface and ensure that the associated firewall rule is moved as well.Additionally you have to remove the pass rule from the OpenVPN tab.
If you need inbound traffic from other OpenVPN connections (obviously you are running a server) assign an interface to these OpenVPN instances and add the rules to them. Or modify the OpenVPN rule so that it is not applied to the forwarded incoming traffic. When running a server, you can simply set the source to the tunnel network and clients can still access anything. -
@viragomann Many thanks, I made that change (probably it got moved to WAN when I was trying to troubleshoot). Once I also disabled the rule in the OpenVPN tab I could reach the port - thank you!
I didn't quite follow your remarks about how to configure the server for inbound traffic, could you maybe elaborate a bit for me please?
-
@endian675
Okay, the whole story: As you realized, it is necessary that response packets to incoming requests from public sources over the VPN provider connection is routed back to the VPN provider. By default pfSense as well as other network devices routes the packets accordingly to its routing table. However, this says that the packet should be routed to the default gateway (WAN). There is no other proper route for these traffic.To route response packets back to the correct gateway, pfSense marks incoming (requests) connection with the 'reply-to' tag, which includes the gateway, responses have to be routed back. This is done by the pass rule, which allows the traffic in.
This understandably requires that there is a gateway assigned on the incoming interface and that the gateway is absolutely unique. Response packets from inside devices are recognized as belonging to the tagged connection and are routed out to the proper gateway.But the OpenVPN tab is indeed an interface group. It is added automatically by pfSense, when creating an OpenVPN client or server and includes all OpenVPN instances. It cannot be removed manually.
Interface group rules are probed before rules on (included) interfaces. So they have priority and if the rule matches no other rules are probed anymore. The same is true for floating rules. Also floatings can include multiple interfaces and hence the gateway is not unique and reply-to is not tagged.So you have to ensure that no floating rule and no one on the OpenVPN tab matches the incoming traffic.
Now, if you're additionally running an OpenVPN access server you have two options:- Let's say the server tunnel network is 10.8.0.0/24. So clients which connect, get an IP out of the tunnel pool. To allow the clients access to any, you can simply limit the source in the OpenVPN tab rule to 10.8.0.0/24. Hence the rule will only match to incoming traffic from your clients, but not to forwarded traffic from the OpenVPN provider, since these sources have public IPs.
- Remove all rules from the OpenVPN tab and assign an interface to the OpenVPN servers instance. Then you get a unique rule tab for the server, where you can add needed rules for client access. These are only applied to the clients then.
-
@viragomann Thanks so much for the detailed and very clear explanation.
-
@viragomann Thanks from my side as well... I've been struggling with this exact same problem and the firewall rules underneath the OpenVPN tab were the problem for me as well.