Secure BPN design

It’s not uncommon to have business partners that share network resources.  This is typically accommodated through the use of a site-to-site (or LAN-to-LAN (L2L) depending on your “phraseology” preference) VPN tunnel.  Sometimes dedicated, leased-line circuits (frame-relay, point-to-point circuits such as T1s, T3s or any fraction thereof) are used as well, although the additional cost of these kind of circuits are usually prohibitive, compared to the inexpensive VPN option.

Before continuing with this discussion, I need to give credit where credit is due.  One of the models presented (the legacy model as I refer to it), I have used and am quite familiar with.  The other model (I term it the “best-practices model”) I was not.  I learned about this model from my mentor, friend and colleague (my boss!) Scott Hogg.  Scott and I were discussing BPN design best-practices when he told me about the second model presented in this discussion.  As always, I enjoy the conversations that Scott and I have — this article wouldn’t have been written without his feedback and input.

There are two main schools of thought when it comes to a BPN.  I’ll call one school of thought the “legacy model”, with the other school (the model currently in use) being the “best practice model”.  This article discusses both models and shows a configuration example (Dynagen .net file included) of the best practice model.

Example Description

Both model examples utilize three customer sites (CE1, CE2 and CE3) and a head-end site (headquarters, main site).  To allow simulation of hosts within each customer network, there are the CE1LAN, CE2LAN and CE3LAN routers.

The HOST1, HOST2 and HOST3 routers simulate hosts/servers within the head-end site.  The HEAD router terminates the L2L IPSec tunnels at the head-end site, where each CEx router terminates the tunnel at the customer site.

The firewall at the main (head-end) site (HEADFWL) could (and probably should be) a dedicated firewall appliance such as an ASA or FWSM.  Although PIX firewalls can be easily emulated, it was easier for this example to use a router with the IOS Firewall (Advanced Security) feature set.  CE1 is allowed to access (ping) HOST1, but nothing else.  CE2 and CE3 are given virtually unrestricted access to the head-end site.

To mix things up a little, there are two customer sites that utilize L2L IPSec tunnels (CE1 and CE2), and a single customer site that utilizes a leased-line (CE3) to connect to the main site.  Now, without further ado, let’s examine the two models.

Legacy Model

This model uses a single LAN for terminating all Business Partners (BPs).  They could arrive via a L2L IPSec tunnel or via a leased-line circuit.  The main issue I’d like to examine here is that all BPs terminate on the same shared LAN.

Best practices in L2L design dictate the use of very specific ACLs to match what traffic is “interesting” to the tunnel (so only what’s needed is sent across the tunnel).  In following this, the possibility of one BP using the BPN as a transit network to attack (or access) another BP is next to nil (assuming of course that proper L3 spoofing precautions are taken).  It is possible to use a host within the BPN as a transit device, bridging the two BPs, but this is a different topic (host security) and can be an issue no matter which model is chosen.

Typically a firewall will guard the untrusted (BPN) network from the rest of the trusted (internal) network, providing stateful packet inspection.  Best practices dictate the use of a device offering deep-packet inspection (IPS, AntiVirus, content inspection, etc.) between the two networks as well.

The following diagram shows the legacy model design:

The focal point now is that all BPs technically are not isolated.  All the BPs terminate on the same shared LAN with no isolation between each BP.  While ACLs are used to determine the “interesting” traffic for each L2L IPSec tunnel, they are not separated (share a common LAN/VLAN).

This model was used (and still can be found in the wild) quite successfully for many years.  What could be better?  Hold on and let’s examine the…

Best Practice Model

The best practice model utilizes L2L IPSec tunnels as well.  The main difference here is that once a BP connects, each BP is completely isolated and firewalled off from the rest of the network (and BPs).  Take a look at the following diagram of the best-practice BPN model.

Three customer sites, two using L2L IPSec tunnels, the third connecting via a leased-line circuit.  This looks almost identical to the legacy model above.  What gives?!

The keywords that should be caught are almost identical.  There’s a very big difference in this design in that separation between BPs is maintained until a security device (the firewall – HEADFWL router) can inspect and manage the BP traffic.

Take a close look at the Public (untrusted) Network Segment.  Notice that this design utilizes VRFs on the the router where the VPN tunnels terminate at the head-end site.  The VRF configuration provides complete isolation between the different BP L2L tunnels on the router.  Each BP is assigned a unique VLAN ID used within the network segment, providing complete L2 separation.

Although the firewall (HEADFWL) doesn’t have any VRFs configured, it uses sub-interfaces, allowing it to keep the different BPs separated.  Within a real environment, it’d be best to use a dedicated firewall appliance (ASA, FWSM, etc.) for this role.  This design would make great use of the multiple-context abilities of the ASA and FWSM (make the BPN a separate context to provide further separation and isolation from the rest of the network).  As a side note, if an ASA or FWSM is used for the firewall role, it might be ideal to make each BP-facing interface (the VLAN sub-interfaces) the same security level and ensure that the same-security-traffic permit inter-interface command isn’t configured so that BPs can’t transit firewall to reach other BPs.

Each router is using a Static Virtual Tunnel Interface (SVTI) for the L2L IPSec tunnel.  An SVTI provides many benefits over a crypto map.  Unlike a crypto map, no ACL is applied that defines the “interesting traffic” for the tunnel.  Rather with an SVTI, any traffic that is sent over the SVTI is considered “interesting”.  It’s a matter of the routing table (ie. the IGP in most environments) to determine what traffic should be sent over the SVTI/tunnel.  In this example I didn’t configure an IGP at the customer sites.  This was partly due to time constraints, but also because I really couldn’t see the value in showing this.  It really doesn’t matter how traffic is routed to the SVTI as long as it gets to it.  Static routes can be used (as in this example), although in most real-world environments, I’d strongly recommend using a dynamic routing protocol (typically OSPF or EIGRP).

Another feature about SVTIs is that they’re simply another router interface — most of the features and protocols that are configured on any other interface can be configured on an SVTI.  This includes multicast (try doing multicast over a tunnel using a crypto map!), IGPs, etc.

To summarize: the VRFs provide separation within the VPN termination point (HEAD) and the leased-line termination point (HEAD-S).  A unique VLAN ID is used for each different BP to provide separation between the entry point (HEAD and HEAD-S) and the firewall protecting the internal/trusted network (HEADFWL).  SVTIs are used for the IPSec L2L tunnel, allowing for multicast support as well as easy IGP integration.

Dynagen .net File

Here’s the Dynagen file that I used for the best-practice model mock-up.  Note that this uses two hypervisor instances (see the Running two simultaneous instances of the Dynamips hypervisor post for more information).

Router Configurations

Note that the following router configurations show just what I thought was necessary.  These are not complete configurations, as a lot of extraneous lines were removed for the sake of brevity.  Note also that the head-end (main) site is the only one that uses an IGP, the rest use static routes.  This isn’t ideal, but the idea of this lab is to show the BPN design as a whole, not focus on all other aspects of proper network architecture.

HEAD

HEAD_S

HEADFWL

HOST1

HOST2

HOST3

CE1

CE1LAN

CE2

CE2LAN

CE3

CE3LAN

Testing

Here’s where the rubber meets the road!  Since I’ve provided the configurations above, I’ll simply show some different aspects of the design, but leave all of the details up to you to try out.

First off, HEAD has VRFs configured — one VRF per BP:

Likewise, there’s one VLAN ID assigned per VRF:

If CE1LAN tries to ping HOST1 (4.0.10.10), the following is observed:

Watch what happens when we try to ping HOST2 (4.0.20.10):

Some of this is from the fact that the routing isn’t pointing to the SVTI:

Notice that CE1 doesn’t have a route to the 4.0.20.0/24 prefix:

If we put one in:

Let’s try it again from CE1LAN:

Same as before — this time, not for lack of a route.  Look at the HEADFWL console:

It’s seen that the ACL isn’t permitting this (it traversed the VPN tunnel, but was blocked by the firewall).  Look at the firewall ACL for customer 1:

We see the matches.  The fact that there are only 4 matches can probably be attributed to the fact that the VPN tunnel had not yet been established when I attempted to ping HOST1 from CE1LAN.

Let’s try one more test and try pinging some different hosts from CE2LAN (no ACL is limiting this customer’s access to the head-end network).  Note that I put in a static route to 4.0.10.0/24 on CE2 for all of the following tests to work.

Conclusion

Hopefully this article has been of some help.  In today’s world, it’s critical to have a secure and solid infrastructure.  Through the use of IPSec L2L tunnels, most security requirements can be easily met.  By using SVTIs, dynamic routing protocols can be used, allowing for load-balancing of traffic across different tunnels (possibly going through different provider circuits, such as utilizing multiple carriers for redundancy) and fast failover of circuit failovers (assuming multiple circuits exist and different SVTIs are created through each individual circuit).

Until next time…