SSL VPN to my home network

Using only my Box (FTTH), I’m able to access my home network (box Lan subnet) by simple NAT redirection from any internet location. More precisely, I connect to as many hosts, residing in my home network, as redirection rules on my box.

My box supports only an overload NAT of my inside local addresses. If I access my network from the outside using my inside global routable address , internet, using my unique public address, I have only the possibility to redirect application port to a local port and address that belongs to the subnet, clients, connected directly to LAN ports of my box, use to access internet.

To access from a remote location I use my smartphone that is configured to share via Wifi it’s 4G mobile internet access. The only difference is that NAT is done by access provider (not the smartphone). The only way to get the public internet routable address used to NAT my smartphone trafic is to capture (wireshark) all incoming trafic at the destination (my Box).

The network topology is described in Figure. 1.

Figure. 1: Network topology

Any man in the middle could intercept Client to Server communication. To secure this communication, I create an overlay VPN between the Client and Server.

My Fortigate 60C firewall offers two possibilities: IPSec site-to-site VPN, or SSL VPN. Here for simplicity I choose to work with SSL VPN. Because SSL VPN build on TCP layer (more exactly over TLS) and there’s no need to secure IP layer, NAT is not a problem. In other scenarios, IPSec would be a better choice.

In Figure. 2, we show how the vpn is implemented. The Client / Server communication (in blue) is embedded into the secured tunnel (in red) established between the VPN client software, FortiClient VPN 6.2.0, and the security gateway (firewall), FortiOS 5.2.4.

Figure. 2: VPN topology

The firewall configuration is straight forward:

  • trafic from the client should be allowed by the firewall
  • the firewall should be configured to listen to VPN protocol on the interface facing the client
  • by default the protocol is listening on port 443
  • in tunnel mode, we configure the address range the clients receive upon successful tunnel establishment. This vpn address is what a vpn client uses to access the server or other networks behind the firewall.
  • an authentication policy must be configured to allow the clients build the tunnel
  • after tunnel establishment, a route must be added to the firewall to indicate what address range is attached of the ssl.root vpn interface
  • at the end, trafic from vpn clients to destination firewall zones must be allowed and NATed (to ease routing effort)

For troubleshooting purpose, we use wireshark in client PC to confirm that the vpn client-side TLS protocol exchange and response from the server if any. The client vpn has a debug utility to trace tunnel estalishment steps. On windows it is necessary to check routing table to confirm that a default route is installed with a better metric and that points to the security gateway.

At server side, we may packet capture the trafic exiting the box and arriving to the firewall. A “diagnose debug application sslvpn”, enables debugging of SSL VPN. A “diagnose debug flow”, may help spot routing issues upon tunnel successful establishment.

What about performance? Next we investigate the advantage of implementing DTLS option. For information, DTLS allows the SSL VPN to encrypt trafic using TLS over UDP instead of TCP.

What is the most secure client authentication and trafic encryption method? supported by SSL VPN? and what is the impact of the quality of service?

atlink'admin

Learn More →

Leave a Reply

Translate »