OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2)
-
It looks to me like AIRVPN's tester is attempting connections to both the tunnel address AND the address you are connecting from. They might use this to catch cases where people have passed/forwarded traffic on WAN but not OpenVPN. Just a guess since I am not AIRVPN.
There is really no other explanation for SYN traffic arriving on both interfaces. As I said, pcaps don't just conjure up phantom traffic and present it.
Your replies are likely being sent out WAN because your OpenVPN rules don't take into account what needs to happen when you receive connections from arbitrary addresses. You probably want to delete/disable all of the rules on the OpenVPN tab and pass the traffic on the AIRVPN tab instead. This will get reply-to on the states and force reply traffic from the bittorrent client back out the VPN where the connection came from instead of obeying the routing table and sending it out WAN.
-
@derelict said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):
Post your OpenVPN firewall rules and your AIRVPN firewall rules.
Outbound from LANGroup to OpenVPN interface
Inbound firewall rule on AirVPN
Port forward NAT rule
Outbound NAT rule
OpenVPN client status
-
Great. And the rules on the OpenVPN tab?
-
@derelict said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):
Great. And the rules on the OpenVPN tab?
OpenVPN (Although I believe this was created for my road warrior setup - OpenVPN server)
OpenVPN Server (if that matters)
-
Yeah. The port forward traffic cannot match that, which it does.
That means you do not get reply-to on the states.
I would assign an interface to the road warrior instance, put the pass any rule there, and put no rules on the OpenVPN tab and it will work.
-
@derelict said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):
Yeah. The port forward traffic cannot match that, which it does.
That means you do not get reply-to on the states.
I would assign an interface to the road warrior instance, put the pass any rule there, and put no rules on the OpenVPN tab and it will work.
Thank you so much, I am i awe that you figured this out with the little bit I gave you. It is working now! I am so impressed!
I don't fully understand why, but I did as you said - I created a new interface for what my setup has as "ovpns2", removed the allow all rule under OpenVPN and tested again. Success. Why would the default OpenVPN interface interfere?
New Interface
Road warrior rules:
OpenVPN (removed the only rule)
-
Because the OpenVPN tab really represents an interface group of all OpenVPN instances both server and client.
When a connection arrives into that it is impossible for pf to know which one it will arrive on so it cannot apply reply-to to the rules there. When you are accepting connections in from locations that your local OpenVPN knows about (has specific routes to), like in a remote access or typical site-to-site configuration, this does not matter because the routing table (and openvpn) will route the reply traffic where it needs to go.
When you are accepting connections from arbitrary source addresses, you need reply-to on the rules or the routing table will direct the reply traffic which, to an arbitrary destination on the internet, will probably mean it tries to send it out to its default gateway.
And, like most everywhere else in pfSense, first match wins and stops rule processing and interface group rules are processed before interface rules so traffic that needs reply-to cannot match rules there.
-
Just want to add I was having this exact same problem and this was also the solution for me. My remote VPN access however was not working after I moved it to it's own interface and added the new FW rule for that interface. I had to reboot pfSense for it to work. I could connect but no traffic would flow back to remote device. I believe a state just got hung up somewhere and the reboot cleared it.
-
The OpenVPN instance has to be restarted after an interface is assigned. This is in all of our documentation related to assigning OpenVPN interfaces. A system reboot was likely not necessary.
-
Your right, I recall that now, that's what I get for troubleshooting at 5AM.
