Overclock.net › Forums › Software, Programming and Coding › Networking & Security › [SOLVED] OpenVPN Client Blocks Inbound Ports
New Posts  All Forums:Forum Nav:

[SOLVED] OpenVPN Client Blocks Inbound Ports - Page 2

post #11 of 26
i would try to see if you could port forward the tun0 also and see what happens with that.
Epic Rig
(9 items)
 
  
CPUMotherboardGraphicsRAM
AMD Phenom II X6 1090T 890FXA-GD70 (MS-7640) Radeon HD 5670 G. Skill 
RAMHard DriveHard DriveOptical Drive
G. Skill WD Green Seagate Samsung Blu Ray reader 
Monitor
i inc 28 inch monitor 
  hide details  
Reply
Epic Rig
(9 items)
 
  
CPUMotherboardGraphicsRAM
AMD Phenom II X6 1090T 890FXA-GD70 (MS-7640) Radeon HD 5670 G. Skill 
RAMHard DriveHard DriveOptical Drive
G. Skill WD Green Seagate Samsung Blu Ray reader 
Monitor
i inc 28 inch monitor 
  hide details  
Reply
post #12 of 26
Because your trying to tunnel to a pc which you don't have root access to. You must tell ppp too add the workstation to the table AND TO use the VPN. Then you must add your home network or the other pc where you Ssh from to the workstations routing table. A name is assigned and the port used for VPN. That port must fwd. It will not be 22. Did you look in the conf file of the VPN what its is?

Add this command
earth$ ssh -L 6669:localhost:6999

just add your own port.

The basic thing is you have to create a mirror on the server that is fwd. On the server remember your pc also got ports. It won't use the mirror if you just fwd the incoming connection because that's incoming. You have to set the VPN up to use the mirror where the SSH is connected. Configuring the router is incoming. It will just fwd it to the workstation. But you need to create a mirror which the port will be fwd otherwise another port will be used by the VPN
post #13 of 26
Thread Starter 
Quote:
Originally Posted by Thedark1337;13903521 
i would try to see if you could port forward the tun0 also and see what happens with that.

The problem with the tun0 interface is that it gets an address of 10.1.1.94, and my router can only accept a single IP address for itself, so the router cannot port-forward to the tun0 anyway.
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Apple Basic Keyboard Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Apple Basic Keyboard Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
post #14 of 26
Quote:
Originally Posted by parityboy;13904193 
The problem with the tun0 interface is that it gets an address of 10.1.1.94, and my router can only accept a single IP address for itself, so the router cannot port-forward to the tun0 anyway.

a VPN is for A private network. Are you using ssl VPN or Ipsec VPN? Are you using the build in VPN client?
Ipsec VPN is site to site. Which means its not mobile. Only those two computers can run that tunnel. That's what your doing I think. Ipsec is hard to setup.
Follow this guide.
http://www.symantec.com/connect/articles/zero-ipsec-4-minutes
post #15 of 26
Thread Starter 
@Spooony

No offence mate - I understand you're trying to help - but I honestly don't think you've read through anything I've written. You keep asking the same questions again and again, and I've answered them more than once.

I really can't explain my situation any more clearly than I have already.
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Apple Basic Keyboard Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Apple Basic Keyboard Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
post #16 of 26
VPNs work by creating a virtual tunnel over the public Internet. In order to create
this tunnel, symmetric encryption is used. Both sides of the tunnel share
common encryption and decryption keys and use them to encrypt all traffic in
both directions. Symmetric encryption is very fast and there are many solid
algorithms available to implement this (Blowfish, AES, 3DES).
OpenVPN tunnels traffic over UDP port 5000.
chroot /usr/local/openvpn {directory you want to “jail” OpenVPN to)This option will lock the OpenVPN process into the OpenVPN directory (or whatever you specify) and not allow it to access the rest of the system. Since you are connecting to a remote network you will probably need to use the route command to get traffic over the VPN tunnel. You will most likely have something like 192.168.1.x on one side of the tunnel and 192.168.2.x on the other side. This means you need to tell your routing table to use the VPN’s TUN/TAP device to access this private
network.route add –net 10.1.0.0/24 gw 10.2.0.1

OPen VPN replaces the old IPsec. You dont understand what I was telling you.

People hear SSL and immediately think of a protocol that encrypts traffic for an application, or for several applications, one at a time via proxying, application translation, or port forwarding. This is NOT a VPN. It is an application level gateway, a firewall, or an SSL gateway, but it is not a VPN. A VPN, or Virtual Private Network, refers to simulating a private network over the public Internet by encrypting communications between the two private end-points. This provides the same connectivity and privacy you would find on a typical local private network. A VPN device is used to create an
encrypted, non-application oriented tunnel between two machines that allows
these machines or the networks they service to exchange a wide range of traffic
regardless of application or protocol. This exchange is not done on an
application by application basis. It is done on the entire link between the two
machines or networks and arbitrary traffic may be passed over it.

Now why are you trying to ssh to the workstation and try to vpn back? VPN are not going to connect with ssh because of the certificates not there nor the exchange keys. You dont need ssh. Open VPN is Ipsec and SSL VPN. A site to site protocol
Edited by Spooony - 6/19/11 at 1:50am
post #17 of 26
Thread Starter 
@Spoony

You don't need to tell me what a VPN does, how it works or why I should use it. I know all of that already, which is why I'm using one. I also know the difference between SSL and IPSec VPNs.

Anyway, I'll explain my setup one more time. I have a standard residential Internet connection using a DSL router; I also have a static IP address.

My LAN is using the network address 192.168.1.x, and the workstation is addressable on the LAN side from other devices on the LAN such as the router, my Android phone and my laptop.

I've set up port forwarding on the router, so that when I am away from home I can get shell or desktop access to my workstation. This works fine (as long as the VPN tunnel isn't active).

The VPN tunnel (when it is active) starts at my workstation and ends at a commercial VPN provider, using OpenVPN (which is an SSL VPN). When the tunnel is active, the tun0 device gets an address of 10.1.1.94. It is masqueraded at the other end.

Problem:
The workstation is addressable from all devices on the LAN (router, laptop), whether the VPN tunnel is active or not.

However, port forwarding from the router's WAN interface to the workstation's LAN interface only works when the VPN tunnel is down.

I don't understand why this is the case. It can't be a routing issue...unless...could it be that the reply channel for an inbound TCP connection is actually being routed over the tun0 inteface, instead of the interface it arrived on (eth0)?

Could this be the case?
Edited by parityboy - 6/19/11 at 5:12am
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Apple Basic Keyboard Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Apple Basic Keyboard Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
post #18 of 26
Are you making use openVPN?

Let me explain this to you nicely it seems like everyone is making this mistake.

A VPN stands for Virtual Private Network. What that means its a secure encrypted tunnel from one machine to the other. That tunnel is a ssl tunnel. OpenVPN is Ipsec made easy or the so called replacement for it. It uses SSL/TLS (which is going to replace) ssl and Ipsec. its a site to site connection. That means you connect with your pc at home. or You connect directly with your workstation then its encrypted. That's a virtual Private Network. You connected to your workstation or otherway around with a encrypted tunnel.

Connecting to a proxy service to hide your ip and go on to the internet is not a VPN. That's a connectivity service. The Internet is not part of your private Network nor is someone else service. The connectivity service providers are using VPN to sell packages.

Now if you open up a browser on your workstation and go to any place that shows your ip that proxy service ip will show. That's your so called VPN service connected.

Now you are trying to Ssh a tunnel a network that you can't see anymore because its behind another ROUTER. The servers Of a connectivity service just act as routers. Routing your traffick thru it to hide your ip. that server that routes you are your ip adress not that adress on the router anymore. That's why when you disconnect the VPN you can see you pc with Ssh again. That router is gone and real ip is now visible.
If you want to see your pc from home with the VPN disconnected your going to tell the first router to port forward to your ip. Not all providers support server port forwards and if they do they provide the port numbers that you must use. So your going to Ssh to that port and your real ip will be visible to when connecting to that port. That's why you can't see the port because there's a second router (that of your "VPN PROVIDER" In the way and thats your pc ip.

If you use openvpn and you make keys for your workstation and keys for your home pc and you enter your homes pc in openvpn and the port you have a vpn then. A secure tunnel between your home pc and workstation. Do you understand now what I was trying to tell you?
Edited by Spooony - 6/20/11 at 6:35am
post #19 of 26
Thread Starter 
The difference being is that I'm not trying to connect to my workstation via the public IP address of the VPN endpoint. I'm trying to connect to my workstation from outside of MY LAN via the public, static IP address handed to MY router by MY ISP.

My router can see my workstation behind it and ping it successfully, so logic says that the router's port forwarding is working fine and that the issue is with my workstation's network interface.

The thing is, that very same interface is addressable from inside the LAN, so it's not as if it's suddenly lost its IP address. The data flowing through the VPN tunnel via tun0 will travel physically over the Ethernet card, but any data flowing onto the LAN will do the same via eth0.

I'm not trying to "ssh a tunnel". I'm trying to connect to my workstation via SSH for a remote session. Two completely different things.

Finally, all other services (such as web servers) for which I have port-forwarded from my router's WAN interface to my workstations LAN interface are also affected.

My "workstation" and my "PC" are the same machine.

EDIT:

Having re-read your last post, there are a few things that need to be clarified.

1. OpenVPN is an SSL VPN. This means that it tunnels IP packets through a TCP or UDP socket which is encrypted using SSL. This is not "IPSec made easy"or indeed anything to do with IPSec - the two technologies might make use of IP packets, but that's where the relationship ends. By the way, OpenVPN uses port 1194 - it no longer uses port 5000.

2. Secondly, my own home router does not disappear when the VPN tunnel is up. It's WAN interface is still addressable via its static IP provided to it by my ISP. I know this works because I've tested its remote management capabilities from outside my LAN.

3. So, to go over the points again:

a) My workstation is connected to my router via a single Ethernet connection with address 192.168.1.253.
b) My router is connected to the LAN via Ethernet, with an address of 192.168.1.1
c) My router can ping my workstation and vice versa
d) Other devices on the LAN, such as laptop and phone, can see the workstation and the router, and
connect to them via HTTP, SSH or other TCP/IP services.
e) My router remains addressable from the public Internet, via the static IP assigned to its WAN
interface, whether the VPN tunnel on my workstation is active or not. The router is NOT involved
in the tunnelling.
f) The VPN tunnel starts on my workstation and ends at a server owned by a commercial VPN provider.
They do not offer "proxies", and they do not provide my workstation with an Internet-routeable IP
address.

Finally, the port forwarding set up in my router, to provide a "hole" from the router's WAN interface to my workstation's LAN interface only connects successfully when the VPN is down. This should not be the case, since the router is not part of the tunnel, and in fact will see it as a standard TCP or UDP connection.

I suspect that the culprit is the routing table on the workstation. I think that the incoming connection is coming in on eth0 but the return channel is being routed over tun0, and therefore not back through my router.
Edited by parityboy - 6/20/11 at 4:40pm
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Apple Basic Keyboard Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Apple Basic Keyboard Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
post #20 of 26
Quote:
Originally Posted by parityboy;13940913 
The difference being is that I'm not trying to connect to my workstation via the public IP address of the VPN endpoint. I'm trying to connect to my workstation from outside of MY LAN via the public, static IP address handed to MY router by MY ISP.

My router can see my workstation behind it and ping it successfully, so logic says that the router's port forwarding is working fine and that the issue is with my workstation's network interface.

The thing is, that very same interface is addressable from inside the LAN, so it's not as if it's suddenly lost its IP address. The data flowing through the VPN tunnel via tun0 will travel physically over the Ethernet card, but any data flowing onto the LAN will do the same via eth0.

I'm not trying to "ssh a tunnel". I'm trying to connect to my workstation via SSH for a remote session. Two completely different things.

Finally, all other services (such as web servers) for which I have port-forwarded from my router's WAN interface to my workstations LAN interface are also affected.

My "workstation" and my "PC" are the same machine.

EDIT:

Having re-read your last post, there are a few things that need to be clarified.

1. OpenVPN is an SSL VPN. This means that it tunnels IP packets through a TCP or UDP socket which is encrypted using SSL. This is not "IPSec made easy"or indeed anything to do with IPSec - the two technologies might make use of IP packets, but that's where the relationship ends. By the way, OpenVPN uses port 1194 - it no longer uses port 5000.

2. Secondly, my own home router does not disappear when the VPN tunnel is up. It's WAN interface is still addressable via its static IP provided to it by my ISP. I know this works because I've tested its remote management capabilities from outside my LAN.

3. So, to go over the points again:

a) My workstation is connected to my router via a single Ethernet connection with address 192.168.1.253.
b) My router is connected to the LAN via Ethernet, with an address of 192.168.1.1
c) My router can ping my workstation and vice versa
d) Other devices on the LAN, such as laptop and phone, can see the workstation and the router, and
connect to them via HTTP, SSH or other TCP/IP services.
e) My router remains addressable from the public Internet, via the static IP assigned to its WAN
interface, whether the VPN tunnel on my workstation is active or not. The router is NOT involved
in the tunnelling.
f) The VPN tunnel starts on my workstation and ends at a server owned by a commercial VPN provider.
They do not offer "proxies", and they do not provide my workstation with an Internet-routeable IP
address.

Finally, the port forwarding set up in my router, to provide a "hole" from the router's WAN interface to my workstation's LAN interface only connects successfully when the VPN is down. This should not be the case, since the router is not part of the tunnel, and in fact will see it as a standard TCP or UDP connection.

I suspect that the culprit is the routing table on the workstation. I think that the incoming connection is coming in on eth0 but the return channel is being routed over tun0, and therefore not back through my router.
open VPN took that ports. OpenVPN is a all application VPN. that means you can sent anything from anywhere on your workstation its going via your proxy to the destination. That's why the port is not there. Does your "VPN provider" support server port forward?

Another question. Where is your workstation? Is it on the same router? If it is you will have to edit the config file of OpenVPN and add your route as a exclude.

Go here
http://wiki.untangle.com/index.php/VPN_FAQs

That will help you.
Edited by Spooony - 6/20/11 at 6:37pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Networking & Security
Overclock.net › Forums › Software, Programming and Coding › Networking & Security › [SOLVED] OpenVPN Client Blocks Inbound Ports