Guys, I need your help .
This is the situation:
> [remote pc which is
> trying to
> ssh to PC01]
> [ the evil internet ]
> [VPN dedicated ip]
> port 60022 opened
> ssh server port22
As you can see I’ve subscribed to a vpn service which provides a dedicated ip and requested to open the tcp port 60022.
On the router I’ve successfully configured the openvpn service and everything seems to work just fine.
Now I’d like to connect through ssh from remote pc to PC01 and here’s where the trouble begins: on the router I should setup port-forwarding and firewalling to allow the connection from the vpn service but it doesn’t seem to work.
Here’s what I’ve done:
Is there something wrong with these settings?
Not clear what do you want to do. Do you want to ssh to your PC? Why do you configure openvpn port forward to ssh port?
Yes, that’s what I want to do: connect to PC01 using ssh from a remote PC connected to the internet.
The route that I would like to follow: I’m on a remote pc connected to the internet → I connect to the vpn server with dedicated ip and port 60022 opened → (this is the tricky part) the router forwards the port 60022 from vpn to port 22 on PC01 → I get ssh access to PC01
How should I configure the firewall and the port forwarding on the router to accomplish that?
Is 60022 actually NAT forwarded to your device when you connect (on the openvpn server)?
I would think you should be able to run nc -l 60022 on your router and then from outside nc 60022 to connect
Once you have that you need to forward it to your PC.
Sorry man, I’ve limited knowledge about networking, could you please explain that in more detail?
From what I know I’ve asked to the vpn provider to open the port 60022 and I can check that on the control panel on their site:
Edit: every time I try to connect from the outside I can see that the number of packets increases of 2 units and the KB usage increases as well.
ok so on the router run nc -l 60022 … it will sit and listen on that port
from the internet - run nc yourvpublicvpnip 60022
this will create a connection from the internet to your router on port 60022 and if you type things it will show up on the terminal that has the nc -l 60022 running.
if that works. then the packets are getting to your router. then you can go about setting up forwarding from your router to the PC
if not you have have to figure out why the port isnt getting to your router.
Ok, thank you very much for being more specific.
I’ve tried the nc command and it works as expected, so one step forward has been made:
root@GL-MT300N-V2:~# nc -lvp 60022
listening on [::]:60022 ...
connect to XXXXXXX:60022 from XXXXXXX
does it work?
Now, how can I setup forwarding from router to pc02?
The rule that I tried to add (second pic of the first post) doesn’t work
I draw a topology diagram, as you can see, you want to ssh from PC0 to PC1, right? If it does, I think it is nothing with vpn, it merely need to configure port forwarding on GL-MT300N-V2.
An example for port forwarding:
Yes, that’s my situation, except all the traffic going out of the router goes through the vpn.
But are you suggesting that the vpn doesn’t matter for the port forwarding?
Sorry if I may ask dumb questions, but I’m a noob
Yeah! In this case, it is nothing with vpn. Using ssh from PC0 to PC1, it is incoming traffic.
I’ve added the following rule but still no luck
Allright because of the frustration I decided to reset the router and start from scratch.
Now adding the following line for the port forwarding works:
Thanks to everyone who helped me
You were SO close! I spent a couple of days trying to figure this out as well - the external zone needs to be the one the VPN client is assigned to instead of WAN (will be something like vpn_client or OVPN - this actually won’t show up until the VPN client is connected, so be sure and do that first). That should get things working (Unless I see that since you are using the 10.X.X.X addressing scheme there could? be a problem where since the VPN service uses an address scheme of 10.X.X.X for its private IP addresses, your local LAN IP may possibly need to be something different if the subnet overlaps at all (could change to, say, 192.168.X.X).
Finally, something I noticed is that this type of forwarding only works when the internet is coming from the WAN (which is usually the case - so in the case of an upstream router providing the internet, this mini router’s WAN would be connected to the upstream router’s LAN - I know you know this but just in case for anyone else reading).
I learned this the hard way, as I setup the same thing with my mini router connected to the upstream router LAN to LAN (with the DHCP server turned off on the mini router, and the LAN IP using a different IP address outside of the DHCP range, but using the upstream router’s LAN IP as its gateway - all clients were being handed the addresses from the upstream router), and the VPN would connect (as a matter of fact, if you statically used the mini router’s LAN IP as the gateway on a client device in that network it would go through the VPN, but if you used the upstream routers IP as the gateway (what DHCP handed out) you would be connected natively.
The lesson on port forwarding was that when it was setup this way (bypassing the WAN) it would only forward to the IP address of the mini router itself, but no other devices on the LAN (they would time out). When I reconfigured and put the internet coming through the router’s WAN port, forwarding worked to any device as expected - all I had to do was connect the VPN client and then add the rule in the same place you did using LuCI (Network>Firewall>Port Forwards) coming from the VPN’s assigned zone (instead of WAN), and it worked by default without changing the settings of any of the other zones or rules, or anything.
EDIT: And I see that you figured this out yourself after doing my writeup! I’m sorry - I completely overlooked that only noticing the WAN box. I will leave my post up to detail the other experiences, but with the forwarding line you have working I see that you’ve added it from “VPN_client” instead of from WAN and it worked.