OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2)
-
Probably be better if you more completely described exactly what you're trying to do.
What kind of VPN?
Who is forwarding the port?
What port?
Where is it supposed to be arriving?
How are you testing?
-
@derelict said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):
Probably be better if you more completely described exactly what you're trying to do.
What kind of VPN?
AirVPN, openvpn. pfSense is the client for the whole network
Who is forwarding the port?
AirVPN forwarding service.
What port?
TCP and UDP 63995Where is it supposed to be arriving?
QBittorrent client. AirVPN provides a public IP based on an exit node, and forwards a specific port TCP or UDP to the internally routed openvpn client IP.How are you testing?
Testing is done via AirVPN client area. I attached a screen capture,
-
There is no way that that test could result in the connection to 63995 arriving on your WAN unless the AirVPN tester is completely broken and they are connecting to your WAN address instead.
Or you are doing something strange like forwarding that inbound connection out your WAN and misreading the WAN pcap source address as the destination.
-
@derelict said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):
There is no way that that test could result in the connection to 63995 arriving on your WAN unless the AirVPN tester is completely broken and they are connecting to your WAN address instead.
I hear you. But every test I run through it, indicates that pfSense is doing something unusual with packet headers. This is a new situation - pppoe with vlan tagging. I suspect a bug. I opened a ticket with AirVPN, and through their own testing, this is what I see packet wise. pfSense / openvpn on my side is doing something unexpected. What do you suggest I try to diagnose this correctly?
Or you are doing something strange like forwarding that inbound connection out your WAN and misreading the WAN pcap source address as the destination.
Ok, that is also a theory, but I need some help to track / log this behavior. I know the NAT and firewall rules are sane, and known to work. The only difference is the PPPOE / VLAN WAN interface configuration
-
PPPoE and VLAN cannot make traffic arrive to that destination address.
What does a packet capture for TCP port 63995 on the OpenVPN interface look like?
Please understand we are not AirVPN support. What do they have to say?
-
@derelict said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):
PPPoE and VLAN cannot make traffic arrive to that destination address.
What does a packet capture for TCP port 63995 on the OpenVPN interface look like?
Please understand we are not AirVPN support. What do they have to say?
The packet capture falsely indicates the interface inbound. It is impossible for it to originate on the WAN. pfSense is doing something unusual here.
I don't expect AirVPN support here. They diagnosed, and I verified a few scenarios to confirm that. The issue isn't with them.
If I revert to using the Bell home hub 3000 in bridge mode, the WAN with PPPOE on it, all without the VLAN 35, it works.
I would share access to firewall for you to see for yourself.
-
The packet capture never lies. If you are capturing on WAN and seeing that, that is what is coming into WAN the firewall cannot generate traffic that comes into an interface. You should probably test again, tell us exactly what you are doing, and use full output from the packet capture page and post it up.
Again, capturing on the OpenVPN interface will show you what is coming over OpenVPN.
-
@derelict said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):
The packet capture never lies. If you are capturing on WAN and seeing that, that is what is coming into WAN the firewall cannot generate traffic that comes into an interface. You should probably test again, tell us exactly what you are doing, and use full output from the packet capture page and post it up.
Again, capturing on the OpenVPN interface will show you what is coming over OpenVPN.
I agree, it shouldn't be wrong.
Here is a capture going to the OpenVPN interface:
21:06:02.209139 IP 188.166.175.60.40277 > 10.11.8.9.63995: UDP, length 48
21:06:07.494078 IP 188.166.175.60.52338 > 10.11.8.9.63995: tcp 0
21:06:08.504706 IP 188.166.175.60.52338 > 10.11.8.9.63995: tcp 0
21:06:10.520798 IP 188.166.175.60.52338 > 10.11.8.9.63995: tcp 0I do another test, capturing on the BELL_WAN interface (not the WAN interface, but the virtual interface with PPPOE and VLAN35).
21:08:04.389707 IP 188.166.175.60.38336 > 69.159.103.101.63995: UDP, length 48
21:08:04.789811 IP 188.166.175.60.60580 > 69.159.103.101.63995: tcp 0
21:08:05.799557 IP 188.166.175.60.60580 > 69.159.103.101.63995: tcp 0
21:08:07.815525 IP 188.166.175.60.60580 > 69.159.103.101.63995: tcp 0
21:08:09.860945 IP 10.11.8.9.63995 > 188.166.175.60.52446: tcp 0
21:08:12.860513 IP 10.11.8.9.63995 > 188.166.175.60.52446: tcp 0The AirVPN test is strictly being sent to the OpenVPN interface IP of 10.11.8.9 in both cases. What explains this?
-
@steven-sl said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):
21:08:04.389707 IP 188.166.175.60.38336 > 69.159.103.101.63995: UDP, length 48
21:08:04.789811 IP 188.166.175.60.60580 > 69.159.103.101.63995: tcp 0
21:08:05.799557 IP 188.166.175.60.60580 > 69.159.103.101.63995: tcp 0
21:08:07.815525 IP 188.166.175.60.60580 > 69.159.103.101.63995: tcp 0It could be that your bittorrent client is actually making connections out WAN and asking for connections back on 63995 I suppose.
-
And if you would be so kind as to use full output so we can see what kind of TCP packets those are that'd be great.
-
@derelict said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):
And if you would be so kind as to use full output so we can see what kind of TCP packets those are that'd be great.
I have multiple devices that are routed through the openvpn connection. In the case of my QBittorrent, it is on my laptop, and by all indications I am going through an AirVPN exit node in Montreal.
My captures are done via pfSense - diagnostics, packet capture. Apart from the interface choice, only port 63995 is set. Let me know if there is a better way.
0_1548641933198_AIRVPN-packetcapture.zip
0_1548641940993_BELLWAN-packetcapture.zip -
Post your OpenVPN firewall rules and your AIRVPN firewall rules.
-
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.
