I was reading about VPNs and I understand that a VPN server can protect my traffic in a way that will prevent the end-server from knowing my original location, plus there are additional encryptions.
But how can a VPN server protect me from my ISP when the request from my laptop has to go first through my home router, then through the network of my ISP and finally reach the VPN server which will then encrypt the traffic and do its job.
So the traffic between my laptop and the VPN server is still unprotected.
Related
I'm struggling to find a good explanation about what actually happens on the client side on a computer when a VPN client is running and connecting to a VPN server on the internet.
When we turn on and enable the VPN application to connect to a VPN somewhere in the world, and then use Chrome or Firefox etc. to access a website, how does the browser software know to connect to the VPN IP address instead?
My understanding is that normally an IP packet from layer 3 which has a source and destination IP address, gets wrapped in an Ethernet frame at layer 2.
When we use a VPN, does the IP packet for the destination address get wrapped in another packet for the VPN server first? Where does the TLS encryption come into this then?
If you have a real VPN (where N stands for network, i.e. not a web proxy) then a virtual network interface is created on the computer and routes are setup, so that all non-local traffic is send through this virtual network interface. The traffic will be encrypted there and then send through the "real" network interface to the other VPN endpoint, i.e. the original IP packet will be encrypted and then wrapped into another IP packet for transport.
In the other VPN endpoint there is the same kind of setup: the encrypted network traffic comes in through the real network interface, gets passed into the virtual network interface, gets unwrapped and decrypted there and emerges decrypted on the VPN endpoint where it (the decrypted data) then get forwarded to the final target.
What I'm trying to achieve is:
Connect to a VPN as client and route all my internal network's traffic over the VPN.
Run a VPN server, so that people from outside can connect to my internal network and get routed over the a.m. VPN client.
I'm trying to achieve that with a router running dd-wrt (netgear D6200), and / or a raspberry pi.
Can someone tell me if this can be achieved, and if, direct me to what would be a possible solution?
(I'm not looking for a tutorial, just a direction)
Thanks!
This thread probably does not belong here.
Consider using OpenWRT instead of dd-wrt. OpenWRT gives you a usable build system and easier to customize and build. I am not advocating OpenWRT. This can be a stop gap measure.
You can setup a OpenVPN server and OpenVPN client using the standard
documentation available on OpenWRT Wiki and also OpenVPN site.
Add to OpenVPN server.conf the following directive redirect-gateway def1. This will push the default gateway to clients connecting to OpenVPN server. Further, make sure you are using a unique network IP pool for VPN clients and does not clash with the remove VPN server.
Make sure you are masquerading the VPN traffic (Clients of local VPN server) before forwarding to remove VPN server. This can be tricky as this interface does not exist at boot time. It needs to be configured using up and down scripts
Make sure you are allowing traffic (clients of local VPN Server) on VPN interface to be forwarded in your firewall rules
Before setting up the OpenVPN server, make sure
The remove VPN server is pushing the default gateway to your VPN
client
You have setup the firewall correctly
You are able to reach the cloud through the Remote VPN Server. Checking with some site like www.whatismyip.com will help
Yes this is possible with dd-wrt on Netgear.
There is no need of Raspberry (unless you meant to run the remote VPN server on it).
Configure and run VPN server on dd-wrt - and try connectivity by connecting clients. Both tun/tap should work in general (with VPN client running). I tested with tun.
Configure and run VPN client on dd-wrt and try connecting to your VPN server. By default, the router should start directing all traffic (for its own LAN clients) via the VPN server.
So far so good.
The problem comes when you want dd-wrt's VPN clients (and not just LAN clients) to take the same route. With a VPN client running on dd-wrt, dd-wrt's own VPN clients will not be able to connect to the VPN server running on dd-wrt as such. To make it work, see below.
This is only possible via PBR - i.e. you run VPN client on dd-wrt, but take the router itself off this client, and route only specific clients through this VPN client running on dd-wrt.
With some tweaks using subnet masks, it is possible to include all your LAN and VPN IPs in the PBR policy so that everything (except the router itself) routes through the remote VPN server.
The key is to include dd-wrt's VPN clients' virtual IPs in the PBR. While configuring VPN server on dd-wrt, there is a field for specifying the clients' network and netmask.
If you use this network IP and netmask in client process's PBR policy, your (dd-wrt's) VPN clients will be able to connect to the VPN server running on dd-wrt, and will in turn be routed through the remote VPN server to which dd-wrt is connected as a client.
I don't have a public ip address so I'm looking to host a server while connected to a VPN, the VPN server is running on a VPS that I own and its running SoftEther VPN server.
In my machine I connect to the VPN and then run the server app, however I check in http://www.canyouseeme.org/ to see if its successfully hosted and can be accessed from internet but its not and it shows "connection refused", if I host the server on the VPS machine it works, but I don't want that, it should be hosted on my machine and should be accessible using the ip address of the VPS/VPN.
You probably want to set up port forwarding on your VPN server.
When you connect to the VPN, your traffic goes through it, but you don't "become" it - the traffic directed to the VPN server (like an attempt to connect to your app) will not be forwarded to your VPN client machine - this is not the purpose of VPNs.
There is a page with port forwarding setup here. This is to be done on the VPN server.
The alternative I use is to setup port forwarding via SSH on the application server and ditch the need for VPN. Check Remote Port Forwarding here. It works fine, encrypts your data between the application server and the gateway, but there might be bigger overhead and it may be more prone to die when the network connection is temporarily lost.
Suppose I have a VPS with private networking setup such that the only ports that are open are the port for SSHing into the server and the port that connects the server to other servers on the private network. Can this same server still send requests through the internet and receive back responses? If so, through what 'channel' are the requests/responses being sent/received?
It depends on what the outbound firewall settings are on the server. If the firewall allows all outbound connections then you can connect out to any server on any protocol.
However, depending on the hosting provider, they may limit the ports which you can use for outbound connections. Most likely (but not guaranteed) you'll be able to use HTTP (80) and HTTPS (443). It is quite possible that SSH (22) would be open as well. Those three should cover most, if not all, of the needs to would have.
I'm currently working on my group voice chatting program. This is my plan:
Build up a server on 192.168.1.125. Listen to port 3490 and forward it to the router.
Clients connect to the server and get the user IP list(Whenever a client connects to the server, its IP address is recorded by the
server)
Clients communicate with each other using UDP multicast(is this ever possible across the router?).
But now I'm running into troubles. If a client inside the LAN, e.g. 192.168.1.120, connects to the server, it's taken down as 192.168.1.120, which won't work for clients from WAN.
I'm wondering if there is any way to convert the LAN IP to public IP? (this might have something to do with the router, I think)
Thanks.
You will have to be prepared for the case where direct client-to-client communication fails. Relaying through the server or NAT traversal/penetration may be necessary. Significant expertise is required to do this correctly.