Openvpn Open Port

[Carmina Piette]

Iam trying to open specific ports for users so that they can use programs such as RDP. I have searched all over the internet, and have yet to find an answer to this question. I have tried every iptables rule in the books, and it still seems to fail. Do I need to use a specific interface to open ports for VPN users?

I'm not sure whether I understand your question correctly. VPN clients need certain TCP port to be opened (1194 on OpenVPN by default). Probably you need to set up a redirection of this port to your OpenVPN server on your border router/firewall. Somewhere in port forwarding settings you'll need to redirect incoming traffic to this specific port on your OpenVPN server.

If you're not sure which port you should open, examine configuration files for server and clients. netstat tool on client side can help you determine which ports are needed to establish connection and are probably closed.

I'm trying to implement a VPN.

I read about configuring VPN servers on Windows (built-in), and also several 3d party software like OpenVPN etc. But all these require a port to be opened in the router for VPN in order to work - but opening a port could expose the server to hackers.

So does VPN itself have protection for this open port, or even with VPN the server can be hacked?What is the solution?

Ports are not "in danger". One cannot attack ports. One only attacks services running on those ports. (Much like you can call a phone number but you aren't talking to a phone number, you're talking to a person behind it, and it's the same person whether they have one phone number or five.)

My first comment is that many VPN clients DON'T require a port to be open (Servers arguably do), and that an open port in and of itself does not make the system vulnerable - any vulnerability will come down to what can be done through the open port.

Provided the VPN implementation is robust the only advantage an open port gives to an adversary is the knowledge that there is some kind of device offering some kind of service (and probably indications of the kind of VPN running on it). Thats it. It does not give any kind of foothold into the system at all.

If you are running a VPN server and are concerned about this there are a few ways you can mitigate even the above issue. Look at "Port Knocking", which can be a way to keep the port closed until a hidden series of packets are received by the router (and the router does not need to respond to these). You can also limit the IP's/ranges that can connect to the VPN which can significantly cut down on the likelyhood of the VPN server being probed. In a similar vein, you could always run a web server and require a specific URL on a different system - possibly on a different network - to be hit which could then be trusted to send an instruction to open up the VPN port to the appropriate IP address.

Another approach might be to spin up a basic server/VPS (eg AWS EC2 instance), and have your VPN "servers" all connect as clients to that instance. In that way the actual VPN endpoints are not directly reachable except throuh the VPN server - which can be locked down as above.

First of all, in everything security related, you should start assuming everything CAN be hacked. And, if exposed on the internet, your service WILL be probed every day. This isn't meant to be scary: it is just what you see as soon as you put something online. You're goal is to minimize the risks...

The first choice I think you need to make is: who will manage this service? It could be you, but this is not the only option. Anyway, if your hosts's security is worth something you should ask yourself if you can really do it by yourself or trust a professional/service.

Back to the "ports"... There is nothing wrong with an open port: it is just the way the service "listens" to requests. You need to focus on using a secure software (ie. openvpn) configured in the right way.

I've run into a bit of a puzzle and haven't had much luck finding a solution. Right now I am (sadly) connected to the net via Verizon 3G. They filter all incoming traffic so it is impossible for me to open ports to accept connections.

I currently have a Linux virtual machine at linode.com, and the thought crossed my mind to install pptpd and attempt to do some iptables port forwarding. I have pptpd installed and my home machine connects happily. That said, here's some general info:

I have tried at least 20 different Googled up iptables configs and none have worked yet. Does anyone have any ideas, or perhaps even a totally different approach I might not be aware of? The goal here is to listen through a horribly firewalled connection, preferably both TCP and UDP traffic.

The reason you need the SNAT is because otherwise your VPN client will send its return packets straight to the host which initiated the connection (z.z.z.z) via its default gateway (i.e. Verizon 3G), and not via the VPN. Thus the source IP address on the return packets will be your Verizon 3G address, and not x.x.x.x. This causes all sorts of problems, since z.z.z.z really initiated the connection to x.x.x.x.

For each client you have to create a file. The filename must match the common name attribute that was specified at the certificate of the client. This command gets the CN from the computers certificate:

What you want to achieve is (probably) very possible with pptpd or OpenVPN and iptables, however, you might find tinc a better candidate for this use case. I just read this which describes how to setup tinc for exactly this use case. It's a (potentially simpler) alternative to the pptdp or OpenVPN part. Then you'd need exactly the same rules for iptables.

I want to be able to reach my 44158 port from the public network, so I have a purevpn connection between my MR3420 router and the VPN server (through my other ASUS router).

I purchased and configured port forwarding in purevpn, and I can see it working when i connect from a pc to the vpn server and host a server on this port. But for some reason it is not working when I try to use the OpenWrt router.

Did you test all 3 of the ports with that PC? This suggests that the VPN itself isn't an issue... but have you verified that locally probing the forward-to hosts shows that the ports are open and listing for inbound connections?

What is the default gateway for your OpenWrt device? If the default gateway is actually 192.168.1.1 (the upstream router), the issue is actually related to the fact that the request comes in via the VPN, but may be egressing towards the normal upstream gateway (192.168.1.1) and therefore getting lost.

You may need VPN Policy Based Routing to get this to work with the current topology. There may be other topologies that could be used, but I don't know if there is a specific reason you have it setup this way and how the VPN is being used.

Hmmm... Have you verified that the public IP as seen from behind this router matches the public IP you expect on the port forwarding from the VPN provider? (google "what's my IP" from a machine behind this OpenWrt router).

Also, have you checked to make sure that the IP address that is assigned to the OpenWrt router (via the OpenVPN connection) is the same as the port forwarding (from the VPN provider) is pointing too? It is possible that your router and your PC were assigned different IP addresses from the OpenVPN server.

Then, if you google "what's my IP" from a computer behind the OpenWrt router -- it will display the apparent public IP of your connection (which should be a public IP from your VPN provider). Does it match the expected public IP that you are using when you attempt to connect remotely (i.e. when not on your own network)?

Did you reset your router? Make sure the OpenVPN service is still active on your router. If that doesn't work, go through the OpenVPN setup process from the beginning again on your router, and re-download the setup files to your client.

When you go through the process of enabling the OpenVPN service on the Orbi, that should open the necessry ports. The details are written to a config file that needs to be loaded on your client machine.

here is a pic of my vpn settings i have tried changing port num, or even port types! when i switch to tcp and connected via my wifi (locally) it works if i get off it and switch to my cellphone LTE, it doesnt connect!! so something is blocking my ports as i suspected and yes i download the new config files each time i have changed the settings but still doesnt connect.

OK. I don't think I can do anything else to help you out. All I can do is suggest you go back to using standard ports and protcol (UDP 1194) and redo the VPN setup from scratch. You said it was working before you changed things. The nonstandard ports could be part of your problem. Good luck.

a situation i used to always run into in the past was: i needed to set up a new infoblox device or ha pair, and the grid master and grid master candidates were in different datacenters/locations and there were one or more firewalls between them. i would submit firewall rules, then hope they were implemented correctly, waiting for the stated time to try my grid join and hope it worked. then, if it didn't, trying to figure out for sure if it was a firewall issue or something else.

i always wished infoblox had an option somewhere to "test" grid communication in some way, just to verify the lines of communication were open without doing the actual join at that point. but they didn't. (and don't, that i'm aware of.)

at some point, i became aware of the expertmode option, and access to the new/different command line tools that mode provides. using that, i was able to figure out a way to test/verify connectivity to the grid master.

caveat: the device must not be already joined to a grid. if the new device is already joined to something, then the openvpn udp ports (at least 1194) will already be in use so this trick doesn't work.

so here's what i do now to verify the firewalls are opened properly, well in advance of my implementation date, so i can follow up with the firewall teams to get things fixed before the join date and time arrives...

3a8082e126