OpenVPN as WAN - Port Forwarding
-
Hi
Wasn't sure which category to put this under as it spans a few but I'll start here. I've purchased an OpenVPN package which includes a static IP address. The provider allows ports to be forwarded via their site so that inbound connections can be accepted via the OpenVPN tunnel. I've tested this outside of pfSense and am able to reach my network using the static IP I've been assigned so I know their routing is working OK (they provide a simple tool which opens a TCP/UDP port on which a dummy service runs to prove the service is reachable/listening).
The next step is to get traffic on that tunnel routed via pfSense to my internal services.
In pfSense I've added the configuration to the OpenVPN client settings and am connected to their server - outbound is working fine (e.g. I can route specific sites over that connection and if I redirect an IP checking site it returns my OpenVPN static IP so I'm confident outbound is working).
The provider has forwarded a range of ports for me on their side, but lets use 443 for now as that's the one I tested with their tool.
In pfSense I've created an interface with an IPV4 configuration type of "None" and a gateway which is configured as dynamic - this results in the interface within pfSense being assigned an IP address in the 10.58.43.X range.
What I now want to do is accept traffic on port 443 on my external IP address 213.183.XX.XX, have that land in pfSense (I presume ending up on the 10.58.43.X address) and then have that forwarded on to my internal service at 192.168.1.XXX where I have an IIS instance running.
In my port forwarding rules, I have the following;
The above rule matches the other two I have for WAN1 and WAN2 (which are PSTN/Fiber WAN connections) - both these accept 443 on their respective public IP addresses.
I'm clearly missing something, either a missing rule/rules or just what I am trying to achieve isn't possible - although I can't see why it would not be possible as the OpenVPN connection is simply another WAN connection unless I am oversimplifying things.
If anybody has any pointers I would be really grateful.
The rationale for doing this is that currently I am tied to one broadband provider who provide a static IP (which I need for email etc.) - if I can get the OpenVPN route working, I can choose any provider and always have the same public IP address follow me.
-
Is it worth posting elsewhere in the forums or is the above not possible?
-
Make sure the incoming traffic doesn't also match a rule on the OpenVPN tab.
If I was running something like that I would just delete/disable all the rules on the OpenVPN tab.
-
The rules on the OpenVPN tab are for my (pfSense) OpenVPN server - they allow inbound traffic to flow when I connect to my own server.
The NPVN tab is the interface of the external OpenVPN server (so NVPN is the OpenVPN client if you will). I've removed all rules from there but still no inbound.
I've made slight progress as if I hit the OpenVPN client IP, I now reach my IIS holding page, so the client IP is forwarding correctly, but not it's public facing IP.
Also, whilst connected to my OpenVPN server running on the pfSense box, the public IP responds to the traffic and redirects me to the IIS holding page, but externally this doesn't work and the ports show as closed on a port scan…I thought I'd cracked it until I realised I was still connected to my pfSense box :(
-
The rules on the OpenVPN tab are processed on ALL OpenVPN servers and clients before the rules on the individual assigned interfaces.
If you have liberal pass rules there they also apply to this client connection which should be treated as a WAN. You are probably passing too much traffic in from the "Internet" there.
You might consider assigning an interface to any other OpenVPN clients/servers and not using any rules on the OpenVPN tab at all.
-
Ah I didn't know that. Thanks for your help so far.
I've created a new interface and moved the rules to that new interface, so the rules now only apply to the client connections. The OpenVPN tab is now empty.
Still no inbound on the OpenVPN public IP though.
Here's the full set of rules I have set up for the NVPN interface (which has the private and public IP I'm trying to route over);
The above rules yield the following results;
-
Allow traffic to flow back out to the internet when I'm connected to the OpenVPN server hosted by pfSense
-
Allow selected traffic in the above tunnel to be routed back out over the internet via the external OpenVPN client
-
Shows the IIS holding page when I'm connected to the pfSense OpenVPN server, both on the private and public IP's of the external OpenVPN client
It feels now like the only issue is that the ports are not open to the outside world on the external OpenVPN public IP, but I've tried a couple of ways to do that and got nowhere.
Any idea's what I'm missing/doing wrong?
-
-
Managed to work it out, part of the issue is that the VPN provider, despite telling me they'd forwarded a list of ports I gave them, hasn't - so the only port which is working is 443 as I added that via their control panel.
The rule in pfSense was quite easy, I just needed the NAT/Port forward pair on the VPN interface to forward the traffic to the correct listening service - I'm sure I tried this before but perhaps I was using one of the ports which I'd assumed had been forwarded at their end but turns out they hadn't.
Thanks for your help Derelict.
-
Glad it's working.
There is another reason you have to have the rules not match the OpenVPN tab and only match the assigned interface tab.
When they come in passed by the assigned interface rule, the resulting states get flagged with reply-to so the reply traffic gets sent out the interface on which it arrived - back out the OpenVPN tunnel in this case.
If the traffic is passed by the OpenVPN interface group tab, there is no way for the system to know which interface it arrived on (it could be any interface in the group) so you don't get reply-to. The reply traffic will be sent according to the routing table which probably means it will be sent out WAN (and die there being out-of-state).
