VPN's and Other Remote Access

Understanding VPNs and Remote Access

A Virtual Private Network, or VPN, lets you use any shared line - most often the public Internet - to reach your corporate servers while keeping every packet encrypted. That encryption keeps data from being read or altered by outsiders, giving the illusion of a private, isolated network over a noisy medium. The key point is that a VPN creates a tunnel: the client sends packets to the Internet, the VPN software encrypts them, and a server on the other side unwraps them and forwards them inside the office network.

Many people assume a VPN is required whenever a remote user wants to work from home or a branch office. That assumption is wrong in two respects. First, if you already have a private circuit such as a leased line, the data you send over that circuit is already isolated from other traffic; adding a VPN on top only adds overhead. Second, if the primary goal is data confidentiality, you can use other tools that encrypt the payload without the full VPN stack. Understanding this nuance saves bandwidth, reduces complexity, and helps you choose the right tool for the job.

When a client connects to a VPN, the connection behaves almost exactly like a physical plug into the office LAN. A user can run telnet 10.1.36.3 from his laptop and reach a machine that, in the office, is only reachable via a private address like . Behind the scenes the VPN client on the laptop sees the public IP of the office server, passes packets to it, and the office server forwards them to the internal address. The client never learns that an encryption layer sits in between.

Speed is a common concern. If you have a high‑bandwidth Internet connection at both ends, a VPN can be surprisingly fast. The encryption overhead is usually a few percent, and the latency added by routing through the VPN server is often negligible compared to the base round‑trip time. In contrast, if either side has a sluggish link - say a 56 kbit/s modem - those few percent of extra data can become a noticeable delay. In those situations, a direct PPP connection or dial‑up line may actually perform better.

Consider a scenario where an employee at home first connects to his ISP via a DSL modem, then uses a VPN client to reach the office server at a public IP like . The VPN client recognises that is part of the office’s private network, so it routes traffic to the office server’s public address. The office server receives the encrypted packets, decrypts them, and forwards the payload to the local address . The user sees no difference from a physical LAN connection: he can ping the internal machine, open a file share, or run an internal web application.

Sometimes the simplest solution is a direct modem‑to‑modem tunnel, also known as a dedicated line. The client initiates a PPP session that establishes a raw IP link over the public Internet. No VPN software is required, no encryption is applied, and the bandwidth overhead is minimal. The only trade‑off is the lack of confidentiality. If the remote user has no reason to keep data private - perhaps the office already uses a secure physical line - this can be an attractive choice.

Think of the Internet as a gigantic private network. Whether you connect over a VPN, a direct PPP link, or a leased circuit, the remote machine can reach any device that lies on that network, not just the machine it is connected to. This explains why people sometimes feel confused: they view the Internet as a single, flat network and the office LAN as a subset. In reality, once a machine is authenticated and routed into the office, it has full visibility of all internal resources. That visibility is why encryption and access control are critical when you expose an internal network to the outside world.

In the modern computing environment, most Windows clients now ship with built‑in SSH support or can easily install lightweight SSH tools like PuTTY (screen or