Hi Everyone,
I'm happily running Debian (on a raspberry pi to be honest) with ddns to no-ip AND an openvpn tunnel.
ddns is working fine, the vpn's IP number is known to no-ip and updates on restart as I would expect. HOWEVER, Although I've set inbound port forwarding on my router to the fixed IP number the RPi is using the forwarded ports aren't 'open'.

I'd (naively?) expected that packets from the world would be presented to my router, and passed on due to their TCP port destination being one that is being forwarded. Can anyone suggest how I can tell if packets are getting through the router, and if they are - how I can make the recipient actually consume them.

I have to admit, my knowledge of Linux is limited - and my knowledge of PtP tunnelling dates back to the stone age.

All help gratefully received.

If your raspberry is establishing the VPN connection, then your router won't be able to see the packets.

And who is saying the ports aren't open? How do you test it?

Yes the VPN client is running on the Raspberry pi.

I have tried to access VNC and SFTP from the outside world by using the VPN's IP address, and the 'original' address from my ISP. Neither of these solicit any response from the RPi.

I know that the port forwarding is working because when I stop openvpn I can get through the router to the RPi. Presumably the tunnel that openVPN has set up is precluding any traffic from getting to VNC or SFTP. Also I should add that I can access all these tools while the VPN is up if I'm accessing from a machine on my LAN.

I'm hoping to find a way to either get the packets to the relevent software on the RPi 'outside' the tunnel or get the tunnel to accept these packets.

Hi mbdmbd,

Could you clarify a few things please:

I assume you're trying this once connected to the VPN using a VPN client? If not, then unless you've opened the VNC and SFTP ports on your router then I wouldn't expect this to work.

So you have VNC and SFTP port forwarding set up on your router and can connect to them from outside without tunneling through your VPN? I.e. using your public "original" IP from your ISP.

Have you checked to see if the VPN adapter on the RPI needs any firewall rules to allow incoming connections?

Is this using the RPI's normal LAN address or connecting to the VPN using a VPN client?

This contradicts the second quote above where you say Can you clarify whether you can access the VNC/SFTP services from outside (it's not enough to simply use the public IP from a LAN connected PC for this) through the router to the RPI without the VPN.

You're end goal is achievable, you should be able to get the services to be tunnelled through the VPN, there just might be some hoops to jump through first

Hi - thanks for mickyg's interest. Here are the answers to his questions.

VNC and SFTP ports have been set up on my router to forward to the static IP number the that RPi is using (specifically 192.168.0.202).
Yes I've been connecting to my VPN provider using openVPN client. I've been trying to connect to VNC using the VPN assigned IP number and trying using the none VPN (original) ISP assigned number.

Neither works when openVPN is active, but when openVPN is not running I CAN access VNC using the ISP assigned number.

I would be happy to either connect through the VPN, OR connect via the ISP assigned number while the VPN is running. (The first of these options is preferable).

Yes, when I'm accessing VNC across the LAN (while openVPN is running) I'm using the RPI's normal LAN address (192.168.0.202)

Clarifying what access works:
with VPN NOT RUNNING - VNC and SFTP both work using the ISP assigned IP number via successful router port forwarding.
with VPN RUNNING - I can't reach the RPI by using either the ISP assigned number or the VPN's IP number.
regardless of whether the VPN is running I can always successfully connect to VNC across the LAN using 192.168.0.202


I'm assuming that this is something that can be worked around with routing tables or how they're invoked by openVPN, but I have no experience of this aspect of linux/networking...... sorry if this thread is asking the obvious.

Thanks again.

Are these services listening on all interfaces, or only eth0?

Ahh, that's a very fair question hortageno..... sadly we've reached the limit of my linux expertise. If there are any files or settings I should post just ask and I'll do so.

In the meantime, I believe that the iptables commands below are implicated in message routing, but I don't know if they tell you what you're asking about.


All I know is that on establishing the VPN connection the route-up script contains

iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE

and the VPN down script contains

iptables -t nat -D POSTROUTING -o tun0 -j MASQUERADE

I'm not aware of whether VNC has settings I should be reporting?

Thanks again for everyone's help

Look in the config files under /etc. For sshd it is /etc/ssh/sshd_config. Is there a uncommented entry for "ListenAddress"? I think by default it is listening on all adresses (0.0.0.0)

Sadly here ends MY linux expertise.

Can you see dropped or rejected packets in syslog (or where-ever iptables logs to) when you try to connect to that server? I think the problem lies with iptables if the port forwarding at your VPN provider is set up correctly. The port forwarding in your router doesn't matter since you're going through a VPN tunnel.

In answer to the 'Listenaddress' question.

There is no explicit Listenaddress specified in ssh_config or sshd_config.

As for other messages:
I've looked in /var/logs/syslog an /var/logs/kern.log and can't find any useful messages. I've even checked them, then attempted to connect, and then re-checked them.... neither file adds any additional data during the attempt.

I have also checked the output from my openvpn client. It shows the route commands openvpn issues when the tunnel is established (I'll try to attach a screenshot to this post).
FYI 192.158.0.1 is my router (bet no one is shocked by that) and 83.170.111.150 is the VPN server assigned IP number.

Thanks for everyone's help so far.

Attached Thumbnails

 

Ah OK, I think I misunderstood what you were attempting to do.... I thought you were hosting your own VPN service on your RPI and allowing connections from the Internet by port forwarding through your router, then connecting to that VPN from another device.... my mistake.

So, let me check if I've understood this correctly now, are you:

a) connecting to an external VPN provider out on the Internet with your RPI and then on a separate device connecting to the same external VPN provider and trying to access services hosted on your RPI using the 'private' VPN IP address (10.187.1.6) of your RPI?

OR

b) connecting to an external VPN provider out on the Internet with your RPI and then on a separate device trying to access services hosted on your RPI using the RPI's 'public' VPN IP address (83.170.117.150)?

I have some follow up questions/comments, depending on which scenario above is correct....

If a's correct:

Does you VPN provider allow connected clients to actually communicate with each other? I'm guessing they probably don't as (AFAIK) most VPN providers are generally there just to mask your external IP address by NAT'ing your client connections to one of their public IP addresses. It may be that your VPN provider isolates clients from each other, thus preventing you from accessing the RPI even though you're connected to the same VPN.


If b's correct:

I would guess your VPN provider won't be accepting incoming traffic to their public IP (83.170.117.150) and almost definately not on the well known VNC/SFTP ports.


As for why some things work and don't work:

That's good, at least it proves that VNC/SFTP are configured and working, also a good starting point!

I've covered why I think you wouldn't be able to do this using the VPN's IP address, however, I think this might be failing when using your public ISP assigned IP address because of the routing table changes that the VPN client makes on the RPI which, if I've read it correctly, tell your RPI to send all network packets (except those destined for 83.170.117.150) to the VPN adapter, therefore when a connection request comes to your RPI having been forwarded by your router (and therefore having a public IP address as the source address), the RPI's response is sent via the VPN adapter instead of eth0.

This could be confirmed by posting the output of the "route" command before and after connecting to the VPN on the RPI to show the state of the routing table.

I suspect this works (and I'm totalling guessing here) because the network packets come from the same subnet as the RPI (so have the 192.168.x.x address as the source address), as opposed to when they are forwarded from your router where they have a public IP address as the source. I'm guessing that the kernel treats these differently when creating the response packets and selecting the interface to use (I won't go in to more detail on this because I've already harped on for long enough now!).