I hope you’re as excited as me about the amazing world of VPN’s!? If not, i hope i change your opinion about them.

I’d already gone through the VPN vol 1 a couple of weeks back, and today was revision time. I’m not particularly proud of my memory, so i was kinda apprehensive about how much of my mistakes i would remember. But i surprised myself and i actually remembered some stuff which i missed out the last time i did this. And i assure you your memory can’t be as bad as mine. ex : I can only remember 3 dates :

1) My Birthday

2) GF’s birthday

3) My anniversary

 Why i am talking about this is that, like me if you have a bad memory, the best thing to do is write stuff down , revise and trust your memory to serve you when you need it. Being apprehensive will only lead to panic, which inturn leads to faulty configuration/no-creative thinking.

Now that i’ve got my little “zen” tutorial aside, let’s get into the dirt i uncovered in today’s study. I had a rack rental from 10:30 PM to 4:00 AM . I did make some notes as i went along and i’m going to share them with you :

• When configuring an ASA for IPSec , always make sure you turn on ISAKMP on the required interfaces. ISAKMP is enabled on all interfaces by default in the IOS, but it’s just the opposite on the ASA. So we have to manually type in “#crypto isakmp enable <interface> “.
• There is a little disparity between the default IKE Phase 1 settings (ISAKMP) in the IOS v/s the ASA. This is to be remembered because there might be a task in the lab where they assume that we know what the default settings in the IOS and ASA are .Here’s the list.

•  VPN-filter is a feature on the ASA using which we can filter out a certain subset of traffic from traversing the VPN. This sounds very familiar to the “interesting ACL” which defines what traffic needs to be permitted within the VPN, however the interesting ACL acts as the first layer of filtering. The vpn-group acts as the second layer of filtering. This ACL is bi-directional.
  • The vpn-filter command is applied in the “group-policy” configuration sub-menu.
  • We create an ACL to define the traffic that needs to be blocked and reference that ACL here using the command “#vpn-filter value <ACL_NAME>”
  • Now here’s the tricky part. When it comes to defining the ACL . There are 2 things which have to be remembered
    • In the ACL , as far as i’ve found , the configuration has to be reversed. Here’s what i mean by this. Suppose the task requires us to block telnet traffic from traversing the VPN. It would seem logical to have the following ACL defined.
      • #access-list VPN_FILTER_ACL deny tcp any any eq telnet
      • But this doesn’t seem to work. To make it work , we need to reverse the source, destination fields in the ACL. So the ACL would now become.
      • #access-list VPN_FILTER_ACL deny tcp any eq telnet any
      • I honestly don’t know why the ASA takes it this way, but everytime i configure it this way it works.
    • Secondly, at the end of this ACL, make sure to explicitly add a “permit ip any any”, otherwise all the VPN traffic will be blocked.
• When using the hostnames as the IKE ID for IKE phase 1 authentication, these are the things which need to be ensured to make sure it’s working
  • Make sure that there is a tunnel-group in the ASA with the remote-peer’s hostname ( Full hostname .ex : R3.Tacack.com )
  • Enter the command “#peer-id-validate cert“, under the tunnel-group ipsec-attributes sub-menu. This makes sure that the peer-id-validation is not mandatory and it can be obtained from the certificate . By default #peer-id-validate req is the command which is enabled, which means that the peer-id is required for landing in the appropriate tunnel . This will not work when using hostnames as the IKE-ID. So this must be changed
  • When using pre-shared keys for authentication, make sure you turn on aggressive-mode if you want to match the peers by their hostnames.
    • ASA : #crypto map VPN_MAP 10 set phase1-mode aggresssive.
    • IOS : #crypto isakmp profile VPN_PROFILE
                      #initiate-mode aggressive
  • Other than this, it’s the usual configuration which one must follow for using aggressive mode with hostname
• When you are configuring 2 devices on either sides of an ASA( which is doing NAT ) setup an IPSec tunnel between them, make sure you turn on NAT -traversal on the initiaing router.
  • IKE v2 automatically performs an action known as “NAT-DETECTION” ( NAT-D for short ), which enables the initiating peer to detect the presence of a device in between , which performs NAT. The way it does this is interesting and i’ll post an article here on how it does it soon. If there is a NAT’ting device detected, it starts sending it’s ISAKMP packets on UDP port 4500 instead of the usual port UDP 500 , and it also informs the receiving peer to expect the ISAKMP packets on 4500.
  • To turn on NAT-traversal on the initiating router, configure Nat keepalives once every “x” seconds. The crypto isakmp nat keepalive command allows users to keep the dynamic NAT mapping alive during a connection between two peers. A NAT keepalive beat is sent if IPSec does not send or receive a packet within a specified time period
  • Since the address of the initiator will be translated, we’ve to configure a dynamic crypto map on the receiving peer’s end with a wild-card pre-shared key.
• Always note, the basic processing of a packet as it enters an ASA is
  • Inside ACL -> XLATE -> Processing -> XLATE -> Outside ACL.
  • So , remember that if we configuring Inside NAT, the Encryption always happens AFTER translation.
• OEQ : After phase 1 , a single , bi-directional tunnel is establsihed, After phase 2, 2 uni-directional IPsec tunnels are established.

Well, i’ll be doing the rest of the lab today and i’ll fill you in on any other stuff i find.

Cheers,

TacACK

Morning!

Have i told you all how much i would love to Shoot AAA in the face ( if it was a person )? There are just these fine nuances which cause all the problems when you start working them out.

When i did the labs, i took much longer than i expected, but it was ok. This is one of the hardest things for me and it’s important for me to get this right. So i fired up ACS on my Win2003 server VM and started.

Here are some points that i made during my labs : (I know i’ve mentioned some in my previous posts, but i’m adding it here too, so that it’s all in one place )

• I’ve always wanted a quick reference chart for all the differences between RADIUS and TACACS. So i made a small table. Here it is

RADIUS	TACACS+
UDP 1812 , 1813 ( Latest and final )UDP 1645 , 1646 ( Old , but used in Cisco devices )	TCP port 49
2 messages used : 1 message combines both Authentication and Authorization, the other one caters to Accounting	3 messages : 1 each for Authentication ,Authorization and Accounting.
RADIUS encrypts only the password in the access-request packet, from the client to the server. The remainder of the packet is unencrypted. Other information, such as username, authorized services, and accounting, can be captured by a third party.	TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header. Within the header is a field that indicates whether the body is encrypted or not. For debugging purposes, it is useful to have the body of the packets unencrypted. However, during normal operation, the body of the packet is fully encrypted for more secure communications.
RADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contain authorization information. This makes it difficult to decouple authentication and authorization.	Separate packets for Authentication , authorization and accounting. During a session, if additional authorization checking is needed, the access server checks with a TACACS+ server to determine if the user is granted permission to use a particular command. This provides greater control over the commands that can be executed on the access server while decoupling from the authentication mechanism.
RADIUS does not support these protocols: AppleTalk Remote Access (ARA) protocol NetBIOS Frame Protocol Control protocol Novell Asynchronous Services Interface (NASI) X.25 PAD connection	TACACS+ offers multiprotocol support.
RADIUS does not allow users to control which commands can be executed on a router and which cannot. Therefore, RADIUS is not as useful for router management or as flexible for terminal services.	TACACS+ provides two methods to control the authorization of router commands on a per-user or per-group basis. The first method is to assign privilege levels to commands and have the router verify with the TACACS+ server whether or not the user is authorized at the specified privilege level. The second method is to explicitly specify in the TACACS+ server, on a per-user or per-group basis, the commands that are allowed.
Open source	Cisco proprietary

• Another issue which was bothering me was : Where can i only use Radius , where am i not supposed to use TACACS+ . So this is what i found

FEATURE	PROTOCOL TO USE
Command Authorization	TACACS+
Cut-through-proxy ( ASA )	RADIUS (for downloadable ACL’s )
Authentication –proxy (IOS )	RADIUS or TACACS+ ( although the configuration is different for both )

• Those were the tricky ones. I hope they’ll help you like they help me.
• Important point. Consider a situation where a router has 2 interfaces. One fa 0/0 and one loopback interface.
  • Now if our task requires us to source the tacacs+ ( or you can also use radius ) authentication requests from the loopback interface , we would enter the command
    • (config)#ip tacacs source-interface lo 0
  • Everything’s fine initially. The authentication requests go the AAA.
  • But now the AAA doesn’t know how to reach the lo 0 interface of R0.
  • So one of the things we have to do is, check if there is connectivity or reachability to the radius/tacacs+ source IP from the AAA server.
  • If we don’t have a route, then get into the command prompt on the AAA server and type in “route add <loopback’s IP> <The routers fa 0/0 IP which is reachable by the AAA server>”. This will create a static mapping on the AAA server.
  • P.S : Also make sure that when you define a AAA client on the ACS, we use the “source-interface” IP as the IP address of the client. So, here the client’s ip would be the loopback0’s IP.
• If you enable command authorization , then every command which is typed is sent to the AAA server for authorization. Now there’s some “fine-print” here. I KNOW!
  • by default when we enable command authorization using the “aaa authorization commands <list> <method1> … <method N >”,  only the commands typed in the exec mode are sent to the configured method to be authorized.
  • If you also want Configuration mode commands to be authorized , you must enter the command “aaa authorization config-commands“.

For now this is what i’ve observed when i did the configuration. If i find more, i’ll update this post. I hope this helps.

Sometime this week , i want to make videos about the dreaded ACS and post them here. I hope i find the time, or rather use the free time

Cheers,

TacACK

It’s day 5 and I received the INE AAA Vol 1 BETA test module today! I totally suck at AAA. I mean, i can do local AAA but i so hate the ACS ( grrr..) .

So i pulled up my sleeves today and started working with ACS and AAA. The first few tasks went by easily ( typically to do with some local authentication+ authorization ).

But then, the problems started. I had to perform command authorization for configuration mode level commands using the ACS. So i set everything up and even enterered “aaa authorization config-commands” to enable the configuration level commands to be authorized. But no matter what i did i couldn’t get the AAA server to authorize the commands.  I entered some debug statements and i could see that the commands were being sent to the ACS for authorization, but i only got back fail messages. I still can’t figure out why i’m getting that. BTW all the exec mode commands are getting authorized perfectly. Wierd!

Here’s another little thing i found out. If  you’re sourcing the TACACS+ or RADIUS requests from a loopback interface, then make sure the AAA server can reach that loopback address. Most often than not, this won’t be reachable. So make sure you manually add a route in the AAA server using the windows command ” route ADD <loopback’s address> <neighbour’s IP> “.

I can’t do any studies tomorrow because i’m going out to my granny’s house for some lunch and relaxation. I’ll see you all on Monday!

Cheers,

TacACK

Hello!

Wow! Today was intense! There are a couple of things that i did/studied today. Here’s the list

• Installed ACS on my PC,  and spent some time understand and working with it..as @packetu would say, it’s definitely got lotsa moving parts for sure!
• There was a CLND thread which i saw today morning, regarding FPM (Flexible packet matching ). There was some problem regarding matching the dot1q encapsulated packets in a trunk port.
  • So i did some digging around and did a small lab.
  • In case of dot1q encryption ,  the dot1q data ( TPID + VLANID ) ,etc are embedded between the Source MAC address and the Type field in the Ethernet-2 header.
  • So when i use the ETHER stack and create a class-map of type stack, and if i match the type field, the IOS does not recognize that there’s a new field which is introduced where the old TYPE field was.
  • So instead of matching the type, it will inturn match the TPID field of the dot1q frame which is 0×8100.
  • This might be a lab issue, where they might ask you to perform FPM on the trunk link, so beaware of this fact.
  • To get FPM working for trunk links you can do the following
    • we could define a class of type “access-control” and manually define an offset from the start of the ETHER-II header , after which the IOS has to match the bytes to a given value. This offset now would be equal to the DESTINATION MAC ADDR ( 6 bytes ) + SOURCE MAC ADDR ( 6 bytes ) =12 . So we are expecting to find the TPID value of 0×8100 ( saying that it’s dot1q encapsulated vlan traffic ) at the 13th and the 14th byte. 
      • #class-map type access-control match-all input 
        • #match start l2-start offset 12 size 2 eq 0×8100
• After doing this, we can even filter based on the VLAN ID of the dot1q encapsulated packet which is arriving on our trunk link. Ex : Here VLAN 121 is connected to the Sub-if fa 0/0.121 on the TRUNKING ROUTER. So we want to filter (drop) all packets going from VLAN 121 to let’s say…a destination ip of 200.200.201.4/24 ( which happens to be in VLAN 122 ). Here’s the config
  • class-map type access-control match-all input
    • match start l2-start offset 14 size 2 eq 0×79 (What this does is it matches the 15th , 16 byte for a VLAN ID of 121 = 0×79 )
    • match field IP dest-addr eq -926365436 ( this is matching the destination IP of the packet to be 200.200.201.4 , the -ve number is some wierd internal representation of that IP )
• And then we map this into a policy-map and apply it on the sub-if on which we want the action to take place.
• Next, based on ANOTHER thread ( yes, i know! )  i got curious about Turbo ACL’s and how they work. I did some research on this  ( 4.5) hours to be exact and published this small post about my findings. Do check it out if you’re free It’s kinda interesting.
• Other than that, i did some reading on PVLAN’s and finally configured them and got them working. Here’s the material i was reading. This is awesome!

I’m excited about tomorrow , ‘coz i’ll be getting to BETA test the INE AAA vol 1 labs v5. I’ve always been very weak in AAA and i see this as a great opportunity to develop, sharpen skills in this area. Again , Thanks INE!

I’ll keep you all updated as to how my studies went!

Till the next post,

Cheers,

TacACK