Cisco (Networking)

You are currently browsing the archive for the Cisco (Networking) category.

Full tunnel AnyConnect with Internet hairpin

May 17, 2013 in Cisco (Networking) | No comments

As a matter of personal preference, I was never a HUGE fan of the ASA as a firewall appliance.  For VPN termination, it’s pretty slick but still has some issues.  Either way, I have a 5505 at home that I use for firewall and VPN.  Being bored some time ago (wish I had free time now) I decided to upgrade the device from 8.2 to 9.1 code.  Along with this change came the dreaded ASA 8.3 NAT configuration change.  I’d argue that NAT on the ASA never made true sense, but once you knew how it worked, you could make it do what you wanted it to do.  Not knowing how to configure the new mode of NAT in the CLI, I decided to try it through ASDM (this of course breaking my ‘ASDM is awful never use it’ rule (and yes, I know you have to use ASDM for some of the AnyConnect XML stuff)).  The ASDM configuration lead to the automagic creation of NAT groups I didn’t need, object groups I didn’t need, and ACLs I didn’t need.  Somehow I managed to click enough buttons that it worked, but I wasn’t happy with the end state of the config. 

Fast forward to now.  Now I want to be able to connect to VPN at my house, access local resources, as well as access the internet through my local Comcast connection (internet hairpin).  Thinking this would be straight forward, I pulled down a copy of my ASA config into notepad and realized that it was full of random stuff I didn’t need.  After some clean up, I came to some realizations about NAT on the newer ASA code.  Namely, the fact that you don’t HAVE to use the NAT configuration under the objects themselves.  This, at least for me, was a HUGE help.  Let’s take a quick look at my config so you can see what I’ve setup…

image

So the real goal here is to be able to access a hosting container I use out on the internets from my laptop.  The hosting container only allows certain IP addresses (my home IP) to access it.  So if I could VPN to my house and use my home internet connection to access the hosting space from my laptop, I’d be all set!

In order to accomplish this, you need to do some ‘weird’ NAT configuration. I’m not going to run through my whole ASA config, but here are the important pieces…

hostname ASA
!
ip local pool vpn 10.20.30.249-10.20.30.253 mask 255.255.255.0
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
switchport access vlan 3
!
interface Ethernet0/6
!
interface Ethernet0/7
switchport access vlan 3
!
interface Vlan1
nameif inside
security-level 100
ip address 10.20.30.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address <removed> 255.255.255.248
!
interface Vlan3
no forward interface Vlan1
nameif guest
security-level 50
ip address 192.168.127.1 255.255.255.248
!
boot system disk0:/asa911-k8.bin
!
same-security-traffic permit intra-interface
object network guest
subnet 192.168.127.0 255.255.255.248
object network locallan
subnet 10.20.30.0 255.255.255.0
object-group network VPNPOOL
network-object 10.20.30.248 255.255.255.248
!
nat (outside,inside) source static VPNPOOL VPNPOOL
nat (outside,outside) source dynamic VPNPOOL interface
nat (inside,outside) source dynamic locallan interface
nat (guest,outside) source dynamic guest interface
!
route outside 0.0.0.0 0.0.0.0 <removed> 1
route inside 10.0.0.0 255.255.255.0 10.20.30.117 1
!
telnet 10.20.30.0 255.255.255.0 inside
telnet timeout 1440
ssh timeout 5
console timeout 0
management-access inside
!
dhcpd address 10.20.30.100-10.20.30.200 inside
dhcpd dns 4.2.2.2 8.8.8.8 interface inside
dhcpd enable inside
!
dhcpd address 192.168.127.2-192.168.127.6 guest
dhcpd dns 4.2.2.2 8.8.8.8 interface guest
dhcpd enable guest
!
webvpn
enable outside
anyconnect image disk0:/anyconnect-macosx-i386-2.5.2017-k9.pkg 1
anyconnect image disk0:/anyconnect-win-2.5.3055-k9.pkg 2
anyconnect profiles vpn disk0:/vpn.xml
anyconnect enable
group-policy DfltGrpPolicy attributes
vpn-idle-timeout none
vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless
group-policy gp_anyconnect internal
group-policy gp_anyconnect attributes
dns-server value 4.2.2.2 8.8.8.8
vpn-tunnel-protocol ikev2 ssl-client
split-tunnel-policy tunnelall
split-tunnel-network-list value splitvpn
webvpn
  anyconnect profiles value vpn type user
  anyconnect ask none default anyconnect
username <removed> password <removed>
tunnel-group tg_vpn type remote-access
tunnel-group tg_vpn general-attributes
address-pool vpn
default-group-policy gp_anyconnect
tunnel-group tg_vpn webvpn-attributes
group-url <removed> enable
without-csd

Lot’s of config there, but I want to focus on are the bolded lines.  The first bolded line is what tells the ASA to allow the ‘hairpin’ to occur.  Specifically, you are telling the ASA with this command that it’s ok for traffic to come in a interface with a certain security level (0) and leave through an interface with an identical security level (0).  This allows VPN traffic to come in the outside interface encrypted, and leave back out the outside interface to get to the internet. 

The next 4 bolded lines are the NAT configuration.  This is what I’m really interested in…

nat (outside,inside) source static VPNPOOL VPNPOOL
nat (outside,outside) source dynamic VPNPOOL interface
nat (inside,outside) source dynamic locallan interface
nat (guest,outside) source dynamic guest interface

Let’s line these statements up on our diagram to give you a visual of what’s actually going on…

image

The first NAT statement tells the ASA to allow the client space in from the outside interface to the inside interface and to not modify the addresses.  This allows my VPN pool (tail end of my 10.20.30.40/24) to talk to the Local LAN space. 

image

The second NAT statement tells the ASA to take the VPN client space in the outside interface, back out the outside interface, but to dynamically overload it to the outside interface IP.  This is the actual NAT hairpin configuration that allows a VPN client to come in the outside and then leave back out towards the internet with the NAT overload.  

image

image

The last two NATs are simple dynamic overloads for the Local LAN and the Guest LAN network.  This allows both RFC 1918 spaces to be hidden behind the outside interface of the ASA.

Not really a ton too it actually, but I did struggle initially with the NAT until I figured out I could do it without defining the NAT under the object group itself.

Tags: , ,

CCIE Written – Observations

March 25, 2013 in Cisco (Networking) | 4 comments

So I obviously won’t talk about the questions that were on the exam, but I will talk a little bit about the exam as a whole.  First, I’d like to talk about how I prepared.

It’s becoming rather apparent that I ‘over-prepared’ for the exam.  I started studying casually for the CCIE after wrapping up my CCIP cert back in December of 2011.  Casually to me means slowly reading through Odom’s CCIE cert guide.  Now the problem is that casual studying really doesn’t work for me.  I tend to lose focus unless I have an outline and some end goal.  So back on February 18th I booked the exam.  Having the date on the calendar really lit a fire underneath me to get things done.  So here’s how I tackled the exam prep.

Exam Prep
-I printed a copy of the blue print for tracking my progress.  If I was comfortable enough with a topic or section I highlighted it right away so I wouldn’t waste any time messing around with it.  Then as I completed sections I highlighted them to track my overall progress. 

-I read Odom’s book cover to cover over the period of a month.  As I read I’d start filling out a page in a notebook with topics that I wasn’t comfortable with or wanted to see work in the lab.  My rule was that once I got a full page, I’d stop reading and go to the lab to work through the items I had noted down.  Once I finished the reviewing the page, I went back to the book and repeated the process.

-The Odom book is a great ‘topic refresher’ ,but in my opinion, doesn’t have enough details to take a reader from novice to expert.  There were lots of blueprint topics that only had a brief mention, a page or less of content, in the book that really wasn’t sufficient.  When needed, I supplemented the Odom book with others.  These were the books I ended up reading cover to cover…

CCIE Routing and Switching Certification Guide (4th Edition)
Routing TCP/IP, Volume 1 (2nd Edition)
Interdomain Multicast Routing

The multicast book was sort of a ‘I’m really interested’ purchase and not necessarily required, but I think it’s a book worth having (Big thanks to Kurt Bales for the recommendation many months ago!).  The first two books are definitely required reading though.  I also used the internets to supplement some comment.  If you google something like ‘CCIE spanning-tree’ you can usually find all kinds of blogs created by other CCIE candidates that have great answers and explanations.  I’m a big believer in the fact that people need to hear concepts in different ways to understand them their own way. 

-I labbed everything I could.  Not only did  I lab it, I spanned and analyzed the actual packets hitting the wire.  This was, without a doubt, the best way that I learned about how the protocols worked.  Often times I’d read something and think to myself that I completely understood the topic.  Then I’d configure it, and when I saw the actual packets I would be completely amazed at how much I had misunderstood (or just missed pieces) the protocol just by reading about it. 

Practice Tests
I don’t generally like doing practice tests until the very end of my studies.  I find them sort of distracting and it’s really easy to get off path by using them.  In the last week of study I installed and used the Boson exam that came with the Odom book.  To be frank, I found it useless.  There were at least two questions that were completely wrong and many that were worded in a such a way that they were almost impossible to answer.  To top it off, the explanations were awful.  In my opinion, don’t waste your time.  Rather, someone from work recommended to me the Boson exam questions that you can actually purchase from Boson…

http://www.boson.com/practice-exam/350-001-cisco-v4-ccie-practice-exam

These questions were MUCH better.  The questions were well thought out, the explanations were amazing, and I felt like it gave a much better idea of the actual type of question you might see on the exam. 

The key to successfully using practice exams (in my opinion) is to not only understand the correct answer, but to also understand why the other answers were wrong.  I found that by doing this, the questions were very helpful.  Also, when I added them to my cart there was a button that said something like ‘special offers’ next to the checkout button.  When I clicked on that, I found a $20 coupon off so I got them for $80.  I think I got the discount for registering the Odom book first but I’m not sure. 

The Exam
The exam itself is like any other Cisco exam.  You NEED to take your time, go slow, read EVERY possible answer (even if you think A is the right one for sure), and double check the final answer.  Beyond that, there is a strategy I use generally on multiple choice tests that I can share with you. 

In college, there was a professor I had who made the worst multiple choice exams.  You know, the ones that had had 7 possible answers and E and F were combinations of A, B, C, and D (ex: F  – Answers A and C).  After doing poorly on an exam I went to his office and complained that the answers were too vague and it was hard to discern which one(s) were the right answer.  He explained to me that there was a simple way to pass his exams.  All I had to do was work backwards.  Rather than finding the right answer, all I had to do was get rid of the ones that I knew were wrong leaving only one answer.  If for instance I could prove that A was wrong, I knew that F (Answers A and C) was also wrong. 

On Cisco exams, I use this approach often.  Not only because they can sometimes use tricky wording, but it also helps me ensure that I actually read all of the questions so I don’t miss something. 

That’s all I’ve got.  I can’t say for sure my study method would work on it’s own, but it worked for me.  I’m looking forward to a couple weeks off and then starting in on the lab prep.  If anyone’s got any advice on that front, I’d LOVE to hear it!

Tags:

Unicast Reverse Path forwarding (uRPF)

March 23, 2013 in Cisco (Networking) | No comments

We talked a little bit about reverse path forwarding when we were dealing with multicast.  The RPF check was used when forwarding some of the traffic to prevent loops.  unicast reverse path forwarding (uRPF) works in a similar manner and it’s actually quite easy to configure.  Let’s take a look at a quick example to see how it works…

image

Imagine a topology like this one.  Here we have 4 routers that are using static routes to get to non-directly connected networks.  In this case, I made the routing asynchronous by having router1 go through router2 to get to the 10.0.0.8 and 10.0.0.12 networking.  Similarly, I made router4 go through router 3 to get to the 10.0.0.4 and the 10.0.0.0 networks. 

Let’s do a very basic check to show the basics.  Here we will configure the uRPF check on router1’s vlan 20 interface (10.0.0.5)…

image

This is pretty straight forward.  It says to check packets coming this interface with a RPF check.  If it fails, drop the packets.  We can see the results of applying the check by trying to ping one of router1’s interfaces from router4…

image

So that’s really the main point of the configuration.  The router checks to see if it would use the packets arriving interface as the return interface.  If the check fails, the packet get’s dropped.  We can see the drops if we look at the fa0/0.20 interface on router1…

image

So that’s the ‘basic’ way to configure uRPF.  Now let’s take a look at some examples of how to configure some of the other options.

uRPF processing works in an order like this…

-Do the RPF check, if it passes forward the packet
-If the check fails, check for associated ACL
-If ACL exists, check to see if packets match ACL
-If ACL match exists, forward packets regardless of uRPF

Note that we specify an ACL here.  If you were looking at a router and hit the ‘?’ when configuring the uRPF check the firs time, you would have seen this…

image

Let’s configure 2 ACLs and see if we can get them to work…

image

Let’s apply them one at a time to our uRPF check and see what we get…

image

A quick test from router4 shows that we can ping both of router1’s interfaces…

image

Looking at the fa0/0.20 interface on router1, we can see that the matches on the interfaces are now showing up as ‘suppressed verification drops’.  We can also see that it’s configured to allow access to communication that matches the ‘reachable-via RX’ condition, or that match ACL1…

image

Let’s clear the counters and configure the extended ACL to see what happens…

 image

Pings from router4 now act differently…

image

The pings to 10.0.0.5 aren’t working while the pings to 10.0.0.1 are.  Looking at our extended ACL, I’d say that would make sense.  The ACL allows the traffic from 10.0.0.14 (ICMP source on router4) to connect to 10.0.0.1, NOT 10.0.0.5.  A look at the interface counters confirms what we experienced…

image

So now that we’ve talked about the ‘reverse-path’ configuration, we need to talk about the ‘ip verify source’ configuration.  If you noticed, when you type in ‘ip verify unicast?’ on the interface sub configuration you get two options.  Source of reverse-path.  We just covered the reverse-path option, so let’s talk about the source option.

The truth of the matter is that they sort of do the same thing.  The reverse-path command syntax appears to be getting deprecated so we should really be using the ‘source’ option (plus it has more functionality).  Using the source syntax, we really have two main configuration options…

image

The first option is the ‘source reachable-via any’ syntax.  This is often referred to as the ‘loose’ mode of operation.  The ‘any’ configuration tells the router to pass the uRPF check if the prefix can be reached through ANY interface on the router.  Basically, if the prefix exists in the routing table, let it through. 

The second option is the ‘source reachable-via rx’ syntax.  This is often referred to as the ‘strict’ mode of operation.  This is exactly what we saw in the earlier examples.  This check to make sure that the router can access the prefix through the SAME interface that it received the traffic on. 

The ACL options work in the same manner in which they did in the above examples.  If initial uRPF check fails, check the ACL for an exception and then permit.  Let’s run through some examples of this quickly just to see the syntax…

image

This gives us the exact same behavior we saw with this last example…

image

Now let’s change it up a little and configure loose mode…

image

Here we see the pings working as expected…

image

It’s interesting to note here that router1 still treats loose mode as a ‘suppressed verification’…

image

Now let’s change things up a bit…

image

If we replace router1’s specific routes with a default route, let’s see what happens to our loose mode of operation…

image

Doesn’t work any more.  If you were to look at the IP interface on router1, you would see the uRPF is failing the checks and dropping the traffic.  But why is that?  Well, a 0’s route sort of makes a uRPF check invalid.  Thinking about it, that makes good sense.  If you only have 50 specific routes and then a 0’s route for the internet, there really isn’t a lot to check right?  Most routes will be internet facing and just work as expected.  To make this work, we need to change the uRPF configuration…

image

This configuration allows the uRPF check to consider the default route during it’s checks.  On the other hand, we could revert the configuration and just add a route like this…

image

Even though the 10’s route is effectively a summary, it still works…

image

The default route is the only one you need to watch out for. 

So there you have it, a quick look at uRPF check.  Hope this was helpful!

Tags:

« Older entries