About IPsec VPN
The IPsec VPN service provides secure Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session.
The VPN Overview article provides some general guidance of which VPN technology may be the best fit for different scenarios.
This section reviews the different settings and configuration options available for IPsec VPN.
The Status tab shows the status of the different components of the IPsec application.
- Enabled IPsec Tunnels
- This section shows a list of all IPsec tunnels that have been created and enabled. For tunnels that are active, the status will display the connection details reported by the IPsec subsystem. For inactive tunnels, the configuration information will be displayed.
- Active VPN Sessions
- This section shows a list of all active L2TP and Xauth connections. In addition to the connection details, there is a Disconnect column that can be used to forcefully disconnect an active session. Please note that there is no confirmation when you click the Disconnect icon. The corresponding session will be immediately terminated.
- Bypass all IPsec traffic
- When this checkbox is enabled, traffic from IPsec tunnels will bypass all applications and services on the Untangle server. This was the only behavior available in previous versions of Untangle, so this option is enabled by default to maintain equivalent functionality on upgrade. If you disable this checkbox, traffic from IPsec tunnels can now be filtered through all active applications and services.
- Also please note that this only applies to plain IPsec tunnels. Traffic from L2TP and Xauth VPN clients will always pass through all active applications and services.
The IPsec Tunnels tab is where you create and manage the IPsec VPN configuration. The main tab display shows a summary of all IPsec tunnels that have been created.
- Tunnel Editor
- When you create a new tunnel, or edit and existing tunnel, the tunnel editor screen will appear with the following configurable settings:
|Enabled||This checkbox allows you to set a tunnel to either enabled or disabled.|
|Description||This field should contain a short name or description.|
|Connection Type||This field allows you to set the connection type to any of the following:
|IKE Version||The IKE version to use, either version 1 or version 2. Both endpoints must use the same IKE version.|
|Connect Mode||This field controls how IPsec manages the corresponding tunnel when the IPsec process re-starts:
|Interface||This field allows you to select the network interface that should be associated with the IPsec tunnel on the Untangle server. For most situations choose Active WAN to bind to the active Internet interface. This allows the VPN tunnel to reconnect using a secondary WAN interface in the event of Internet failover. The Active WAN option is available when using the WAN Failover app. Alternatively, you can select a specific interface, or you can manually configure an IP address using the Custom option and manually inputting the IP address.|
|Any remote host||Enabling this option allows the VPN Server to accept tunnel connections from any IP Address. This option enables the remote side of the tunnel to connect from a dynamic IP address or via a secondary WAN link. This option switches the Connect Mode to On Demand and removes the Remote Host field as these options are not used when allowing connections from any remote host.|
|Remote Host||This field should contain the public IP address or DNS name of the host to which the IPsec VPN will be connected.
|Local Identifier||This field is used to configure the local identifier used for authentication. When this field is blank the value in the *External IP* field will be used.|
|Remote Identifier||This field is used to configure the remote identifier used for authentication. When this field is blank, the value in the Remote Host field will be used.
|Local Network||This field is used to configure the local network that will be reachable from hosts on the other side of the IPsec VPN.|
|Remote Network||This field is used to configure the remote network that will be reachable from hosts on the local side of the IPsec VPN.|
|Shared Secret||This field should contain the shared secret or PSK (pre-shared key) that is used to authenticate the connection, and must be the same on both sides of the tunnel for the connection to be successful. Because the PSK is actually used as the encryption key for the session, using long strings of a random nature will provide the highest level of security.|
|DPD Interval||The number of seconds between R_U_THERE messages. Enter 0 to disable this feature.|
|DPD Timeout||The number of seconds for a dead peer tunnel to be restarted.|
|Ping Address||The IP address of a host on the remote network to ping for verifying that the tunnel is connected and routing. Leave blank to disable.|
|Ping Interval||The time in minutes between ping attempts of the ping address. Leave as 0 to disable. Recommended value is 1 when using a Ping address.|
|Authentication and SA/Key Exchange||If you leave the Phase 1 and Phase 2 manual configuration checkboxes disabled, IPsec will attempt to automatically negotiate the encryption protocol with the remote peer when creating the tunnel. Given the number of different IPsec implementations and versions, as well as the overall complexity of the protocol, best results can often be achieved by enabling manual configuration of these two options, and selecting Encryption, Hash, DH Key Group, and Lifetime values that exactly match the settings configured on the peer device.|
The VPN Config tab manages the L2TP/Xauth/IKEv2 server configuration, enabling VPN client connections from remote desktops and mobile devices. IPsec is a preferred option because it uses native VPN software built into most systems, and therefore does not require installation of 3rd party software. When available, use IKEv2 type of VPN connections for optimal performance and compatibility.
- Enable L2TP/Xauth/IKEv2 Server
- Use this checkbox to enable or disable the L2TP/Xauth/IKEv2 server.
- L2TP Address Pool
- This field configures the pool of IP addresses that will be assigned to L2TP clients while they are connected to the server. The default 198.18.0.0/16 is a private network that is generally reserved for internal network testing. It was chosen as the default because it is used less frequently than other RFC-1918 address blocks, and thus is less likely to conflict with existing address assignments on your network.
- Xauth Address Pool
- This field configures the pool of IP addresses that will be assigned to Xauth clients while they are connected to the server. The default 198.19.0.0/16 is a private network that is generally reserved for internal network testing. It was chosen as the default because it is used less frequently than other RFC-1918 address blocks, and thus is less likely to conflict with existing address assignments on your network.
- Custom DNS Servers
- Leave both of these fields blank to have L2TP and Xauth clients use the Untangle server for all DNS resolution. Alternatively, if you have other DNS servers you want clients to use, you can enter IP addresses in these fields.
- IPsec Secret
- This is the shared secret that will be used between the client and server to establish the IPsec channel that will secure all L2TP and Xauth communications.
- Allow Concurrent Logins
- If enabled, the same credentials can be authenticated simultaneously from multiple devices.
- User Authentication
- In addition to the IPsec Secret configured above, VPN clients will also need to authenticate with a username and password. To use the Local Directory, select this option and click the Configure Local Directory button to manage use credentials. Alternatively, you can use an external RADIUS server for authentication by selecting the RADIUS option, and clicking the Configure RADIUS button to configure the RADIUS server options.
- Server Listen Addresses
- This list is used to configure one or more of your server IP addresses to listen for inbound VPN connection requests from remote clients. Clicking the add button will insert a new line allowing the entry of another server IP address.
The GRE Networks tab is where you create and manage connections to remote GRE servers. Generic Routing Encapsulation (GRE) is a tunneling protocol that can encapsulate a wide variety of network layer protocols inside virtual point-to-point links over an Internet Protocol network.
GRE Address Pool
This field configures the pool of IP addresses that will be assigned to interfaces created and associated with tunnels added on the GRE Networks tab. The default 198.51.100.0/24 is a private network that is generally reserved for internal network testing. It was chosen as the default because it is used less frequently than other RFC-1918 address blocks, and thus is less likely to conflict with existing address assignments on your network. If you use GRE to connect multiple Untangle servers together, you may need to configure a different, unused pool on each server.
The main tab display shows a summary of all GRE Networks that have been created.
- Network Editor
- When you create a new GRE Network, or edit and existing network, the network editor screen will appear with the following configurable settings:
|Enable||This checkbox allows you to set a network to either enabled or disabled.|
|Description||This field should contain a short name or description.|
|Interface||This field allows you to select the network interface that should be associated with the GRE Network on the Untangle server. When you select a valid interface, the Local IP field (see below) will automatically be configured with the corresponding IP address. If for some reason you want to manually configure an IP address that is not currently active, you can set the Interface to Custom and manually input the IP address below.|
|External IP||Use this field to configure the IP address that is associated with the GRE Network on the Untangle server. Normally this field will be read-only and will automatically be populated based on the Interface selected above. If you select Custom as the interface, you can then manually enter the local IP address.|
|Remote Host||This field should contain the public IP address of the host to which the GRE tunnel will be connected.|
|Remote Networks||This field is used to configure the list of remote network traffic that should be routed across this GRE tunnel. Networks should be entered one per line in CIDR (192.168.123.0/24) format.|
The IPsec State tab allows you to see the status of all established IPsec connections. There will typically be two entries per tunnel, one with details about the local side of the connection, and another with details about the remote side of the connection.
The IPsec Policy tab allows you to see the routing table rules associated with each IPsec VPN that is active.
The IPsec Log tab allows you to see the low level status messages that are generated by the underlying IPsec protocol components. This information can be very helpful when attempting to diagnose connection problems or other IPsec issues.
The L2TP Log tab allows you to see the low level status messages that are generated by the underlying L2TP protocol daemon. This information can be very helpful when attempting to diagnose connection problems or other L2TP issues.
The Reports tab provides a view of all reports and events for all connections handled by IPsec VPN.
This applications reports can be accessed via the Reports tab at the top or the Reports tab within the settings. All pre-defined reports will be listed along with any custom reports that have been created.
Reports can be searched and further defined using the time selectors and the Conditions window at the bottom of the page. The data used in the report can be obtained on the Current Data window on the right.
Pre-defined report queries:
|IPsec VPN Summary||A summary of IPsec VPN actions.|
|Hourly Tunnel Traffic||The amount of IPsec tunnel traffic over time.|
|Top Tunnel Traffic||The amount of traffic for each IPsec tunnel.|
|Top Active Users||The top IPsec VPN users by number of sessions.|
|Top Download Users||The top IPsec users grouped by amount of data downloaded.|
|Top Upload Users||The top IPsec users grouped by amount of data uploaded.|
|Top Protocols||The top IPsec VPN connections by protocol.|
|L2TP/Xauth Events||Shows all user L2TP/Xauth events.|
|Tunnel Connection Events||Shows all IPsec VPN tunnel connection events.|
|Tunnel Traffic Events||Shows all IPsec tunnel traffic statistics events.|
The tables queried to render these reports:
IPsec VPN FAQs
What's the difference between tunnel and transport mode?
When using tunnel mode, you can think of the payload packet as being completely encased in another packet. In addition, IPsec can allow or deny packets access to the tunnel depending on policies. When using transport mode, communication is limited between two hosts. Only one IP header is present, with the rest of the packet being encrypted. Unless you have very specific needs, you'll most likely want to use tunnel mode.
How do I configure MacOS IKEv2 VPN
If I install NG Firewall behind a NAT device, what do I need to forward to NG Firewall for IPsec VPN to connect?
You will need to forward ESP, AH, and UDP port 500 from the public IP to the NG Firewall server. You may also need to enable NAT traversal. It is recommended to give NG Firewall a public IP if you want to set up IPsec tunnels.
Can I use IPsec on a server that uses DHCP to get its external address?
It is generally recommended to use IPsec VPN only on NG Firewall servers configured with static IPs. However, technically it can work with DHCP, but you will need to reconfigure the tunnel whenever the IP address actually changes. On some ISPs this is rare and servers will often have the same IP for months. On other ISPs IPs change daily.
Does IPsec traffic go through other NG Firewall applications?
Yes and Maybe. IPsec tunnel traffic and traffic from L2TP and Xauth clients will pass through all the other apps just like any other LAN traffic. However, if you want IPsec tunnel traffic to bypass scanning by other applications you can add a bypass rule.
Note: In versions prior to 16.2, the default was to bypass all IPsec tunnel traffic (but not L2TP or Xauth). You may still have a bypass rule in place to Bypass all IPsec traffic which will cause the traffic to not be scanned by other apps.