Can I VPN to my Home LAN?

Carlosinfl

Loves the juice
Joined
Sep 25, 2002
Messages
6,633
I really would like the ability to connect to my home LAN from remote locations like work, friends, or maybe select places that have Wi-Fi. Currently I have the following at my home:

{INTERNET} ---> Modem ---> Asus NT-R66U ---> Synology DS211+ NAS

Both my home router and Synology NAS box support VPN but I'm honestly not sure what / how this can be configured and what the limitations are. I figured I'd ask here to see if this is even possible. I just would like to ssh into my home servers from time to time...
 
Yes, use the built in VPN in your Asus box but it only supports PPTP which is considered very low security.
//Danne
 
+1 to OpenVPN, make sure all the features that you might want are supported on DD-WRT (I had problems with port forwarding when I switched to tomato on my old router)
 
Based on my flow chain of hardware, would it be preferred running my OpenVPN on my router or my NAS? Seems like my router would be better suited as a dedicated network device and it's also the default gateway to the LAN however clearly Asus router hardware is significantly weaker than my Synology NAS box.
 
Depends on how fast your net connection is. What are your upload and download speeds?
 
Ok, a couple things here. You don't need a VPN to SSH into your own boxes. You don't need a VPN to download files either, that can be done through SSH as well. If all you're wanting to do is SSH occasionally, just run the SSH daemon on a non-standard port and forward the port on your router to the SSH server.
 
Last edited:
Ok, a couple things here. You don't need a VPN to SSH into your own boxes. You don't need a VPN to download files either, that can be done through SSH as well. If all you're wanting to do is SSH occasionally, just run the SSH daemon on a non-standard port and forward the port on your router to the SSH server.

Exposing ssh to the Internet isn't a very good idea. Openvpn is a bit harder to exploit.

Even on a different port, port scans still happen. If your firewall doesn't have port scan detection then it's just a matter of time.
 
Exposing ssh to the Internet isn't a very good idea. Openvpn is a bit harder to exploit.

Even on a different port, port scans still happen. If your firewall doesn't have port scan detection then it's just a matter of time.

If he's actually worried about that then he can disable root logins and use a decent password on non-root account to login and elevate as needed, or even just use key based authentication. Exposing SSH is only bad if you don't manage it properly.

And using OpenVPN to simply SSH kinda defeats the purpose of the encryption SSH provides in the first place since it would be encapsulated inside the OpenVPN encryption. So basically he would be encrypting/decrypting twice. If he's going to use OpenVPN for other things, it would be good, but I don't see the point in using a VPN just so you can SSH into the local network.
 
If he's actually worried about that then he can disable root logins and use a decent password on non-root account to login and elevate as needed, or even just use key based authentication. Exposing SSH is only bad if you don't manage it properly.

And using OpenVPN to simply SSH kinda defeats the purpose of the encryption SSH provides in the first place since it would be encapsulated inside the OpenVPN encryption. So basically he would be encrypting/decrypting twice. If he's going to use OpenVPN for other things, it would be good, but I don't see the point in using a VPN just so you can SSH into the local network.

Exactly why I asked him what his point was.... if he needs to login to a domain at his place or something then why would he need VPN? :confused:
 
Exactly why I asked him what his point was.... if he needs to login to a domain at his place or something then why would he need VPN? :confused:

Because ssh by nature is really insecure. It is very easy to brute force. End of story. A small botnet can brute force most passwords in a short amount of time. Often times an attack on a low load server goes unnoticed because it can still perform it's normal duties.

Relying on ssh for security is like relying on pptp for vpn. They are both easily broken attack magnets. Even running on an alternate port makes little difference. Most script kiddies test all open ports for an ssh response automatically.

Openvpn can be set up for certificate verification + password, much much harder to break.
 
Last edited:
Cisco IOS Zone Firewall with hardware based encryption using AES-256 SSL VPN.... haha

just kidding... thats what I use but OpenVPN should be great for you! PPTP is simple and it does work and if you are not trying to do a lot it is sufficient for short stents of whatever drives you to use VPN.
 
Because ssh by nature is really insecure. It is very easy to brute force. End of story. A small botnet can brute force most passwords in a short amount of time. Often times an attack on a low load server goes unnoticed because it can still perform it's normal duties.

Relying on ssh for security is like relying on pptp for vpn. They are both easily broken attack magnets. Even running on an alternate port makes little difference. Most script kiddies test all open ports for an ssh response automatically.

Openvpn can be set up for certificate verification + password, much much harder to break.

People shouldn't be operating servers if they don't have safeguards in place to detect and prevent bruteforce attacks. OpenVPN may be more secure from the standpoint of trying to decrypt packets, but it still uses a web interface with a username and password. If someone can brute force your SSH credentials, they can do the same to OpenVPN. SSH can also be set up to use certs for login, rather than the standard username/password.
 
Because ssh by nature is really insecure. It is very easy to brute force. End of story. A small botnet can brute force most passwords in a short amount of time. Often times an attack on a low load server goes unnoticed because it can still perform it's normal duties.

Relying on ssh for security is like relying on pptp for vpn. They are both easily broken attack magnets. Even running on an alternate port makes little difference. Most script kiddies test all open ports for an ssh response automatically.

Openvpn can be set up for certificate verification + password, much much harder to break.

A random botnet isn't going to be able to brute force an SSH if root is disabled, atleast very easily. It would first have to know an actual login, brute force the password to that login, and then elevate afterwards. Random internet scanning bots rely on badly configured servers to make brute forcing a reasonable prospect.

Improperly configured SSH exposed to the net:

-Bot scanners looking for SSH finds it on port 22
-Bot brute forces the root login with an easy to guess password
-Bot now has control of box with root


Properly configured SSH exposed to the net:

-Most bot scanners miss it because its on a non-standard port (a couple might find it)
-The bots that do find it on a non-standard port can't auth because it doesn't have a key in authorized_keys

or (with username/passwords)

-The bots that do find it on a non-standard port must now brute force a non-root login name AND strong password.
-And then finally elevate their privileges in some way with the local non-root account.

Not very practical, there's much easier fruit to grab.
 
Last edited:
Because ssh by nature is really insecure. It is very easy to brute force. End of story. A small botnet can brute force most passwords in a short amount of time. Often times an attack on a low load server goes unnoticed because it can still perform it's normal duties.

If it's SO EASY and SO INSECURE...

freshly created digital ocean droplet, ubuntu 14.04 x86.
192.241.135.21
port 22
root is active
no fail2ban, just a password that 12 year old didn't set.


good luck.
 
Oh.. and by the way
Code:
C:\Users\S>nslookup 192.241.135.21
Server:  pfsense.house
Address:  192.168.1.1

Name:    bds1904.is-very-bad.org
Address:  192.241.135.21

Shots fired. :p
 
. OpenVPN may be more secure from the standpoint of trying to decrypt packets, but it still uses a web interface with a username and password. If someone can brute force your SSH credentials, they can do the same to OpenVPN.

Uhhh, who in their right mind puts the admin web ui to openvpn as an available service to the internet? The only port I have open on my network is 1094. I can access the admin interface just fine.... From inside the network. Why have multiple attack vectors when you can fullel everything down to one point of entry.
 
Uhhh, who in their right mind .

The same people that leave SSH open to the internet on the default port with weak root passwords.

Also, I was talking about the client log in, not the admin one. You can secure OpenVPN and you can secure SSH. Why set up an entirely new system and secure it, when you could just secure the service that you're already using?
 
Uhhh, who in their right mind puts the admin web ui to openvpn as an available service to the internet? The only port I have open on my network is 1094. I can access the admin interface just fine.... From inside the network. Why have multiple attack vectors when you can fullel everything down to one point of entry.

Exactly. Looks like we got another networking master in the house:rolleyes:. You always have to have the openvpn https admin console accessable from the web. LOL, that's great.

Openvpn certainly does not require the control interface open to the web. As a matter of fact it requires no tcp ports open at all.

The other thing ssh leaves you with is a service that can easily be ddos' ed. It's a tcp service that can be flooded.

Openvpn by nature runs over udp. again, harder to exploit.

Did you know that if you get DDoS' ed at home and it affects your isp you will likely get your connection terminated for violation of ToS? Most agreements state no servers, and if you get ddos' ed you obviously have a outside service accessable.
 
Exactly. Looks like we got another networking master in the house:rolleyes:. You always have to have the openvpn https admin console accessable from the web. LOL, that's great.

Openvpn certainly does not require the control interface open to the web. As a matter of fact it requires no tcp ports open at all.

The other thing ssh leaves you with is a service that can easily be ddos' ed. It's a tcp service that can be flooded.

Openvpn by nature runs over udp. again, harder to exploit.

Did you know that if you get DDoS' ed at home and it affects your isp you will likely get your connection terminated for violation of ToS? Most agreements state no servers, and if you get ddos' ed you obviously have a outside service accessable.

I never said you always have to have the web interface open to the public. Just like you don't always have to leave SSH on the default port with a weak admin password. :rolleyes:
 
I never said you always have to have the web interface open to the public. Just like you don't always have to leave SSH on the default port with a weak admin password. :rolleyes:

yes you did:

People shouldn't be operating servers if they don't have safeguards in place to detect and prevent bruteforce attacks. OpenVPN may be more secure from the standpoint of trying to decrypt packets, but it still uses a web interface with a username and password. If someone can brute force your SSH credentials, they can do the same to OpenVPN. SSH can also be set up to use certs for login, rather than the standard username/password.

OpenVPN by default uses Server & client certificates + password. If one is wrong you get denied. The client expects a certain cert, the server expects a certain cert, then on top of that you still need a password.

AFAIK SSH can only do one or the other. In the end it is still a TCP service that can be DDoS'ed by any script kiddie.
 
Last edited:
Exactly. Looks like we got another networking master in the house:rolleyes:. You always have to have the openvpn https admin console accessable from the web. LOL, that's great.

Openvpn certainly does not require the control interface open to the web. As a matter of fact it requires no tcp ports open at all.

What are you on about? 1194 is the default port for OpenVPN clients. Not sure how exposing that (and nothing else) has anything to do with the https console. I think you misread my post or something.
 
Back
Top