Port Forwarding w/ OpenVPN Tunnel - What am I doing wrong?
-
@techboot
It's local IP.Edit:
also flush the states after adding the rule. -
No change. To confirm:
NAT:
Outbound NAT:
Rules (VPN Interface)
VPN Provider Port Check Tool: (Note, telnet to the public IP from an outside IP (ie: an Azure VPS, yields the same result)
--
In an effort to maybe make this easier, should I delete this thread and re-make it? I will remove all of the rules, NAT, etc.. reboot for good measure and start over with all of the details / information in one post based on your feedback and comments thus far?
-
@techboot said in Port Forwarding w/ OpenVPN Tunnel - What am I doing wrong?:
NAT:
And the mess goes on...
10.13.31.22 is your VPN interface address. The NAT IP has to be your internal server IP!Also you should limit the destination IP. Your may set it to the interface address.
-
-
@techboot
Ah ya. So you need to edit the outbound NAT rule and correct the destination IP. -
Cleared States.
--
--
I am confused what you mean by limit the destination IP and limit to the interface address. I assume you mean on the port forward tab?
-
@techboot said in Port Forwarding w/ OpenVPN Tunnel - What am I doing wrong?:
I assume you mean on the port forward tab?
Yes.
In the LAN outbound NAT rule correct the translation to interface address, please, which is the default setting.
-
I think I have now gone and confused myself in all of this. Thank you for bearing with me.
Like this?
-
@techboot
destination: internal server IP with /32 mask
translation: LAN address -
-
Question on this...
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.
In my case, I want to only route specific IP's out via the VPN, which DOES currently work.
Could this actually be some of my port forward issues?
Edit: this is the documentation pertain to port forwarding from the VPN provider: https://airvpn.org/faq/port_forwarding/
-
@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.
