This article provides an example of configuring generic routing encapsulation (GRE) over an IP Security (IPsec) tunnel on SRX devices.
Overview
The primary use of GRE is to carry non-IP packets via an IP network, with the original IP header buried inside the GRE header (GRE is also used to carry IP packets via an IP cloud). However, GRE tunnels offer minimal security, whereas IPsec offers security in terms of confidentiality, data authentication, and integrity assurance even though it cannot directly support multicast packets. However, if an encapsulated GRE tunnel is used first, the IPsec tunnel can be used to provide security to multicast packets.
In a GRE over IPsec tunnel, all of the routing traffic (IP and non-IP) can be routed through because when the original packet (IP/non-IP) is GRE encapsulated, it will have an IP header (as defined by the GRE tunnel, which is normally the tunnel interface IP addresses). The IPsec protocol can, therefore, understand the IP packet and so it can encapsulate the GRE packet to make it GRE over IPsec.
However, GRE over IPsec has a few limitations in Junos OS (flow mode):
The IPsec tunnel needs to be route based.
The GRE endpoint and the IPsec endpoint cannot be the same to ensure that the GRE packets go over the IPsec tunnel.
These issues can be addressed in the following ways:
Use a numbered interface in st0 and the st0 IP address as the GRE endpoint.
Use a loopback interface as the GRE endpoint and route this IP address to st0.
Configure the GRE tunnel. For more information, refer to KB19371 - [SRX] GRE Configuration Example [juniper.net] .
Configure a static route with the destination as the remote subnet via the GR interface.
Here, the entire traffic to the remote subnet will first be encapsulated into the GRE IPv4 address, and then routed via the IPsec tunnel.
The local subnet interface is ge-0/0/0 with the IPv4 address of 10.10.11.1/24.
The destination subnet is 10.10.10.0/24 with the tunnel endpoint IPv4 interface set to 10.10.10.1.
The GR tunnel endpoints have loopback addresses on both the sides, with the local loopback IPv4 address of 172.20.1.1 and the remote loopback IPv4 address of 172.20.1.2.
The gr, st0.0, and lo0 interfaces are bound to a security zone and policies are created accordingly.
[edit interfaces] root@Juniper# show ge-0/0/0 { unit 0 { family inet { address 10.10.11.1/24; } } } gr-0/0/0 { unit 0 { tunnel { source 172.20.1.1; destination 172.20.1.2; } family inet { address 192.168.1.1/24; } } } lo0 { unit 0 { family inet { address 172.20.1.1/32; } } } st0 { unit 0 { family inet; } } [edit] root@Juniper# show routing-options { static { route 10.10.10.0/24 next-hop gr-0/0/0.0; route 172.20.1.2/32 next-hop st0.0; } } [edit security] root@Juniper# show zones { security-zone trust { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { gr-0/0/0.0; lo0.0; st0.0; } } }
[edit] root@Juniper> show interfaces gr-0/0/0 terse gr-0/0/0 up up gr-0/0/0.0 up up inet 10.1.1.1/32 --> 0/0 gre up up
root@Juniper> show security ike security-associations root@Juniper> show security ipsec security-associations
Verify that the route that is towards the private remote subnet has the GR interface as the next-hop.
Verify that the route towards the GR remote end is through the st0 interface.
2020-09-25: Article reviewed for accuracy; no changes required.