4

I'm trying to understand use cases for GRE over IPSEC. In the diagram below, each site uses GRE to encapsulate multicasts associated with OSPF. (There is still a requirement to configure SAs between each site.) In this case, tunneling over ospf within GRE would save the complexity of configuring static routes between sites.

Is this a valid use case? Are there others that are commonly deployed (e.g. applications that required multicast)?

enter image description here

Improve this question
0

1 Answer 1

Reset to default
5

Running multicast or multicast based routing protocols does not necessarily require GRE-over-IPsec. "Tunnel based" or "route based" VPN (tunnel mode ipsec ipv4 a.k.a. IPsec Virtual Tunnel Interfaces in cisco lingo) will transport multicast and EIGRP or OSPF happily.

However, GRE is needed when you need to run non-IP protocols across IPSec:

At my former employer's, we used to run MPLS-over-GRE-over-IPSec extensively, mostly with EIGRP on GRE as the GRT routing protocol, and with certificate based IKEv1 and IKEv2 beneath it.

This enabled us to have a multi-VRF CPE as small/cheap as a Cisco 890 series at the customer site, while allowing for path isolation or "zoning": one VRF or "zone" for the ATM, one for video surveillance, one for internal data, one for guest WiFi, one for facility management, etc.

At the same time, these IPSec tunnels were used over almost any flavour of underlying transport (dark fibre, lit fibre, point-to-point L2VPN, multipoint L2VPN, L3-VPN, cable or xDSL internet, etc.

Of course, we would have preferred to run MPLS atop IPSec directly (tunnel mode ipsec ipv4, see above), but IPsec has no support for MPLS-over-IPSec (I believe there is - or was - an RFC draft for that, but it never made it).

Addon 2018-12-13:

Yes, MTU across the WAN is cut short to 1400 or less (minus 8 if the local loop at the customer's end is based on PPPoE!) with MPLS-o-GRE-o-IPSEC. PMTUd is further made difficult because the tunnel interface is not actually an IP interface anymore, but an MPLS interface. Therefore ip tcp adjust-mss is without effect on the tunnel interface, and TCP MSS clamping has to be done on the CE facing interface.

Fragmentation of IKEv1 messages was also a difficult topic when RSA keys grew larger, eventually properly solved with IKEv2 and it's support for explicitely defining payload size (crypto ikev2 fragmentation mtu <size>)

Improve this answer
2
  • Thanks for the response. The MPLS-over-GRE-over-IPsec use case sounds like a good one. But assuming encryption is occurring in the Customer network, why encrypt MPLS? What labels are entering the customer environment (unless some sort of Carrier Supporting Carrier thing)? To me, this sounds like a Provider problem, no?
    – The_Glidd
    Dec 13, 2018 at 15:51
  • In that use case, the CPE at the customer's was ours. All the customer could see on their CE switches (very rarely a VRF-lite resp. multi-VRF CE) were VLAN tags as agreed-upon with them. The carrier providing the underlay could only see IPSec, and the occasional http/SCEP request from the CPE to the CA. IPSec was mandated by the customer to protect their data, but it had the beneficial side effect to hide the MPLS labels als well.
    – Marc 'netztier' Luethi
    Dec 13, 2018 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.