VPN Server Authentication with oMG 3.13

Between releases 3.12.1 and 3.13.0 the default oMG VPN Server ID behavior changed because both the operating system and the Strongswan software were upgraded.  

Prior to 3.13.0, if the Server Address was configured in an oMG's VPN settings to be a fully qualified domain name (FQDN) and the Server ID was blank, then the oMG would ask for authentication of the Server ID using the IP address of the FQDN. Since the oCM uses its IP address to confirm the Server ID by default, there would be a match.

In oMG 3.13+, the VPN Strongswan behavior is different: if the Server Address is set to an FQDN and the Server ID is blank, the oMG will ask for authentication using the actual FQDN as the Server ID, preceded by “@” or @FQDN. The oCM still, by default, uses its IP address to confirm the Server ID but consequently there would be a mismatch and therefore the oMG VPN will no longer connect.

There are a variety of ways to resolve this:

Method 1.

On the oMG, set the VPN Server Address to the oCM's IP address and leave the Server ID blank.

The disadvantage to this approach is that if the oCM IP address is ever changed, the Server Address on all oMGs would have to be updated.

Method 2.

On the oMG, leave the Server Address set to the FQDN and enter the Server ID as the IP address of the oCM. Note that if the oCM is behind a firewall, the private IP address of the oCM should be used.

The disadvantage to this approach is that if the oCM's IP address is ever changed, the Server ID on all oMGs would have to be updated.

Method 3.
1. On the oMG, leave the Server Address as the FQDN (e.g. ocm.customer.org).
2. Leave the Server ID blank.
3. Configure each oMG entry on the oCM to use the FQDN as its authentication ID using the following commands on the oCM, replacing the serial number per oMG:

                configure

                set vpn ipsec site-to-site peer @H140512J9999 authentication id @ocm.customer.org

                commit

                save

The advantage to this approach is that changes only need to be made on the oCM.

The disadvantage to the approach is that if the FQDN is ever changed, then both the oMG server address and each individual entry on the oCM will need to be changed. This will require a lot of work to change while trying to keep everything still in service.


Method 4.
1. On the oMG, leave the Server Address as the FQDN.  
2. Set the Server ID to something unique (e.g. “Customer VPN”).
3. Configure each oMG entry on the oCM to use the unique Server ID using the following commands, replacing the serial number per oMG:

                configure

                set vpn ipsec site-to-site peer @H140512J9999 authentication id ‘Customer VPN’ 

                commit

                save

The disadvantage to this approach is the additional up-front set up required, since changes are needed on both the oMG and oCM.

The advantage to this approach is that there is no need for any changes to be made on the oCM or the oMG if the network is changed.