SmallWall now supports all three of the most popular VPN standards. And all three can be used in conjunction.
This is the standard business class point to point VPN for connecting networks together over the Internet. It not only works from SmallWall firewall to SmallWall firewall, but has been proven to work with Cisco, Fortigate, Watchguard, and Sonicwall as well. This is not surprising, as it is designed as a standard to support interoperability. However, to insure maximum interoperability, SmallWall also supports encryption standards that have been shown to be vulnerable.
SmallWall supports IPsec mobile clients. This is not L2TP IPsec, but an old and little used standard before L2TP was developed. If you really need it, you will know. If you do not know what it is, you really do not need it.
In the Tunnels tab, you can globally enable or disable all tunnels. You can create a new tunnel with the + icon.
VPN: IPsec: Edit tunnel - The initial definition and description of the tunnel
Disabled - Used to disable this, and only this tunnel.
Interface - The local endpoint, or interface the remote end is connecting to. (Usually WAN)
NAT-T - Allows the encapsulation of ESP and UDP packets. This can help if one end is behind a firewall doing NAT.
DPD - Detects when the other side is down and tries to rebuild the tunnel. If there is nothing here, it will allow the tunnel to stay down until needed. This can cause some latency on first ping...
Local Subnet - The local network advertised to the other firewall. It does not have to be the same as your local network. It can support subnets, and summery routes. It must match the Remote Subnet on the other side.
Remote Subnet - The remote network advertised on the other firewall. It does not have to be the same as it's local network. It can support subnets, and summery routes. It must match the Local Subnet on the other side.
Choosing "LAN Subnet" is risky here unless both sides are running SmallWall. This is because while 192.168.1.0/24 and 192.168.1.1/24 are functionally the same, they do not negotiate the same, and your tunnel will not come up. If you are having problems, specifying the exact same values here at both ends can help.
Remote Gateway - The IP address or Fully Qualified Domain Name of the remote firewall. If this is a domain name, and IPsec DNS check interval on the System -> Advanced page is set, you can use Dynamic DNS for an endpoint.
Description - A friendly name for your tunnel.
Phase 1 proposal (Authentication) - This is where the actual encryption for your tunnel is negotiated. An encrypted tunnel is set up with known parameters, and then new parameters are negotiated for the actual tunnel. This allows new and unknown keys for each new tunnel.
Negotiation Mode - Aggressive negotiates slightly faster at the expense of some security, and L2TP compatibility. It is there for compatibility purposes.
My Identifier - Think of it as the username for the tunnel
Encryption Algorithm - The encryption of the negotiation tunnel. Blowfish is the most efficient if both sides support it. DES and 3DES are for compatibility purposes, but are not recommended.
Hash Algorithm - How the hashes are generated. SHA1 and MD5 are for compatibility purposes, but are not recommended.
DH Key Group - Higher bitrates are more secure, but also more computationally expensive. 2048 is currently recommended best practices.
Lifetime - This is the lifetime of the negotiation tunnel, not the encryption tunnel. It must be shorter then the Phase 2 lifetime. Generally, a few minutes here is fine.
Authentication Method - Where you choose a share key or a cert.
Pre-Shared Key - A shared passphrase. Long is good here. Both sides can see this key in the config.
Certificate - The certificate of an RSA key.
Key - The private key of an RSA key.
Peer certificate - The certificate of the other side. The private key on the other side remains a secret.
Phase 2 proposal (SA/Key Exchange) - This is where the negotiated keys in Phase 1 are exchanged and the actual tunnel that passes traffic if built.
Protocol - You can choose AH for no encryption. This is not secure. It is there for compatibility purposes.
Encryption Algorithms - The encryption of the actual tunnel. Blowfish is the most efficient if both sides support it. DES and 3DES are for compatibility purposes, but are not recommended.
Hash Algorithms - How the hashes are generated. SHA1 and MD5 are for compatibility purposes, but are not recommended.
PFS Key Group - Perfect Forward Secrecy is a property of key-agreement protocols ensuring that a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future. http://en.wikipedia.org/wiki/Forward_secrecy It is another layer to the security onion. It is commonly left off, and is not supported by all routers.
Lifetime - This is the lifetime of the data tunnel. After this amount of time, an new set of keys in negotiated. This means that a bad actor would now have to hack an entirely new key. 28800 seconds (8 hours) is a good default here with reasonable encryption. If forced to use broken encryption due to compatibility reasons, a shorter interval can make things a bit more secure for real time access, but not for offline analysis of packet captures.
This is the current best practice for standards based, on demand, VPN tunnels. It is one of only two methods supported by Chromebooks.
Enabling L2TP will instantly break any IPsec tunnels negotiated with Aggressive Mode. Makes sure you do not have any Aggressive tunnels.
IPSEC PSK - A shared passphrase. Long is good here. Both sides can see this key in the config.
Server address - Think of this as the gateway address to your subnet.
Remote address range - This is actually a range of IP addresses, but a real subnet. And it can be within your LAN network (but not your DHCP scope) and will appear as local addresses.
Users tab - The user names and password for the L2TP server only. This is separate from Captive Portal users, Web GUI users, or PPTP VPN users.
Passwords for VPN users are stored in the config file in clear text. This is a limitation of the VPN server. Keep your config file secure for password security.
PPTP is the original on demand VPN protocol. Microsoft introduced the Point-to-Point-Tunneling-Protocol (PPTP) with Windows 95. (It was called "Dial-Up-Networking) The initial implementation (20 years ago) had essentially no security. Since then, it has improved, but it is still not considered "secure" anymore as there are known vulnerabilities in the more secure algorithms as well. Additionally, it can easily be misconfiguration to connect with no encryption, even when it is available on both sides.
On the other hand, the client is in everything! (But Chromebooks) Any system you are likely to find yourself on will have a pptp client available. This ubiquity is why it is still very useful.
PPTP Redirection - You can redirect incoming PPTP connections to a Windows 95 "Server" with Dial-Up Networking enabled, or whatever other server you have providing it.
Server address - Think of this as the gateway address to your subnet.
Remote address range - This is actually a range of IP addresses, but a real subnet. And it can be within your LAN network (but not your DHCP scope) and will appear as local addresses.
RAIDUS - You can use a RADIUS server for authentication instead of the local user list.
Require 128-bit encryption - This prevents clients from negotiating down to less secure encryption..
Users tab - The user names and password for the PPTP server only. This is separate from Captive Portal users, Web GUI users, or L2TP VPN users.
Passwords for VPN users are stored in the config file in clear text. This is a limitation of the VPN server. Keep your config file secure for password security.