VNC client to internet remote PC

I am trying to establish a remote desktop session with a PC that is connected to a Comcast box.

The connection would look like this:
<#1 linux PC running reminna> -> IPFire -> internet -> -> <#2 linux PC>

Given the IP of #2, I can ping from #1 to #2. This leads me to think IPFire is not blocking the IP address. (Am I wrong?)

But, when I attempt to VNC connect to #2 IP with reminna on #1 it says can’t connect.

My question is: do I need to do something on my IPFire to allow the VNC to pass that ping gets around?

Do you have a forwarding IPF --> <#2 linux PC>?

https://wiki.ipfire.org/configuration/firewall/rules/port-forwarding

Because you dont tell what you try to reach on <#2 linux PC>, here a example for a common setup, VNC server you need forwarding TCP Port 5900.

You should think about if you not maybe use VPN for (more) security

Thanks for the reply.

I don’t have any port forwarding. But, I’m not sure how to handle a rule for this situation.

PC #1 is on my green network. PC #2 is on the other side of a Comcast router, somewhere in another part of the country. (and the its IP may change whenever the PC powers on or Comcast changes the IP lease. Right?)

The VPN is a fine thing to do, but, since the last time I had to get to PC #2 was over 3 years ago, I think a VPN might be a bit of overkill. :slightly_smiling_face:

Sure, use dyndns

Not if we talk about security :wink:

Time to change something :wink:

How does one tell a rule on my ipfire to use dyndns to look up an ip of a random pc on the internet?

Sure, but, PC #2 is a 2 hour drive away. And they got a new printer. They have no idea what is going on and would have no idea how to configure a VPN connection, and of course the printer is not working…and I can’t get into PC #2 to do it remotely. :frowning_face:

A little bit engagement doesnt harm :slight_smile:
https://wiki.ipfire.org/configuration/services/dyndns

For such things, but i do not recommend it because i dont like such services, there some services like teamviewer

Does this mean you think I should do more research? :blush:

I have no problem doing that…except I’m a little lost as to WHAT to research…hence my long list of questions… :frowning_face:

If I understand how to set that up, I need to have PC #2 configured to use dyndns. Meaning, I have no way, short giving instructions over the phone to someone who is far, far, far, from computer savvy. :upside_down_face:

Absolute :wink:

I would recommend you start at the beginning of the wiki and look how far you come. After this ask as often you need help, but first read our lovely wiki. Its there for something good :wink:

Thats why i said teamviewer or similar but as i said i do not recommend it.

Well, you assume I’ve read none of it. But, I have read some (enough to get confused… :blush:). Nothing I’ve read so far is giving me any guidance for my issue. It has much goodness for setting things up…IF one already knows what is needed.
I don’t.

For example, I don’t know, if, by default, a VNC connection to a given IP, outside my green network, is being blocked, when ping works just fine (yes, I know, different protocol, so, one protocol is blocked and one isn’t?)

And, if the VNC is being bocked by my IPFire from going onto the internet, will adding a port forward fix that? I don’t know, have no real way to experiment.

Also absolute, but this time absolute No, i dont think a second so. Its because you said

So its always a good idea to start at start :wink:

I already answered this before.

Hey folks, you’re a little bit crazy to advise or to accept using VNC without tunneling it throug a VPN and to make an end user desktop device direct available to the internet by portforwarding. Even more in case of a remote access tool. Great invitation to unwanted visitors discovering your device, @drmacro, by a portscan in the twinkling of an eye.

I do not agree. By comparison it’s a mutch better idea to use something like Teamviewer than implementing a direct reachable VNC-Server. You know about the security issue but proceed to advise. The OP seems not to know and is just desperately seeking a remote support option and would use what ever by chance works - masking any security risks.

@drmacro, you could take account of using something like Teamviewer to install the VPN-Client on the remote device. Also to change IP configuration from DHCP to fixed IP so that your target device is available at always the same local subnet IP and also to install the according VNC-Server for further assistance later without having to use services like Teamviewer then. That could be a reasonable way to proceed. In that case you don’t need portforwarding and you’re tunneling VNC secure through a VPN-Connection.

Of course the WAN IP of your Comcast box responds to ICMP ping. But hopefully there is a firewall on that box and the target device is behind that firewall? Or is it really that way you described it at the beginning, that your target device is connected directly to the internet only with the software firewall of the choosen Linux protecting it? But also in that case, it’s the WAN side that is responding to your pings and the hopefully active firewall would block anything else inbound. E.g. the attempt to reach a local VNC-Server on Port 5900.

Regards,
Simulacron

@anon47238184 Can i help you?

I appreciate the help and coaching. :slightly_smiling_face:

I fully understand the security implications and would love to find a solution. So, let me lay out the status.

  • the “user” is a 90 year old guy who doesn’t know the difference between an icon and a network. And uses it for email, browsing, and printing. (the printer died and he bought a new one & new one, for some reason, quit working after reboot)
  • the “user” has a PC running Ubuntu 16.04.
  • it is connected to a Comcast cable modem
  • No clue what sort of firewall is working on that side.
  • I am 100 miles away. Short of donning a mask and hopping in the car for a 2 hour road trip through covid infested lands, and then a 2 hour ride back, I don’t have physical access.

So how can I implement all this security and get his printer running? Or, set up for VNC, do my work, and remove the open port/s.

:thinking:

Mac,
Find a neighbour of the elder, who can assist. Have them install TeamViewer. TV can be configured as a daemon. Set up with a unique pw so you can connect from 100 miles away. Then, you should be able to admin his system remotely. I do that with a friend, she lives 60 miles away.

@drmacro - Suggestion: Granimals for networks!

Build up a simple IPFire firewall. Label everything like cables, ports all cords. Setup with VPN and configure a login for you. Put the VPN on your computer and TEST. Test again! Ship to user.

Green Network:

  • Purchase green ethernet cable
  • One end labeled with to PC
  • Other end labeled with to Firewall

Red Network:

  • Purchase red ethernet cable
  • One end labeled with to Comcast Modem
  • other end labeled with to Firewall

IPFire box:

  • Label Red port
  • Label Green port
  • Label Power button

This is what I did for family and it works VERY well. On July 4 my sister just did the complete setup without any telephone help from me! (she is sending me pics of the setup since I didn’t take any before sending)

After received you can talk “user” thru setup. And thru VNC setup.

I understand the rest of your post (took me a couple seconds to get the Granimals reference… :wink: )

But, I have questions.

  • The testing bit. (and this applies to the VPN I already have on my local IPFire. Testing with a cell phone is easy: generate the certificates, copy to cell phone storage, turn off wifi and let it revert to the cell phone internet access, start VPN client on cell phone. Confirm you can see my local net, etc.

But, how do I test a local tablet or pc that has no cell phone network? Once the certificates are on the tablet/pc, then what? It’s local and still connected to my green network.

  • are you saying you configured a VPN on your network and set up the remote IPFire to connect to your VPN to get to the internet? Or that you have a roadwarrior VPN from your local PC, through your IPFire to a VPN setup on the remote IPFire?

  • What you have configured would require getting the mac address from the remote PC to generate the certificates.

  • How do you test the remote IPFire/VPN setup locally before you ship it to remote site?

This was the term my sister came up with and it seemed appropriate!

 

I installed Tunnelblick (openvpn client) on my Mac, copied over the certificate, connected the computer to a cell phone via hotspot, and tested & connected that way. Sorry, I don’t know the Windows or Linux way to do the same.

So for the test is:
Mac > Tunnelblick (openvpn) > USB cable > iPhone (cell data only) > Internet

-and then-

Internet > your Modem > IPFire box (test) > OpenVPN (road warrior mode) > PC (test)

Nothing changes on your own local IPFire box. If your PC user address changes then you’ll need Dynamic DNS.

Here is info about OpenVPN on IPFire.
Here is info about Client-to-Net configuration (Roadwarrior).

Does this help?

Sure, that is what I describe for testing via cell phone.

But, without a cell phone, then you have to have a hotspot outside you local IPFire/VPNserver. Or am I missing something. :upside_down_face:

Hmm…not the way I see it. I have to shutdown my existing IPFire/VPN firewall. Replace it with the IPFire/VPN box (the one that will be shipped to the end user). Maybe I don’t get what you’re telling me… :thinking:

Sure, I read those to get my local IPFire/VPN with roadwarrior working for my cell phone. But, for roadwarrior devices with no cell carrier, I need to use a external hotspot to see if the device was indeed getting to my local net behind my IPFire firewall.

You got it perfect.

Yes this is correct. What I was saying (badly saying) is there are no config changes to your IPFire box.

I’m not sure I understand this paragraph (sorry I may not be fully caffeinated).

A temporary setup of a hotspot or some sort of external internet connection is needed to test the PC user’s new IPFire box and VPN connection.