IPSec VLAN #2 - Hardening Rules

After review of information in this SANS 2006 document, I am a little more confident that I can implement the Gateway into my house with a more controlled hardening.  This document is a design using open source components for an Intrusion Detection/Prevention System.  It applies to a small to medium network which is appropriate for my home environment.  My thought is to have this implemented prior to the OpenVPN server in the IPSec VLAN setup that I am building.  Additionally, I will be using SELinux to lock down the services running on my OpenVPN RPi server.  So at this point the following would be needed:

1. IDS/IPS in the flow between the internet connection and the OpenVPN server.
2. SELinux used to lock down services in the RPi server.
3. Checks to make sure that the OpenVPN stream is not broken/compromised, if so then stop all traffic incoming to the home network (meaning the IPSec streams would stop).
4. Audit logs of activity and regular checking of the logs to ensure that nothing got by.
5. No DHCP service on No Man's Land LAN.
6. No ICMP ping responses from any device connected to No Man's Land LAN, this might include any detection of scanning in the network and/or detection of pen test tools.

IPSec VLAN #1 - Keeping VLANs Separate Using Encryption

I was reviewing some Capability Package (CP) documents from NSA the other day and it occurred to me that one of the ideas I could use was to keep VLANs separate from each other even across the internet.  This has appeal since I have a couple of VLANs in my home network that are not connected to the outside world or each other, yet I want to be able to do something with them during lunch at work.

Without going into too much detail re: the CP from NSA, they describe a virtual private network using commercial products which keep security domains separate from each other.  This is done through a double encryption linkage.  The following illustrates what I am talking about:

In this diagram, an OpenVPN Gateway is used on both sides (with certificate based connection) to form a connection between two No Man's Land LANs.  This is roughly equivalent to what we normally do on a day to day basis connecting a laptop using an OpenVPN client to our home networks through an OpenVPN server.  That being said, the connection goes between two LANs that do nothing in this diagram except give a place to combine packets from multiple IPSec VPN Gateways.  If we use a separate certificate to access each "VLAN", the information will not cross between them.  In other words, I could have an IPSec VPN Gateway at work, with a certificate for LAN A, and I could only connect through IPSec VPN Gateways at home that used the same certificate.  Those would be ones that are part of the same LAN A "VLAN".  Notice that I don't have to have a switch/router that is VLAN aware; I could have everything on separate conventional networks.

My thought is to implement OpenVPN on a RPi which would serve as an OpenVPN Gateway into the No Man's Land LAN (after hardening the RPi to attack of course, using a certificate specific to the OpenVPN connection). I would then implement IPSec VPN Gateways on other RPis (also hardened to attack) with certificates specific to the LAN that they connect to.  This speaks of having my own certificate authority (which is food for another post).  The OpenVPN Gateway doesn't necessarily need to be on an RPi either; I just would like to see if I can get this working using commodity items.  Note that the IPSec VPN Gateways could be implemented in VMs as well running on a server.

More Later.