OSPF over GRE over IPsec is a network design approach that combines dynamic routing, tunnel encapsulation, and encrypted transmission. It is commonly used in scenarios where multiple sites need to be interconnected securely and flexibly over untrusted networks, such as the Internet.

In this architecture, GRE is first used to establish a logical tunnel. This enables networks that do not support multicast or dynamic routing protocols to carry OSPF packets, thereby achieving dynamic route learning and automatic route convergence. Then, IPsec encryption is applied outside the GRE tunnel to ensure confidentiality, integrity, and authentication for all transmitted data.

Based on the principle of "first encapsulation and then encryption", this approach not only overcomes the limitation that IPsec does not natively support multicast (which affects OSPF neighbor establishment), but also provides enterprise-level security protection.

Example topology:

Prerequisites:

1. The Athena NGFW device is deployed in a mode that supports establishing an IPsec VPN tunnel with a third-party device. To be specific, at least one routed interface can be used for IPsec VPN establishment. The pure transparent mode and the virtual wire mode cannot be used for IPsec VPN establishment because they do not provide Layer-3 routed interfaces.

2. Your Ethernet interfaces and zone configurations are correct. For more information, see the "Interface" and "Zone" section.

3. Athena NGFW has the IPsec VPN module enabled and is licensed for branches. For more information, see the "Device Management and License Activation" and "License Introduction" section.

4. A fixed IP address or a fixed domain name is configured on at least one end (either the local or the peer).

5. The peer device supports the standard IPsec VPN protocol and IKEv1. Athena NGFW supports IKEv2 since 8.0.23.

6. The IPsec VPN tunnel information on the peer device is available, including the IP address, whether it has an internet address, and whether NAT is involved.

Configure the basic network:

Step 1. Define zones. Policies, such as ACL and content security policies, control traffic within an IPsec VPN tunnel based on selected zones and network objects. For this reason and for easier management, zones must be defined first. Specifically, log in to the web console of each of the HQ and branch Athena NGFW devices, go to Network > Zones, and click Add to create two zones. Then, associate the two zones with the interface used to establish an IPsec VPN tunnel with the peer device and the vpntun interface used for communication after the IPsec VPN tunnel is established. This way, after the IPsec VPN tunnel is established, ACL and content security policies can allow traffic within the IPsec VPN tunnel based on the selected zones.

Make sure that the vpntun interface you select here is the default vpntun interface of Athena NGFW instead of a newly added one. On Athena NGFW, the default vpntun interface is used for the policy-based IPsec VPN, whereas custom vpntun interfaces are used for the route-based IPsec VPN.

Step 2. Configure the VPN WAN interface, which is used to establish an IPsec VPN tunnel with the peer device. Specifically, log in to the web console of each of the HQ and branch Athena NGFW devices, go to Network > Interfaces > Physical Interfaces, select the interface used to establish an IPsec VPN tunnel with the peer device, and configure a default gateway for the interface. If no default gateway is configured, the interface cannot communicate with the peer device after the IPsec service is enabled. Configure the VPN WAN interfaces on the HQ device:

Configure the VPN WAN interfaces on the branch device:

Step 3. Configure the VPN interface. Specifically, log in to the web console of both the HQ and branch Athena NGFW devices, go to Network > Networks > Physical Interfaces, and configure a VPN tunnel interface. Make sure that the IP addresses of the VPN tunnel interfaces configured on the HQ and branch devices are different.

VPN tunnel interface on the HQ device:

VPN tunnel interface on the branch device:

Athena NGFW supports using a physical interface, a VLAN interface, a subinterface, or an aggregate interface as the VPN WAN interface, without the need to enable the WAN attribute for the interface.

Configure the VPN service:

Step 1. Enable the VPN service. Specifically, log in to the web console of each of the HQ and branch Athena NGFW devices, go to Network > Sangfor/IPsec VPN > VPN Status, and select Enable VPN service. An IPsec VPN tunnel can be established with the peer end only after the VPN service is enabled.

Step 2. Configure a VPN link. Specifically, log in to the web console of each of the HQ and branch Athena NGFW devices, go to Network > Sangfor/IPsec VPN > General Settings > VPN Links, and click Add. In the dialog box that appears, select the interface used to establish the IPsec VPN tunnel with the peer device, specify the ISP, and enter the public IP address. A VPN link must be configured in advance before it can be selected during IPsec VPN configuration to establish an IPsec VPN tunnel with the peer device. If multiple WAN links are used to establish IPsec VPN tunnels with the peer device, multiple VPN links must be created.

VPN link for the HQ device:

VPN link for the branch device:

Configure IKE and IPsec parameters:

Step 1. Log in to the web console of each of the HQ and branch Athena NGFW devices, go to Network > Sangfor/IPsec VPN > IPsec VPN, and click Add Device. In the Add Device dialog box that appears, configure parameters based on the network settings on the local and peer ends.

Configure the IPsec VPN tunnel on the HQ device:

Specifically, in the Add Device dialog box, configure Device Name, Description, Status, Protocol, Peer Address Type, Peer IP Address, Auth Method, Shared Key, Confirm Key, and Local Outbound Interface based on the network settings on the local and peer ends. Since the HQ device and the branch device each have only one WAN link, the IPsec VPN tunnel is established between the WAN1 link on the HQ device and the WAN1 link on the branch device.

Configure the IPsec VPN tunnel on the branch device:

Specifically, in the Add Device dialog box, configure Device Name, Description, Status, Protocol, Peer Address Type, Peer IP Address, Auth Method, Shared Key, Confirm Key, and Local Outbound Interface based on the network settings on the local and peer ends.

Parameter	Description	Consistency on Both Ends
Device Name	Specify a name used to identify this IPsec VPN tunnel. We recommend that you use an easily recognizable name for easier management.	No. It can be locally customized.
Description	Enter a description for the tunnel. We recommend that you enter the tunnel purpose or additional information for easier O&M management.	No. It can be customized.
Status	Select whether to enable or disable the tunnel. We recommend that you enable the tunnel for production use. When you disable the tunnel, the connection can be temporarily stopped but the configuration is retained.	No. It can be independently configured on the local device.
Protocol	Select the protocol. Supported protocols include IPv4 and IPv6. We recommend that you select the protocol based on the network environment.	Yes. Make sure that the protocol selected on the local device matches that on the peer device.
Peer Address Type	Select the address type for the peer device. Three address types are included: Static IP, Dynamic Domain, and Dynamic IP. If Static IP is selected, enter the IP address of the peer device. If Dynamic Domain is selected, enter the domain name bound to the WAN interface on the peer device. Select the address type based on the actual peer environment.	No. It needs to match the actual address type on the peer device.
Authentication Methods	Select the authentication method. Supported authentication methods include Pre-shared key, Certificate based, and SM2 certificate V1.1. We recommend that you make selection based on your actual requirements. Pre-shared keys are commonly used in enterprise environments, whereas the certificate-based method is suitable for environments with high security requirements.	Yes. Both ends must be consistent.
Shared Key and Confirm Key	Enter the correct pre-shared key, and make sure that both ends use the same key. We recommend that you use a complex and consistent key to avoid connection failures.	Yes. Both ends must be consistent.
Local Outbound Interface	Select the corresponding outbound link based on the actual network environment. We recommend that you select the primary outbound link. A backup link can also be configured when necessary.	No. It can be independently configured on the local device.
Encrypted Traffic	Configure the interesting traffic for the standard IPsec VPN and the Phase 2 negotiation parameters. We recommend that you configure the traffic based on the local and peer subnets that require encryption.	Yes. Make sure that the local and peer subnets match.

Step 2. On the Policy Mode tab, click Add next to Encrypted Traffic to configure the interesting traffic and negotiation parameters. Take note that Local IP and Peer IP are set to the addresses you specified for the VPN tunnel interfaces configured on the local and peer devices. This is because a GRE tunnel is usually established based on the addresses of VPN tunnel interfaces.

Configure encrypted traffic settings on the HQ device:

Specifically, configure Protocol, Local IP, Local Intranet Service, Peer IP, Peer Intranet Service, Phase 2 Proposal, and Route Priority as required.

Configure encrypted traffic settings on the branch device:

Specifically, configure Protocol, Local IP, Local Intranet Service, Peer IP, Peer Intranet Service, Phase 2 Proposal, and Route Priority as required.

When configuring encrypted traffic on the HQ and branch devices, make sure that the local subnet on the HQ device matches the peer subnet on the branch device, and that the peer subnet on the HQ device matches the local subnet on the branch device. Otherwise, the negotiation will fail.

Parameter	Description	Consistency on Both Ends
Local IP	Specify the source IP matching rule for IPsec VPN interesting traffic. You can enter a single IP address or subnet. We recommend that you configure this parameter based on the local intranet subnet to avoid missing or incorrect matches. Take note that precise configuration improves security, whereas overly broad configuration may cause unrelated traffic to be encrypted.	Yes. It must match the peer interesting traffic settings.
Local Intranet Service	Select the local service matching rule. Valid values: All Services, All TCP Services, All UDP Services, and All ICMP Services. We recommend that you make selection based on actual business requirements and use a precise matching rule to prevent unrelated traffic from being encrypted.	Yes. It must match the peer service type.
Peer IP	Specify the destination IP matching rule for IPsec VPN interesting traffic. You can enter a single IP address or subnet. We recommend that you configure this parameter based on the peer intranet subnet to ensure that target traffic is correctly encrypted.	Yes. It must match the peer interesting traffic settings.
Peer Intranet Service	Select the peer service matching rule. Valid values: All Services, All TCP Services, All UDP Services, and All ICMP Services. We recommend that you make selection based on actual business requirements and use a precise matching rule.	Yes. It must match the peer service type.
Phase 2 Proposal	Select the protocol, encryption algorithm, authentication algorithm, and whether to enable perfect forward secrecy (PFS). Supported protocols include AH and ESP. Supported encryption algorithms include DES, 3DES, AES, AES192, AES256, SANGFOR_DES, and SM4. Supported authentication algorithms include MD5, SHA1, SHA2 series, and SM3. Make sure that the Phase 2 proposal settings on the local end are consistent with those on the peer end. For environments with high security requirements, a combination of ESP, AES256, SHA2-256, and PFS is recommended. For common enterprise environments, a combination of AES128 and SHA1 can be used. Take note that strong encryption provides higher security but increases CPU overhead, whereas DES is insecure.	Yes
Route Priority	Specify the route priority of the tunnel when multiple VPN tunnels exist. A smaller value indicates a higher priority. Make sure that the priority is properly configured so that critical traffic uses the correct tunnel. Improper configuration may cause traffic to preferentially enter a lower-priority tunnel.	No. It can be independently configured on the local device.

Step 3. Configure IKE settings. Specifically, in the lower-left corner of the Add Device dialog box, click Advanced. In the Advanced dialog box that appears, configure IKE settings on the IKE Options tab as required. This configuration must be completed on both the HQ and branch Athena NGFW devices.

Configure IKE settings on the HQ device:

Specifically, configure IKE settings such as IKE Version, Mode, Initiate Connection, Local ID Type, Peer ID Type, IKE SA Timeout (secs), DH Group, DPD, NAT-T, and Phase 1 Proposal based on the network settings on the local and peer ends. Since the aggressive mode cannot predefine the peer identity and allows negotiation initiation from dynamic IP addresses, we recommend that you use the aggressive mode when either end uses a dynamic IP address.

Configure IKE settings on the branch device:

Specifically, configure IKE settings such as IKE Version, Mode, Initiate Connection, Local ID Type, Peer ID Type, IKE SA Timeout (secs), DH Group, DPD, NAT-T, and Phase 1 Proposal based on the network settings on the local and peer ends. Since the aggressive mode cannot predefine the peer identity and allows negotiation initiation from dynamic IP addresses, we recommend that you use the aggressive mode when either end uses a dynamic IP address.

1. IKEv1 has better compatibility but limited functionality. Considering that the peer device may not support IKEv2 and that IKEv1 configuration is more complex, the foregoing configuration examples use IKEv1 for demonstration. In actual deployments, we recommend that you preferentially use IKEv2 for negotiating secure protocols.

2. We recommend that you configure Detection Interval (secs) and Max Attempts for DPD based on business needs. If high business continuity is required, set the two parameters to smaller values. For example, you can set both Detection Interval (secs) and Max Attempts to 3. This way, if over 3 consecutive timeouts are detected at the detection interval of 3 seconds, the VPN tunnel is considered interrupted, and the traffic is switched to another tunnel.

Parameter	Description	Consistency on Both Ends
IKE Version	Select IKEv1 or IKEv2. IKEv2 provides more advanced features and supports fast renegotiation and multiple tunnels, whereas IKEv1 offers better compatibility but limited functionality. Make sure that the IKE version on the local device is consistent with that on the peer device. IKEv2 is recommended if it is supported on the peer device. IKEv1 is recommended for mixed environments.	Yes
Mode	Select the negotiation mode. Two modes are supported: main mode and aggressive mode. The main mode provides higher security but does not support NAT traversal. This mode is suitable when both ends use fixed IP addresses or when one end uses a fixed IP address and the other uses a dynamic domain name. The aggressive mode supports NAT traversal, and is suitable when one end uses dial-up access or a dynamic IP address. Select the appropriate mode based on the actual deployment scenario.	Yes
Initiate Connection	Select whether to enable the local device to proactively initiate the tunnel establishment process. Proactive initiation reduces the tunnel establishment delay but may trigger policy conflicts. We recommend that you enable the end that uses a dynamic IP address to proactively initiate the connection, whereas the end that uses a fixed IP address remains passive. In dial-up or branch scenarios, the branch side is typically configured to proactively initiate tunnel establishment, whereas the fixed-IP side can remain passive.	No. It depends on the network policy.
Local ID Type	Select the local ID type and then enter the local ID to ensure that the peer device can identify the local device. Supported ID types include IPV4_ADDR, FQDN, and USER_FQDN. We recommend that you use IPV4_ADDR for fixed IP addresses, and FQDN for dynamic IP or domain name environments. Improper configuration may cause Phase 1 negotiation to fail. Therefore, select the appropriate ID type and ID based on the network environment.	Yes
Peer ID Type	Select the peer ID type and then enter the peer ID to ensure that the local device can identify the peer device. The ID type and ID must match the peer configurations. Otherwise, Phase 1 negotiation may fail. Select the appropriate ID type and ID based on the network environment.	Yes
IKE SA Timeout (secs)	Specify the lifetime of the Phase 1 SA, in seconds. We recommend that you use a longer lifetime in stable network environments and a shorter lifetime in environments with frequent disconnections. An excessively short lifetime causes more frequent renegotiation, whereas an excessively long lifetime consumes more resources.	Yes
DH Group	Select the DH key exchange group such as group 1, 2, 5, 14, 15, 16, 17, or 18. Make sure that the DH group on the local device is the same as that on the peer device. We recommend that you select a larger group such as 14, 15, or 16 for environments with high security requirements, and a medium-sized group for common enterprise environments. A larger group provides higher security but increases computational overhead.	Yes
DPD/NAT-T	DPD is used to detect whether the peer device is alive, whereas NAT-T is used for NAT traversal. We recommend that you enable DPD, and set Detection Interval (secs) to a value from 10 to 30 and Max Attempts to a value from 3 to 5. In NAT environments, NAT-T must be enabled to prevent ESP encapsulation from being blocked, and to ensure that traffic is encapsulated and transmitted over UDP. DPD enables fast detection of failed peers, whereas NAT-T resolves NAT traversal issues but increases UDP encapsulation overhead.	DPD can be enabled on only one end, whereas NAT-T must be negotiated by both ends.
Phase 1 Proposal	Select the encryption algorithm and authentication algorithm. Supported encryption algorithms include DES, 3DES, AES, AES192, AES256, SANGFOR_DES, and SM4. Supported authentication algorithms include MD5, SHA1, SHA2-256, SHA2-384, SHA2-512, and SM). Make sure that the Phase 1 proposal settings on the local end are consistent with those on the peer end. For environments with high security requirements, a combination of AES256 and SHA2-256 is recommended. For common enterprise environments, a combination of AES128 and SHA1 can be used. Take note that stronger encryption provides higher security but increases CPU overhead, whereas DES is insecure.	Yes

Step 4. After the IKE settings are completed, click the Other tab in the Advanced dialog box to configure parameters such as Max Attempts and IPsec SA Timeout (secs) as required. After all necessary parameters are configured, click OK.

Parameter	Description	Consistency on Both Ends
Max Attempts	Specify the maximum number of attempts allowed for establishing a standard IPsec VPN tunnel. We recommend that you configure this parameter based on network stability. In general, 3 to 5 attempts are recommended. In unstable network environments, you can increase the number of attempts. Take note that an excessively small number of attempts may cause tunnel establishment to fail during temporary network fluctuations, whereas an excessively large number of attempts may delay the detection of an unreachable peer device.	No. It needs to be configured only on the local end.
IPsec SA Timeout (secs)	Specify the lifetime of the IPsec SA, in seconds. This parameter controls the tunnel renegotiation frequency. We recommend that you configure this parameter based on network stability and traffic conditions. In general, set this parameter to a value from 3600 to 86400. Take note that an excessively short lifetime increases renegotiation frequency and CPU overhead, whereas an excessively long lifetime consumes more resources and delays fault detection.	Yes. We recommend that you set this parameter to the same value as that on the peer device.
Expiration Time	Select whether to enable or disable the expiration feature of the IPsec VPN tunnel. We recommend that you enable this feature if you want the system to automatically clean stale tunnels. For long-term stable tunnels, disable this feature. Take note that enabling this feature facilitates management but may result in unexpected tunnel disconnections, whereas disabling this feature enhances tunnel stability but requires manual maintenance.	No. It can be configured based on policies and requirements.

Step 8. Check the parameters to ensure that the IPsec VPN tunnel settings on the local Athena NGFW device match those on the peer device. Then, click OK to submit the policy.

IPsec VPN tunnel configured on the HQ device:

IPsec VPN tunnel configured on the branch device:

Configure a traffic allow policy:

Step 1. Configure an application control policy. Specifically, log in to the web console of each of the HQ and branch Athena NGFW devices, go to Policies > Access Control > Application Control > Policies, and click Add. In the dialog box that appears, set both Src Zone and Dst Zone to the zones associated with the IPsec VPN tunnel and the GRE tunnel, and Services to any. After necessary parameters are configured, click Save to submit the policy. This policy ensures that traffic between the local and peer networks is allowed.

That Services in the application control policy is set to any is used only as an example for your reference. In actual business scenarios, allow traffic for specific zones and network objects based on the actual network management requirements.

Configure a GRE tunnel:

Log in to the web console of each of the HQ and branch Athena NGFW devices, go to Network > Interfaces > GRE Tunnels, and click Add to add a GRE tunnel. For more information about configuration details, see the "GRE Tunnels" section.

Step 1. Configure the GRE tunnel on the HQ device. Specifically, enter a custom IP address for the GRE tunnel interface, and set the source and destination addresses of the GRE tunnel to the addresses of the local and peer IPsec VPN tunnel interfaces. Make sure that the custom address does not conflict with internal network segments.

To enable the HQ device to check the liveness of both ends and ensure GRE tunnel availability, click Settings next to Advanced to configure the interval for sending keepalive messages and the maximum number of attempts allowed. Specifically, in the Advanced dialog box, select Send keepalive message, and configure Interval (secs) and Maximum Attempts.

Step 2. Configure the GRE tunnel on the branch device. Specifically, set the IP address of the GRE tunnel interface to a custom address, and set the source and destination addresses of the GRE tunnel to the addresses of the local and peer IPsec VPN tunnel interfaces. Make sure that the custom address does not conflict with internal network segments.

To enable the branch device to check the liveness of both ends and ensure GRE tunnel availability, click Settings next to Advanced to configure the interval for sending keepalive messages and the maximum number of attempts allowed. Specifically, in the Advanced dialog box, select Send keepalive message, and configure Interval (secs) and Maximum Attempts.

Step 3. After all necessary parameters of the GRE tunnel are configured, click OK. Then, you can view that the GRE tunnel is established and the keepalive status indicates Valid.

GRE tunnel on the HQ device:

GRE tunnel on the branch device:

Configure the OSPF protocol:

Step 1. Configure the OSPF protocol. Specifically, log in to the web console of each of the HQ and branch Athena NGFW devices, go to Network > Routes > OSPF > OSPF, and click Add. The following content uses the configuration process on the HQ device as an example.

On the HQ device, configure Basics such as Router ID. We recommend that you set Router ID to an IP address that can uniquely identify this device. Then, click OK and Go to Advanced.

In the Edit Advanced dialog box, click Add on the Areas tab. In the Add Area dialog box that appears, enter the network segment to which the GRE tunnel interface belongs, specify the corresponding netmask, and configure other parameters. Then, click OK.

Routes learned through OSPF are not initially included in the local routing table or encryption domain. If route redistribution is performed, these dynamically learned routes cannot be matched by IPsec. As a result, traffic cannot be correctly forwarded into the encrypted tunnel. Therefore, route redistribution is required to import OSPF-learned routes into the corresponding routing or policy framework, to ensure that service traffic can be correctly identified and forwarded through the GRE over IPsec tunnel. To achieve this purpose, go to the Route Redistribution tab in the Edit Advanced dialog box, and click Add. In the Add Route Redistribution dialog box that appears, select the routes to be redistributed, configure other parameters as required, and click OK.

Repeat the same configuration process on the branch device. Make sure that the router ID specified for the branch device can uniquely identify that device.

Step 2. Check the route learning status. Specifically, log in to the web console of the HQ Athena NGFW device, go to Network > Routes > OSPF > OSPF Adjacency to view the OSPF neighbor. The interface name of the neighbor indicates a GRE interface. This means that the OSPF adjacency is established over the GRE tunnel.

Go to Network > Routes > OSPF > OSPF Routes to view the routes learned via OSPF. The Next-Hop IP column of these routes indicates a GRE interface.

Verify the configuration result:

Step 1. Check the IPsec VPN tunnel status. Specifically, log in to the web console of each of the HQ and branch devices, go to Network > Sangfor/IPsec VPN > VPN Status, find the tunnels, and view the tunnel statuses. The result shows that the tunnels have been established.

You can view that the tunnel established on the branch device displays information such as the peer public IP address (Peer’s Public IP), peer private IP address (Peer’s Internal IP), real-time sending rate (Outbound), and real-time receiving rates (Inbound).

Step 2. Attempt to access an address in the peer network from an endpoint PC in the local intranet by using ping, HTTP, or FTP services. The result shows that the access is successful.

Step 3. Since the HQ and branch devices each have only one WAN link, the VPN tunnel will be interrupted when the WAN link of either device goes down, resulting in a communication failure.

{{ $t('index.defaultHeader.logo') }}

Athena NGFW (Next-Generation Firewall)

OSPF over GRE over IPsec Configuration in Policy-Based Mode