Port Forwarding w/ OpenVPN Tunnel - What am I doing wrong?
-
@techboot said in Port Forwarding w/ OpenVPN Tunnel - What am I doing wrong?:
These are my current OpenVPN Client (towards the VPN Provider) Settings... I was under the impression that I wanted the "Dont Pull Routes" checkbox selected, since that would otherwise set the default gateway for the whole router towards the VPN provider.
That's correct. You don't need routes, since you do policy routing for outbound traffic.
Edit: this is the documentation pertain to port forwarding from the VPN provider: https://airvpn.org/faq/port_forwarding/
There is nothing mentioned, that the provider does masquerading as you stated above.
If he doesn't masquerading you need to enable reply-to for proper reply-routing.For a quick test if this is the issue, remove the "Don't pull routes" check, ensure that the VPN is shown as default gateway in Status > Gateway, then test the access.
-
Will try shortly.
To clarify, this is the only information that shows how they (provider's port check tool) works.
To me, that's public -> pfsense (as VPN client 10.65.138.204) -> LAN client (10.13.31.22)
-
@techboot
I don't expect, that the provider knows your LAN clients IP. -
You make a fair point. I should have been more specific, but I added my LAN client IP for completeness. Apologies there.
However, with the test by disabling the don't pull routes .. success
Understandably now my whole LAN is out the VPN, but how would I set reply-to for the proper routing as you mentioned?
-
@techbooties
You need to remove the pass rule from the OpenVPN tab.If you are running an OpenVPN server come back with the info to elaborate, how you get access then.
-
I am using an OpenVPN server. I will try and specify my setup specifically for you.
I have a single LAN. No VLAN's. I have a few machines in my homelab, one is (10.13.31.22).
I have a primary internet connection, which should be used for all of my clients, EXCEPT those that are in the "VPNAccess" alias group. In this case, only 10.13.31.22 is listed.
I have a VPN provider connection with a third party (airVPN) via the pfSense router, that I would like the members of VPNAccess alias group to use as their primary means of internet access. I would also like to use port forwarding with the VPN provider towards specific members of the VPNAccess alias (10.13.31.22 specifically).
I have an OpenVPN Server, which I use for remote access to my home network. (ipad, raspberry pi remote backup, etc.) It is using only my primary internet connection. It's on the pfSense box directly, not via some other machine behind the router.
-
@techbooties
If it's an OpenVPN access server limit the source in the OpenVPN pass rule to its tunnel network. -
wow. that worked!
I changed the rule as you noted, 10.13.30.0/24 is my VPN net:
I even killed the client, requested a new IP from another server and still works:
Can I ask why that made such a difference? Was it related to all being OpenVPN based connections?
Thank you!!!
-
@techbooties said in Port Forwarding w/ OpenVPN Tunnel - What am I doing wrong?:
Can I ask why that made such a difference?
In fact you have two WANs with inbound traffic. You real WAN and the VPN_WAN.
In this case pfSense need to tag incoming connections with the reply-to, which includes the gateway assigned to the incoming interface. This is done by the filter rule, which allows the incoming packets.
Without this, pfSense would send respond packets to the default gateway, regardless which interface the request did enter.However, that the reply-to is applied requires that the concerned rule is defined on the interface tab. It doesn't work on interface groups and floating rules.
But the OpenVPN is an interface group in fact. It appears in pfSense, when you run either an OpenVPN server or a client and includes them all.
AND both, interface group and floating rules have priority over interface rules by design. Hence there must not be any matching pass rule on theses tabs.The reply-to would not be necessary if the provider masquerades the traffic to the server IP, since this is within an assigned subnet.
So it was misleading that you mentioned, the provider does masquerading. -
Thank you again. I assume that this also would explain why I did see some kind of traffic with the port sniffing. Apologies for the confusion, my ignorance with assuming masquerading certainly didn't help. Lesson learned!