How to Simulated 3 site MPLS with Remote Site-to-site Branch Office


No messing about today, we are going straight in with a more advanced lab! (and once which is more than likely familiar to you)

Now we all know how to create simple site to site VPN’s between two cisco devices (easy right? especially if you’ve read my previous blogs…), but what about say requiring access to multiple LANS, topped off with a sprinkle of IPSec tunnel terminating on a non-cisco device? Well that’s what I’m going to try and attempt here.

As you can see from the above network diagram, we are effectively  simulating an “MPLS CLOUD” at it’s simplest level as well as the “PUBLIC INTERNET”.

There are 3 MPLS sites, SITE A, SITE B and SITE C.

We then have a remote site, which will connect to MPLS Site C via the public internet using a VPN Tunnel.

The idea here is to allow the Remote site, access to all three MPLS LAN’s.

First I’m going to configure up the 3x 1841’s SITEA, SITEB and the MPLS Cloud.

If you are not familiar with the serial interfaces, then don’t worry too much. They are very similar to ethernet interfaces, you just need to specify a few addtional options (e.g clock speed of the interface). I’m not going to cover this now as it’s not relevant, so am going to carry on configuring the routers.

We now need to tell the “MPLSCLOUD” how to get to the various sites

And on with Site A configuration

Moving to Site B

Quick check to make sure Site B can ping the interface Site A connects to, as well as pinging Site A’s MPLS IP

Now lets move over to Site C (ignore the hostname Internet in the first line, that was me typing the wrong name…)

Now lets assign these VLAN’s to switchports (as you have to do on the ASA 5505)

Quickly check we can access the inside interface of Site A… Oh dear. Lets make sure we can get to the MPLS Cloud interface…

So we can hit the cloud router, but not site A.

Best have a look at the routes then make sure they are OK

So it knows how to get to those remote subnets, but what about the MPLS subnets. Right lets add them in then

We also need to add the following line:

This will now let traffic flow between interfaces with the same security level (so inside to MPLS and MPLS to inside)

Now this is done and all the route’s are in lets continue with the configuration, moving on to the “Internet Router”

Make sure you can ping the outside interface of site C

Everything is coming together nicely so far, so lets go ahead and configure up the branch office.

The branch office uses a draytek 2820, and first things first lets make sure we are running the latest firmware.

July 24th 2009. Hummmm there must be some later firmware…off to draytek.com and indeed there is, so now i’ll update

Thats better, May 23rd 2012.

On with configuring the interface which connects to the public internet

And now we need to configure the local lan of the remote site

Everything looks to be OK so far. We can see a connect to the public internet:

And I can also ping the “next hop” after the draytek

Back on to the internet router to make sure I can ping the draytek.

Oh dear, something isn’t right here. Don’t worry to much, much like cisco ASA’s blocking ICMP traffic by default so does our friend the draytek

Lets retry that

That’s much better.

Now time to configure the VPN tunnel on the Draytek, fairly straight forward (for those GUI lovers)

click advanced to enter the phase 1 / phase 2 settings

Now jump back over to site C and configure the VPN tunnel on there.

So thats the VPN tunnel done on this end, lets now try and send some traffic and hopefully the tunnel builds.

Oh dear, this is not good, lets have a look at the logs on the ASA (debug crypto isakmp 7 and debug crypto ipsec 7)

So what we can see here is Phase 1 has completed, but Phase 2 is a no go. It’s saying the ACL does not match Proxy ID’s.

Local proxy 0.0.0.0 / 255.255.255.0

Well it has a point, I’ve not any specified that on the ASA, so lets just check the draytek again

And there it is “remote Network IP”, we need to specify the remote LAN on here so it matches the ASA’s ACL

Now lets pass some traffic…

And looking at the logs, we can see Phase 2 completed (and as above traffic is passing)

Lets just check this on the draytek

We now have a tunnel built, and we can pass traffic from Site C to the remote site and site C to the remote site but what about accessing Site A and B?

Well naturally you would assume on the ASA all you need to do is make this simple change to the ACL:

  • access-list VPN extended permit ip 192.168.10.0 255.255.255.0 192.168.40.0 255.255.255.0 (original ACL)
  • access-list VPN extended permit ip 192.168.20.0 255.255.255.0 192.168.40.0 255.255.255.0 (additional line)
  • access-list VPN extended permit ip 192.168.30.0 255.255.255.0 192.168.40.0 255.255.255.0 (additional line)

Then we move over to the draytek and click the “more” button

And here we specify the remote subnets

Drop the tunnel then wait for it to rebuild, and try to ping across to site A or B….The result? You won’t be able to.

Lets just take a look at the ASA (show crypto ipsec sa)

access-list VPN extended permit ip 192.168.30.0 255.255.255.0 192.168.40.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.30.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.40.0/255.255.255.0/0/0)

for some reason the ASA is only showing the first line of the ACL. Not good, this leaves sites A  and B cut off from the remote site.

So what can we do? well luckily for us the remote sites can all be summarised, so 192.168.10.0/24, 192.168.10.20/24 and 192.168.30.0/24 can be summarised as 192.168.0.0 /21 (255.255.224.0)

If we make this change on the ASA as well:

  • access-list VPN extended permit ip 192.168.10.0 255.255.255.0 192.168.40.0 255.255.255.0 (original ACL)
  • access-list VPN extended permit ip 192.168.0.0 255.255.224.0 192.168.40.0 255.255.255.0 (NEW ACL)

Re-build the VPN tunnel by dropping the tunnel and passing traffic, we can now see the following:

Notice next to IPsec it shows 192.168.0.0/255.255.224.0 as oppose to 192.168.30.0/24

This is good news surely? Lets try from the 192.168.30.0/24 (Site C) subnet and see what we can reach

We can hit our default gateway, the laptop on 192.168.10.10 (Site A) and also the laptop on 192.168.40.10 (Site C) (no Site B as I ran out of power to have the 5th router on!)

Lets move over to site A and the 192.168.10.0/24 network and make sure we can get to everything

Again, we can hit the default gateway and the laptops in SITE C and the Remote site.

There we have it then ladies and gentlemen, complete connectivity between 3 MPLS sites and a remote branch office…..

Or do we, well I wasn’t happy having to specify such a wide subnet (just to be able to access SITE A/B/C) (192.168.0.0/21), so I spent a fair amount of time looking into this and trouble shooting.

What I discovered was:

ASA to ASA (multiple remote/local LANS) = OK

Draytek to Draytek (multiple remote/local LANS) = OK

Draytek to ASA (with multiple remote/local LANS) = Fail

After a bit of further head scratching, pulling out of hair, and shouting at the kit I found out that ONLY one pair of IPsec Security Associations (SA’s) can be maintained at anyone time……

If you’ve not already fallen asleep let me explain..

Remote Site (192.168.40.0/24)
|
Internet (IPSEC TUNNEL) ——–PHASE 1 SA OK
|
SITE C (192.168.30.0/24) WITH SITE A & B subnets connected (192.168.10.0/24 & 192.168.20.0/24)

As you can see SITE C has 3 IP subnets behind it. With IPSEC tunnels there needs to be a PAIR (one outgoing, one incoming) of SA’s for each IP Subnet pair.

Eg:
PHASE2 SA’S for example would be as follows:

192.168.40.0/24 —OUTGOING—->192.168.10.0/24
192.168.40.0/24 <—INCOMING—-192.168.10.0/24

192.168.40.0/24 —OUTGOING—->192.168.20.0/24
192.168.4.0/24 <—INCOMING—-192.168.20.0/24

192.168.4.0/24 —OUTGOING—->192.168.30.0/24
192.168.4.0/24 <—INCOMING—-192.168.30.0/24

Communication can only exist between the different IP subnets if these SA “PAIRS” exist for the corresponding subnet pairs.

The Draytek has the limitation of only being able to maintain ONE SA PAIR at a time which has the unwanted affect of NOT being able to communicate to ALL subnets at the SAME time…

Luckily for the purpose’s of this lab I was able to summarise the three subnets in to a larger subnet to get around this issue. But if I had used 192.168.10.0/24 at one site and 172.16.40.0/24 at another site then I’d have been up the creek without a paddle.

As mentioned above this problem only occurs when doing IPSEC VPN between Draytek and CISCO in my test Draytek to Draytek has no problems.

So hopefully this saves you many hours of shouting, head scratching and hair loss! as i’ll be honest until I did this lab I was not aware of that either.

Finally below is the lovely setup I’ve had to live with looking at for the past few days….

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: