Blog

BGP over IPSEC VPN

March 5, 2014 9:55 am

This post presents how to configure BGP as routing protocol over an IPSEC hub and spoke VPN.

The requirements:

The following diagram depicts the network architecture:

BGPIPSEC-1-2

What we have to do:

  • All TRUST networks should be known on every SRX.
  • The ST0 interface should be the next hop of BGP routes.
  • Only the Corporate office provides Internet access, for its local network and also for remote offices. Remote Offices has to use the VPN to reach the Internet gateway SRX-A.

Zone configuration:

For Remote Offices: the Private Network of each SRX is attached to the TRUST zone. The Secure Tunnel Interface will be attached to the VPN zone. The physical interface connected to the Internet is placed within the UNTRUST zone.

For Corporate Office: the Private Network is attached to the TRUST zone. The Secure Tunnel Interface will be attached to the VPN Zone. The physical interface connected to the Internet is placed within the UNTRUST zone.

ST0 interfaces can handle IKE protocol and BGP protocol. Only the Corporate zone has a default route pointing to the Internet provider interface’s. Here, we don’t use Virtual Router on SRX.

Security zone configuration for SRX- A (the same for the 3 others):

BGPIPSEC-2IPSEC configuration:

This is quite simple Hub-Spoke configuration. The Corporate Office is the Hub and its st0.0 interface is configured as a multipoint interface. We use standard proposals.

Configuration of the HUB (SRX-A) :

BGPIPSEC-3

BGPIPSEC-4Configuration of one SPOKE (SRX-X):

BGPIPSEC-5BGPIPSEC-6Now let’s check that every VPN are UP on SRX-A:

BGPIPSEC-7Security Policies configuration:

The requirements are:

  • Intra VPN flows are allowed for any applications.
  • Every Sites can reach each other for any applications through the VPN
  • Local Network of the Corporate office can reach the Internet directly via the UNTRUST Interface of the SRX A
  • Remote Networks attached to Remote Offices can reach Internet only via the VPN toward the SITE A.

Now we can implement the requirements in the Security Policies – For Site A:

BGPIPSEC-12And for the 3 remote sites:

BGPIPSEC-13 Routing protocol configuration:

The aim is to exchange BGP on every TRUST networks.

Moreover, Corporate site has to send its default route in BGP to provide a default route to remote offices in order to reach the Internet through the VPN.

The Next-hop of the BGP routes must be the ST0.0 interface of the attached SRX. Indeed, we want that routes exchanged in BGP are reachable via the VPN. Remember we have configured BGP as host-inbound allowed protocol for the VPN zone!

The BGP ASN used will be AS 65000. The router-id of each SRX will be equal to the ST0.0 address.

To connect Sites with BGP we have 2 possible ways:

  • Full mesh BGP (Each site has a session with all the other sites)
  • Route-Reflector design. Only one site plays the role of RR and reflects routes received from clients.

For Hub & Spoke architecture the RR design is better. Indeed, the Corporate Site already plays a central role. It can configure as the RR server. All the remote sites will peer only with the RR which will reflect routes to each RR client. This solution is more scalable than a full mesh configuration and it is easiest to add a new Remote site within the BGP cloud.

Nevertheless, keep in mind that low end SRX like SRX 240H and H2 don’t support BGP Route Reflection feature. So the only solution is to use a full mesh BGP configuration where each SRX has a session with all the others. The following configuration shows you a more scalable solution based on RR.

Let’s configure the SRX-A has the RR server (the cluster ID is chosen arbitrary):

BGPIPSEC-14Remember in RR configuration, a route received from a RR client is automatically reflected to the other RR clients. As you can see, I’ve defined also a specific BGP export policy in order to:

  • Redistribute the local TRUST network.
  • Redistribute the static 0/0 route to provide Internet Access to Remote sites. Notice: unlike direct attached routes where the Next Hop is by default “Self”, for static routes we keep the Next Hop defined as the BGP Next Hop. In our case, we want that the default route is reachable via the VPN. Therefore, we need to rewrite the NH: this is why we use: “next-hop self”

The my-export policy is written like this:

BGPIPSEC-15-1

Now, let’s do the SPOKE SRXs configuration. Each Remote site has only one BGP session (the SRX-A). Hereafter the BGP configuration of the SRX-X (same for Site Y and Z):

BGPIPSEC-16

Here again I have defined a specific export policy to announce local TRUST network. The export policy is defined like that. For example for SITE Z

BGPIPSEC-18Verification:

Now it’s time to verify if all our BGP sessions are established. On the RR server, SRX-A:

BGPIPSEC-19I added also a command to check which prefixes are received from a specific BGP neighbour. Here, I checked the prefix received from SRX-X. Moreover you can see that next-hop is the ST0.0 interface of SRX-X.

To finish we check on one Remote Site (SRX-Z) that all TRUST Networks are well known and reachable via the VPN. Moreover, Internet (the default route) is well installed in the routing table.

BGPIPSEC-20Conclusion:

BGP is a protocol that can be used to exchange routes between Sites on Hub & Spoke IPSEC VPN configuration. OSPF can be also used. The JNCIE-SEC iNET ZERO Workbook’s and rack rental also covers this other case.

David Roy

David Roy

My name is David Roy . I'm 35 years old. I live in France. I'm a content developer for iNET ZERO and also a Technical Support Engineer since 7 years. Before that I worked during 5 years at a research & development department (IP / DVB satellite team). I'm JNCIE-SP #703, JNCIE-ENT #305, and JNCIE-SEC#144 certified

More Posts

Tags: , , ,

Categorised in:

  • Hi there, I discovered your site by way of Google while searching for a related
    topic, your web site came up, it appears good.
    I have bookmarked it in my google bookmarks.
    Hi there, simply become alert to your blog thru Google, and found that it is truly informative.
    I am going to be careful for brussels. I’ll be grateful for those
    who continue this in future. A lot of folks might be benefited from your writing.

    Cheers!

  • My buddy recommended I could this way website. He had been fully correct. This specific set up essentially designed my day time. You can’t believe that just how much time I had put together spent just for this information and facts! Thanks a lot!

    • Chap building the same type of networks for the banking space, good to see someone else doing the same! Only my designs are via point to point ipsec suite b and bgp peers however, via next hop static nat CE routers so we need to add local and remote ike id’s . But like the multipoint seems to simplify the ike and bgp peering somewhat basically reuse the same template over many clients…

      Good blog.

  • Mohamed Elkhodary says:

    Hi David,

    This is a great Topic, I have a question for host-inbound-traffic
    should IKE be allowed on the “UNTRUST” Zone (That contains the VPN Outgoing Interface) and not the “VPN” Zone ?

  • Serdar says:

    How can be made with full mesh bgp?

Leave a Reply

Your email address will not be published. Required fields are marked *