All current Opengear products support IPsec VPN using the Linux Openswan/KLIPS implementation.
Your Opengear device can use IPsec to securely connect and route between two or more LANs (aka site to site, LAN-to-LAN, L2L VPN), or as a single client endpoint connecting to a central LAN or endpoint (aka host to site or host to host).
IPsec does not make a formal distinction between client and server, however the Opengear can both initiate tunnels (as a "client") and have other devices initiate tunnels to it (as a "server").
Due to its security-centric design, IPSec interoperability can be fickle. When configuring a tunnel, the best place to start is Opengear's interoperability guides:
- To create a tunnel to a Cisco IOS or ASA device: AppNote_IPsec_Cisco_ASA_and_1700_Series-v1.1.pdf
- To create a tunnel between two Opengear devices: AppNote- Opengear IPsec tunnel VPN.pdf
- To create a tunnel to a Fortigate device: AppNote_IPsec_Fortigate_v1.0.pdf
- To create a tunnel to Check Point device: Tunnel to Check Point R75.40 Gateway using X.509 certificates
- To create a tunnel from the Shrew Soft Windows VPN client: AppNote- Shrew Soft IPsec VPN
Note: Concerning Cisco interoperability, Opengear devices support is for policy based VPN only, route based VPN and DMVPN are not supported. L2TP or GRE over IPsec are also not supported. X.509 certificate authentication is not supported via GUI configuration.
If you hit issues or have any queries regarding IPsec interoperability, contact Opengear support.
IPsec has many options and unless both ends of the tunnel match, the tunnel will not initiate or will not be stable.
Note: In IPsec parlance, "Left" always refers to the device you are currently configuring, and "Right" refers to the device at the other end of the tunnel.
The following provides an overview of the IPsec configuration UI on the Opengear device:
- Login to the Opengear we UI as root or an admin group user
- Click Serial & Network -> IPsec VPN -> Add
- Tunnel Name is an arbitrary descriptive name for the tunnel, a useful convention is: LeftDevice_to_RightDevice, e.g. MyOpengear_to_MyCisco
- Check Initiate Tunnel and make an outbound connection to the right device to bring up the tunnel, i.e. be the "client" end (this is particularly useful if this device has a dynamic or NATed IP address)
- Authentication Method may be:
- via setting a Shared secret (PSK) aka pre-shared key – this is the most common option
- via RSA digital signatures – after generating a key, paste the displayed Left Public Key into the right device's Left Public Key field (or equivalent), and vice versa
- Authentication Protocol may be via ESP (most common) or AH (uncommon)
- Check Aggressive Mode if one of the devices has a dynamic IP address, if both ends have known static IP addresses you may leave this unchecked to use Main Mode
- Note: Using Aggressive Mode with Shared secret (PSK) authentication makes the tunnel more vulnerable to brute force attack – in this case it is particularly important to choose a strong shared secret
- Choose an explicit IKE Proposal (Phase 1), if you are using Main Mode you may leave this blank and it will be negotiated
- Check Perfect Forward Secrecy, generally this is desirable unless the right device doesn't support it
- Left and Right ID:
- Left ID is a name for this end of the connection used to identify this device with the right device, it must contain the "@" character, a useful convention is: @LeftDevice e.g. @MyOpengear
- In Right ID enter the identifying name of the right device, e.g. @MyCisco
- If Left ID and Right ID are left blank, the devices' IP addresses will be used to identify either end – in practically this is only feasible if both ends have known static IP addresses
- Left and Right Address:
- You can generally leave Left Address blank, it will be automatically detected
- The Right Address is the public address of the right device, you must enter this if you have checked Initiate Tunnel otherwise you can generally leave it blank
- Left and Right Subnet:
- Left Subnet is the CIDR network address of the LAN behind this device, i.e. the local network to route via this tunnel, e.g. 192.168.0.0/24
- Right Subnet is the CIDR network address of the LAN behind the right device, i.e. the remote network to route via this tunnel, e.g. 10.10.0.0/16
- For site to site VPN: Enter both Left and Right Subnets, otherwise for host to site VPN: leave Left Subnet blank and enter a Right Subnet
- You may enter Custom Tunnel Options to write to /etc/config/ipsec.config.conf – these will override any values entered through UI fields above
- Click Apply
Using the example of an Opengear to Opengear tunnel, the following image illustrates fields that must match between left and right devices, fields that are transposed between left and right devices, and fields unique to the left device:
To troubleshoot, first login to the Opengear CLI as root or as an admin user and become root with: sudo -s
Check whether the tunnel has established, run:
ipsec auto --status
If you see a security association (SA) that is "eroute", the tunnel has established successfully, e.g.:
000 "BranchACM_to_CentralIM/1x1": 192.168.0.0/24===192.168.0.1[@BranchACM,+S=C]...220.127.116.11<18.104.22.168>[@CentralIM,+S=C]===10.10.0.0/16; erouted; eroute owner: #2
Test traffic is being passed across the tunnel by pinging an address on the Right Subnet, note that you may have to force the Opengear device to route via the IPsec tunnel, e.g.:
ping -I ipsec0 10.10.0.1
While pinging, test whether traffic is traversing the tunnel (inspect traffic inside the tunnel):
tcpdump -ntl -i ipsec0
While pinging, test whether encrypted traffic is being sent and received (inspect traffic from outside the tunnel):
tcpdump -ntl -i wwan0 ip proto 50 or udp port 500 or udp port 4500
.. where wwan0 is the interface via which tunnel is being established.
To restart the tunnel from the CLI run:
ipsec setup --restart
The following guide shows how IPsec VPN can integrate with Auto-Response: