Stan Jewhurst

When hosting things at home, or even in the cloud, there is often an issue with having multiple services with web interfaces, but only one external IP address. As a result, we end up relying on port forwarding, using a bunch of non-standard ports which, while functional, is often far from ideal. The two main issues with this approach are:

• Delving into your ISPs Port Forwarding settings – which are usually clunky, confusing a don’t always work.
• Non-standard ports being blocked by organisations or service providers – they are often considered a security risk, or involve too much work to ensure traffic inspection/classification.

(There is, of course, the further complication that your IP Address may not be static, but we’ll deal with that in a different post. For now, we’ll assume our IP is Static)

Enter the Proxy.

According to Wikipedia, a Proxy is an ‘application or appliance that acts as an intermediary for requests from clients’. In the IT world, proxies are often used at the network edge – they allows multiple internal users to connect out to the web from a single or range of IP addresses (without the complications of NAT) while also giving the business insight into the types of requests being sent, and allowing them to enforce governance and security policies on the traffic. Proxies can also cache frequently requested content, which can significantly increase web performance for users (i.e. less cries of “The Internet is sloooww”).

There are a range of commercial paid-for and free proxy services but for this post we’re going to focus on NGINX. NGINX is actually an open source web server – similar to Apache – but with some extra features which make it very suitable for a multitude of applications including caching, streaming, load balancing and proxying.

Now I know what you’re thinking – “..but we’re interested about traffic coming in, not going out..” – and you’d be right, which is why we need to flip this whole concept around and talk about a Reverse Proxy. While standard proxies generally act as a single gateway for users going out to the web a Reverse Proxy acts as a single gateway from the web – usually to multiple servers sitting behind it.

This means we only need to open our web ports and the Reverse Proxy can do the rest for us. Configuring NGINX to take on this role is actually pretty straightforward, so let’s get it instsalled.

stan@nginx~# sudo apt install nginx

Just like that we have a web-server up and running – just head to http://<NGINX-IP> and you should see the NGINX default web page:

The default installation of NGINX on Debian will create the directory /etc/nginx which holds all the files we need to get things up and running. If we head into the sites-available folder, there will be a default.conf file – the default configuration for the above web page. It will be filled with lots of comments about how to use the file, but in essence will look something like this:

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/html;

        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                try_files $uri $uri/ =404;
        }
}

This defines the ports (80) and IPs (0.0.0.0 and :: – i.e. all IPv4 and IPv6 addresses) we want the server to listen on, then the location of the website root directory (/var/www/html) and the index page types to look for. The server_name attribute lets us define a way of identifying the server and the location section lets us list any specific configuration based on the URI.

In Reverse Proxy mode, we don’t want to serve a website locally, so we modify this configuration:

server {
        listen 80 default_server;
        listen [::]:80 default_server;

       server_name _;

        location / {
	        proxy_pass http://<SERVER-IP>:<SERVER-PORT>;
        }
}

This is the most basic configuration to allow reverse proxying to work but if we now browse to http://<NGINX-IP> we will find ourselves looking at the web application deployed on <server>:<port>. So, with the basics out of the way, how do we make this work for our multiple services?

NGINX, like Apache, utilises the concept of Virtual Hosts to allow multiple websites to be served from a single web server (commonly known as shared hosting). We can use the URI of the website to differentiate the server we want to proxy to. This next step assumes that DNS entries pointing to your Public IP are in place for your services – we’ll use services s1, s2 and s3 with the domain home.net. They will run on internal IPs .10, .20 and .30 from the 192.168.1.0/24 network.

server {
        listen 80 default_server;
        listen [::]:80 default_server;

       server_name _;

        location / {
                try_files $uri $uri/ =404;
        }
}
server {
        listen 80;
        listen [::]:80;

       server_name s1.home.net;

        location / {
                proxy_pass http://192.168.1.10:8080;
        }
}
server {
        listen 80;
        listen [::]:80;

       server_name s2.home.net;

        location / {
                proxy_pass http://192.168.1.20:3667;
        }
}
server {
        listen 80;
        listen [::]:80;

       server_name s3.home.net;

        location / {
                proxy_pass http://192.168.1.30:8080;
        }
}

This configuration utilises multiple server{} blocks along with the server_name attribute to separate out the services we wish to proxy for. If we browse to http://s1.home.net we will be forwarded to http://192.168.1.10:8080 while http://s2.home.net will take us to http://192.168.1.20:3667. Our browser, meanwhile, will still show http://s1.home.net and http://s2.home.net – this whole process is transparent to the browser. As a result we only need to forward port 80 on our Router to our NGINX server, and let it handle the rest.

Again, this is a very basic configuration – often times this will need tweaked depending on the requirements of the web application to ensure that certain information from the HTTP Header is passed on to the final website – or to insure information passed back from the website is done so correctly. Best practices would also have each of the backend server{} statements in its own file under sites-available, which can then be symbolically linked to the sites-enabled folder, also within the /etc/nginx directory.

stan@nginx~# ls -1 /etc/nginx/sites-available
default.conf
s1.hone.net.conf
s2.hone.net.conf
s3.hone.net.conf
stan@nginx~# ls -1 /etc/nginx/sites-enabled
default.conf -> /etc/nginx/sites-available/default.conf
s1.hone.net.conf -> /etc/nginx/sites-available/s1.hone.net.conf
s2.hone.net.conf -> /etc/nginx/sites-available/s2.hone.net.conf
s3.hone.net.conf -> /etc/nginx/sites-available/s3.hone.net.conf

With the proxy acting as a frontend for all of our services, there is now the opportunity to enable HTTPS for all of them, but that is a post for another day…

Remote access to my Home Lab and various other assets has always been something I’ve secured with HTTPS – I’ve used multiple technologies from nginx remote proxies to HAProxy with SSL Offloading (this works really well when integrating with LetsEncrypt with multiple back end services); however after picking up my new iPhone 11 Pro, I wanted a good way to secure my general browsing when out and about on public WiFi as well as a more straightforward method of gaining CLI access to my various assets.

I’ve not spoken about my use of VyOS yet, but as an alternative to the time-based licensing on Cisco CSR1000v (and it’s kind of crazy VM requirements) I decided to migrate my Edge Routing to VyOS which runs in a small sized VM, on practically any CPU which supports virtualisation, and yet can still support decent encryption speeds. I also implemented this on my remote vServer, so I could extend my Home network into the Cloud.

Being a network engineer raised in a Cisco environment, IPSec has always been my tunnelling protocol of choice, but with a remote endpoint such as an iPhone, with a dynamic IP, I felt this could be a tad clumsy to set up. Likewise, IKEv2, while supported by iOS natively, is entirely undocumented from a VyOS standpoint for a dynamic remote client, such as a phone (and older versions of VyOS have had issues with IKEv2 support). Unlike a lot of Routers – as it is Debian based – VyOS has native support for OpenVPN but I wanted something native to make it easier to deploy – which left me with L2TP.

L2TP on it’s own is not a very secure protocol. In fact, it’s entirely insecure, which led to the creation of RFC3193 which denotes a methodology for securing L2TP with IPSec. I was a tad concerned about the security of this, as the RFC denotes that either 3DES or AES can be used, but I figured I would be able to configure that within VyOS, and continued on my merry way.

The configuration was actually super easy – L2TP is a supported protocol within VyOS, and their command line interface is nice and straightforward to use. I’m going to use a VPN range of 10.66.66.1 – 10.66.66.6. My Outside interface will be pppoe0. First we enable IPSec on the outside interface, enable NAT Traversal and define the networks we’re allowing:

set vpn ipsec ipsec-interfaces interface pppoe0
set vpn ipsec nat-traversal enable
set vpn ipsec nat-networks allowed-networks 10.66.66.0/29

Next, we simply configure L2TP the way we like it, including authentication, users, passwords and addresses for clients:

set vpn l2tp remote-access description iOSL2TP
set vpn l2tp remote-access authentication mode 'local'
set vpn l2tp remote-access authentication local-users username user1 password 5ome$ecur3Pa$5
set vpn l2tp remote-access client-ip-pool start 10.66.66.1
set vpn l2tp remote-access client-ip-pool stop 10.66.66.6
set vpn l2tp remote-access dns-servers server-1 10.10.10.5
set vpn l2tp remote-access dns-servers server-2 8.8.8.8
set vpn l2tp remote-access ipsec-settings authentication mode 'pre-shared-secret'
set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret A12DigitPass
set vpn l2tp remote-access ipsec-settings ike-lifetime '3600'
set vpn l2tp remote-access outside-address 'MyOutsideIP'

There are a couple of things about the configuration above, but we’ll start with the elephant in the room – while you can configure this on any VyOS router, you need to specify your outside IP, which means if you don’t have a static IP, you’re gonna have a bad time. Some UK ISPs do offer static IPs to home users, such as Zen, Cerberus and PlusNet.

Secondly, you may notice that my DNS Server 1 IP is an internal IP – that’s my PiHole DNS server which means that my VPN enabled iPhone won’t have to deal with those bandwidth consuming adverts (especially as they screw up mobile web browsing so much). It also means that I can hit my internal hosts using DNS.

There is one final piece of configuration, and that is to make sure that the IPs can reach the internet, so we tweak NAT to take that into account:

set nat source rule 100 outbound-interface 'pppoe0'
set nat source rule 100 source address 10.66.66.0/29
set nat source rule 100 translation address masquerade

With that complete, configuring the iPhone is easy, adding in your outside IP (or DNS), username, password, and PSK:

And when we spin it up, we can confirm on the CLI:

stan@home-vyos:~$ show vpn remote-access
Active remote access VPN sessions:

User            Proto Iface     Tunnel IP       TX byte RX byte  Time
----            ----- -----     ---------       ------- -------  ----
user1           L2TP  l2tp0     10.66.66.1        6.0K    9.7K  00h00m02s

You may remember earlier I mentioned that I wasn’t sure how secure L2TP/IPSec actually was, and you can see that VyOS gives no options to configure the Phase 1 or Phase 2 SAs. Thankfully, it does have a way of showing some detail on the IPSec connection being used:

stan@home-vyos:~$ show vpn ipsec sa verbose
[..snip..]
Connections:
remote-access:  my.ip.add.ress...%any  IKEv1, dpddelay=15s
remote-access:   local:  [my.ip.add.ress] uses pre-shared key authentication
remote-access:   remote: uses pre-shared key authentication
remote-access:   child:  dynamic[0/l2f] === dynamic TRANSPORT, dpdaction=clear
Security Associations (2 up, 0 connecting):
remote-access[109]: ESTABLISHED 31 seconds ago, my.ip.add.ress[my.ip.add.ress]...82.132.242.151[10.5.202.100]
remote-access[109]: IKEv1 SPIs: 6f77acf533823322_i 5516f8dae8156886_r*, rekeying disabled
remote-access[109]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
remote-access{717}:  INSTALLED, TRANSPORT, reqid 19, ESP in UDP SPIs: c050470e_i 0da3faea_o
remote-access{717}:  AES_CBC_256/HMAC_SHA1_96, 1343 bytes_i (24 pkts, 5s ago), 1992 bytes_o (25 pkts, 5s ago), rekeying disabled
remote-access{717}:   my.ip.add.ress/32[udp/l2f] === 82.132.242.151/32[udp/61545]

We’re using IKEv1 with AES256-CBC Encryption, SHA1 Hashing with IPSec Phase 2 using ESP-AES256-CBC and SHA1 Hashing…which I think is quite secure enough to be getting on with.