Building network automation solutions

9 module online course

Start now!

PE-to-PE IPSec: do you have creative ideas?

Ying would like to have a PE-to-PE IPSec protection for traffic within a single VRF. For example, all traffic in VRF-A sent between PE-1 and PE-2 should be protected with IPSec and the PE-routers should be the endpoints of the IPSec session (CE-to-CE IPSec is trivial).

My first response was “hard to do”, then I started hallucinating about MPLS-over-GRE-over-IPSec-over-IP-over-MPLS tunnels between the PE-routers with tunnel-specific IGP and per-VRF BGP next hops. It can be done (we’ve implemented numerous large-scale MPLS/GRE/IPSec designs), but is there a simpler alternative? Please share your ideas in the comments.

We migrated our blog a few days ago, and the commenting functionality is not there yet. In the meantime enjoy the older comments, or find our content on LinkedIn and comment there.

20 comments:

  1. Hi!

    I Think you should take a look on Cisco GET ( Group Encrypted Transport VPN )
    :)
    http://www.cisco.com/en/US/products/ps7180/index.html

  2. GETVPN is a CE-to-CE solution. We're looking for a PE-to-PE solution for a single VRF.

  3. What about VRF aware IPsec feature? So create VRF B on both PEs as transit VRF and then run a VRF aware IP sec through it. Or some variation along those lines. :)

  4. If you don't trust the MPLS VPN of your provider, why would you trust his PE routers?

  5. I don't know the full background, but it could be site-deployed PE routers ... or someone trying to offload the burden of regulatory-enforced encryption to the SP.

  6. You can indeed use IPSEC in a VRF mode.
    2 options:
    you can use the IGP core as tunnel endpoints, you will use global (not VRF!) loopbacks as the source and destination of the tunnel and just use the "ip vrf forwarding" under the tunnel (this is a very nice security feature that will make every successfully(!) decrypted packet enter the VRF specified in the "ip vrf forwad" command).
    If you want the tunnel to initiate from within the VRF itself, you can ADD the " tunnel vrf" command to the tunnel - then, the source and destination will have to belong to the VRF context.

    Hope this helps!

  7. Thanks for the idea. Much better than mine ... but it destroys all the scalability of MPLS VPN, as you have to build per-VRF tunnels between the PE-routers (not to mention the routing mess you could make).

  8. Hmmm, what about running MPLS/VPN over DMVPN between the PE ?

  9. You're making my hallucinations scalable 8-) If nothing better comes along, we can always use this.

  10. I agree MPLSoDMVPN is your friend if you're looking for pure scalability, but MIGRATING from MPLS core to IP core and running mpls on tunnels is quite a change...certainty not feasible for SP (if that's the case)

  11. What about binding a crypto-map on the customer-facing interface(s) of the PE, so incoming traffic should be encrypted, forwarded into the VRF and routed thru the VPN.
    Don't know if this is possible but it may work...?

  12. Because the crypto map works in the output direction.

  13. So I tried, it seems to work (if I didn't make any mistake) with a basic config (ie DMVPN without crypto):

    http://www.ipflow.utc.fr/configs/DMVPN_PE/

    (Sorry I don't have any drawing at this time)

    The "mpls bgp forwarding" command on the tunnel interface did the trick.

  14. Well Explained about the requirement of PE-PE Ip Sec Security

    http://etutorials.org/Networking/MPLS+VPN+security/Part+III+Practical+Guidelines+to+MPLS+VPN+Security/Chapter+6.+How+IPsec+Complements+MPLS/Location+of+the+IPsec+Termination+Points/

  15. Great job. Thanks! Can I use the configs in my other articles?

    BTW, using "mpls ip" on the tunnel interface should also work.

  16. Thanks. Great document (I wonder where it came from, it's too well written for a "free tutorials" web site).

  17. Yes, of course, no problem.

    About using LDP, I read in http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/ngwanempls.html that direct spoke-to-spoke communication is not possible except via the hub acting as a P router (I guess the PE cannot form a LDP adjacency ?)

  18. Hi think I missed your point, I guess the idea was to have "mpls ip" on the interface only to allow MPLS packets, not to establish LDP adjacencies.

  19. google gives the answer ...

    http://my.safaribooksonline.com/1587051834/part01
    MPLS VPN Security, by Michael H. Behringer; Monique J. Morrow

    Back to the topic, for me it's crazy idea
    to have the SP encrypt the traffic of it's customers.
    Possible ? Maybe, but who would like
    to have such a network ?

  20. Its not about the SP encrypting traffic for its users as a "service" , but more about maintaining security when using a carrier of carriers model . That means the SP is using the internet as the core between PEs. Happens frequently with VNOs.

Sidebar