Goodbye '09

Hi Everyone,

As the year winds up, I figured I'ld steal a quick post - the very last one for 2009.

2009 was a quite a phenomenal one - You'ld probably be in 2010 by the time you are reading this ;)

Highlights of the year include; GEM (Global Economic Meltdown), Graduation from the University, Passing the CCIE R&S lab, Serving my country, Starting this blog and a whole lot of other events.

Looking back at the year, there is a lot to be happy about and I am immensely grateful to God and everyone that made the year a special one. Thank you to family, friends, peers, colleagues and everyone.

Wish you all a great new year. Its about 90mins away from here. Let the fireworks begin :-)

Cheers,

Amplebrain.

ASA Cut-Through Proxy Part 2: Radius Authorization

AAA Authorization and Authentication are two separate processes. Authorization must be performed after Authentication has taken place. That makes sense because we have to know who the user is before we can know what he can do right?

While User Authentication and Authorization are separate processes, they are implemented together in the RADIUS server. The User is Authenticated and downloadable access-lists are used to perform Authorization for the user.
From a configuration perspective, no further authorization command is needed on the ASA as the authentication and authorization is performed at once on the RADIUS server.

From the radius server perspective, there are two ways to accomplish authoriztaion.

1. The radius server can reference an ACL configured on the ASA which is now 'activated' after the user has authenticated. In this case, the access-list name is specified under the radius attribute 11 (filter-id). The access-list can also be specified under the cisco AV pair (009,001) attribute.


2. The Access-list entries can be defined on the ACS server and downloaded unto the ASA after the user has authenticated.
Downloadable access-lists can be created on the server using the Advanced downloadable access-list features, (This must be activated from the Interface configuration tab). Check the box for "group-level downloadable access-lists"

The other option is to specify the access-list entries in the cisco-av-pair using the "inbound access-list" syntax.

ip:inacl#[acl-line-number]=[acl permit/deny statement] for example:

ip:inacll#1=permit ip any any



Note that there must be an authentication protocol for authorization to work, if none of the authentication protocols (telnet, http(s) or ftp) is configured, then the virtual telnet/http command should be used.



Consider the following same topology as the previous post;

R1 --- (inside)ASA(outside) -- R2 where the Radius server is on the inside interface.

The user would be authorized to telnet from the outsude interface to R1 on port 3070.



1. Configure the authentication AAA server on the ASA.

aaa-server ACS protocol radius

aaa-server ACS (inside) host 10.10.10.5

key bauxite



2. Configure the Authentication access-list


access-list AUTH extended permit tcp any host 2.2.2.2 eq telnet

virtual telnet 2.2.2.2




3. Since it is on the outside the access-list must be configured to allow the authentication traffic:



access-list OUTSIDE_IN permit tcp any host 2.2.2.2 eq telnet

access-group OUTSIDE_IN in interface outside



4. Configure AAA for authentication


aaa authentication match AUTH inside ACS




5. Configure the AAA server: To keep things simple, we would define the access-list test_auth on the ASA and then refer to it through the filter-id attribute of the RADIUS server:



access-list test_auth extended permit tcp any any eq 3070

access-list test_auth extended permit tcp any host 2.2.2.2 eq telnet



The 2nd line of the acl is added so that the telnet session for authentication does not die after the authorization has taken place on the ASA. If the telnet session is not allowed by the authorization acl, though authorization would still take place, the telnet session would die immediately after the user is authorized and an error would be returned (though the process was successful), we would rather add the line for sanity sake. :-)



On the Radius server:



6. Enable Per-user override on the inbound access list on the outside interface;

This makes the downloaded access-list take precedence over the existing interface access-list
access-group OUTSIDE_IN in interface outside per-user-override



7. Verification


Enable telnet on port 3070 on R1



line con 0

rotary 70

password cisco





Before Authorization:



R2#telnet 10.10.10.3 3070

Trying 10.10.10.3, 3070 ...

% Connection timed out; remote host not responding



R2#telnet 2.2.2.2

Trying 2.2.2.2 ... Open



LOGIN Authentication



Username: Amplebrain



Password:




Authentication Successful




[Connection to 2.2.2.2 closed by foreign host]



R2#telnet 10.10.10.3 3070

Trying 10.10.10.3, 3070 ... Open




User Access Verification



Password:

R1>




Show User Authentication on the ASA


ASA#sh uauth


Current Most Seen


Authenticated Users 1 1

Authen In Progress 0 1

user 'Amplebrain' at 192.168.1.2, authenticated

access-list test_auth (*)

absolute timeout: 0:05:00

inactivity timeout: 0:00:00


As I mentioned earlier, Authorization can also be accomplished using the tacacs+ protocol but this is implented entirely differently. I hope to put up a post on this sometime in the future.



Anyway, this is the last technical post for the year 2009!



Wishing everyone a prosperous 2010...Cheers!


Amplebrain

ASA Cut-Through Proxy: Part 1

In the previous post, I discussed the IOS Authentication Proxy and hw it is used for 'authorization' using downloadable access-lists. In this post, I would describe the Cut-through proxy feature of the ASA.

The Proxy Authentication feature of the ASA is tied to the AAA process.
Authentication proxy can be configured for any protocol but authentication is performed by the telnet, http, https and FTP protocols. If any other protocol is requires authentication, one of the other "authentication protocols" (ftp, http(s) or telnet) MUST also be configured to authenticate the user before access can be granted.
Once a protocol is configured for authentication under the AAA process, unauthenticated users are not given access to the protocol.

The Authentication and Authorization processes are separate on the ASA.
Users can be authenticated using the local database, tacas+ server and the RADIUS server. Users can only be authorized with Radius or Tacacs+ but not the local user database.

Unlike Auth-Proxy, the traffic required for authentication MUST be allowed in the access-lists otherwise Authentication/Authorization wouldnt be able to take place. Authorization can be used to allow further traffic.

Lets look at a simple example of proxy-authentication using the local database. Assuming we have the topology:

R1 ---- (inside)ASA(outside) ---- R2

Base configuration:

interface Ethernet0
nameif inside
security-level 100
ip address 10.10.10.1 255.255.255.0
!

interface Ethernet1
nameif outside
security-level 0
ip address 192.168.1.1 255.255.255.0
!

1. Specify traffic to be Authenticated using an access-list

access-list AUTH extended permit icmp any any
fixup protocol icmp

The fixup protocol is used to ensure icmp traffic is inspected. (It is a quick fix compared to using the MPF). Another option would be to allow icmp inbound on the outside interface.

2. Configure AAA server: We would just add a user since we are using the local database.
username Amplebrain password cisco


3. Configure AAA on the ASA

aaa authentication match AUTH inside LOCAL
auth-prompt prompt Authenticate Before Access
auth-prompt accept Access Granted
auth-prompt reject Access Denied

The line "aaa authentication match AUTH inside LOCAL" means that traffic matched by the AUTH access-list on the inside interface must be authenticated using the local database before they can be allowed to pass through.

4. Test

R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

We cant reach R2. This is because we are authenticating icmp protocol but icmp is NOT one of the authentication protocols. At least one authentication protocol configured for authentication for this to work.
The ASA uses the virtual command for this.


5. Configure Virtual Telnet address and add 2.2.2.2 to the AUTH traffic

virtual telnet 2.2.2.2
access-list AUTH extended permit tcp any host 2.2.2.2 eq telnet

The authenticating user must have a route to 2.2.2.2 for this to work properly.

6. Test Again: Authenticate with virtual telnet and then ping.


R1#telnet 2.2.2.2
Trying 2.2.2.2 ... Open

LOGIN Authentication

Authenticate Before Access
Username: Amplebrain

Password:
Access Granted

Authentication Successful


[Connection to 2.2.2.2 closed by foreign host]
R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
24/88/196 ms
R1#


On the ASA, we can show authenticated users

ASA(config)# sh uauth
Current Most Seen
Authenticated Users 1 1
Authen In Progress 0 1
user 'Amplebrain' at 10.10.10.3, authenticated
absolute timeout: 0:05:00
inactivity timeout: 0:00:00
ASA(config)#

The next post would describe proxy-authorization using the Radius Server.

Compliments of the season :-)

Amplebrain.

IOS Authentication Proxy

Authentication Proxy is a very useful cisco IOS Firewall Feature.
IMO, It is a more 'advanced' form of dynamic access-list.
Back with Dynamic access-lists, users were required to authenticate using Telnet and then the dynamic entry in the access-list is activated using the "access-enable" command. This can be automated using the autocommand feature either with the username command or under the line configuration.

Drawbacks of Dynamic access-list include;
1. It requires that the user first telnets into the router.
2. You can only have one dynamic entry line in an access list. The work around was normally to give access to a bastion host that is now used to access further resources (or to use)
3. You cannot have user specific (or group specific) profiles.

Documentation for dynamic access-list can be found here.

The IOS Auth-proxy feature was designed to fix these issues. It uses the ACS Server for Authentication and Authorization. Either the radius or tacacs+ server can be used for auth-proxy.

The IOS auth-proxy service uses user/group specific downloadable acls that is downloaded from the ACS server unto the router. This access-lists are specified on the AAA and attached to the auth-proxy service. This is implemented a little differently on the radius and the tacacs+ server.

On the Tacacs+ server, the auth-proxy service is first added, from the Interface Configuration Section, then access-list is specified under the user/group settings. The privilege level must be set to 15 for the access-list to be downloaded correctly. An example of the custom attributes of the auth-proxy service that would be defined in group settings would be:

priv-lvl=15
proxyacl#1=permit ip any any

With the Radius server, the downloadable access-list is set as the cisco-av-pair (9,1) as we would see in the example below.
Assuming we have the topology below;

We want to implement AP for users in the inside network. We would use telnet and http as our protocols for authentication.

Default configuration:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
ip access-group 101 in
interface FastEthernet1/0
ip address 192.168.1.1 255.255.255.0
access-list 101 permit ip host 10.10.10.5 host 10.10.10.1
access-list 101 deny ip any any

Note that the address of the ACS server is allowed to communicate with the router so that authentication can take place.

There are 5 steps in this configuration:

1. Configure AAA on the router
FW#sh run | i aaa
aaa new-model
aaa authentication login default group radius
aaa authentication login cons none
aaa authorization auth-proxy default group radius
radius-server host 10.10.10.5 auth-port 1645 acct-port 1646 key bauxite

The 'cons' method is defined so as to exclude the console line from AAA authentication.

2. Configure AAA on the server. The radius configuration snapshot is shown below



3. Configure auth-proxy on the router.

ip auth-proxy auth-proxy-banner http #Authenticate before Access....#
ip auth-proxy auth-proxy-banner telnet #Please Authenticate#
ip auth-proxy name test http inactivity-time 60
ip auth-proxy name test telnet inactivity-time 60

4. Configure http-server for http authentication process
ip http server ip http authentication aaa

5. Apply Auth-proxy on the interface.

int f0/0 ip auth-proxy test

Verification:
From the Inside Router:
INSIDE#telnet 192.168.1.2
Trying 192.168.1.2 ... Open

Please Authenticate
Username:Amplebrain
Password:
Firewall authentication Success.
Connection will be closed if remote server does not respond
Connecting to remote server...

User Access Verification

Password:
OUTSIDE>

For http: Here are snapsots from the From the inside host:

After Authentication:

Merry Christmas!

Hi Everyone,
Merry Christmas.
Hope you all have fun and stay away from 'geeky' stuff :-)
Here's what I'ld call a totally "cisco-geeky" xmas.
Thanks to Joe Astorino on GS for the link.

As the year comes to an end, it's time to take stock and make resolutions for 2010.
Feliz Navidad guys!

Amplebrain

Configuring BGP through the PIX/ASA.

When configuring BGP through the ASA, a basic understanding of how the ASA works and how BGP is implemented is very important. I would highlight some of my findings about the BGP/ASA relationship in this post.

1. The ASA (when in routed mode) is a HOP: This doesnt matter if we are configuring ibgp since BGP believes that the underlying IGP would take care of reachability to the neighbor but with ebgp, we need to explicitly state that the bgp neighbor is not on the same subnet. The ebgp multihop command is used to achieve this. Lets assume the following topology;

R2(f0/0) --- (ins) ASA (out) --- (f0/0) R3.

on R2 (and similarly on R3), we need to configure:

router bgp 1
neighbor 192.168.13.3 remote-as 2
neighbor 192.168.13.3 ebgp-multihop 2

When configuring ebgp multihop, we should also ensure that there is a route to the neighbor with a length greater than 0 (default route will not work) in the routing table..

Assuming we have on R2,

ip route 0.0.0.0 0.0.0.0 192.168.12.1

When we try to negotiate the BGP connection, it would fail (except R3 configured properly - which would always make R3 active). When we look at the debugs, we would see;

BGP: 192.168.13.3 active open failed - no route to peer, open active delayed 29090ms (35000ms max, 28% jitter)

But when we take a look at the routing table, sure enough, our default route is there...

R2(config-router)#do sh ip rou
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.12.1 to network 0.0.0.0

C 192.168.12.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 [1/0] via 192.168.12.1

This is because the router actually searches for a route going to 192.168.13.3 and finds none.

R2(config-router)#do sh ip rou 192.168.13.3
% Network not in table

To fix this, we insert a route with a longer match in the routing table (doesnt have to be a host route, anything from a /1 would do)

R2(config-router)#ip route 192.168.0.0 255.255.0.0 192.168.12.1

That should fix things considerably and the BGP neighbor should come up.

2. The ASA does NAT: If the ASA NATs the address of the BGP peer, the neighbor statement should reflect this. Assuming we had a static statement on the ASA,
static (i,o) 192.168.13.2 192.168.12.2

Then on R3, we would peer with 192.168.13.2 instead of 192.168.12.2

neigh 192.168.13.2 remote 1

This would work well if Authentication is NOT configured.

3. Configuring BGP Authentication: BGP Authentication uses special tcp option for MD5 (option 19) to carry the Authentication information. This is stated in rfc 2385. The 16-byte MAC is computed based on a one-way hash function (MD5) generated from TCP header, the IP header, the password and a key. The following must be considered when configuring BGP authentication through the ASA:
a. Since the IP header is used in generating the hash, NAT cannot be used to change the ip address of the peers as this would break the authentication. If nat-control is enabled, the real and translated ip address must be the same.
b. Since the tcp header is used, the sequence number must not be randomized (default behavior of the ASA.) To stop randomization we can append the norandomseq option behind a static address mapping (that does not change the IP address) of the neighbor. This would only work in routed mode (of course)

static (inside,outside) 192.168.12.2 192.168.12.2 no randomseq

We can also disable random sequencing in the global_policy.

c. Finally, option 19 must be allowed to pass through the ASA for BGP traffic. This can be achieved by allowing it in the global_policy. The configuration on the ASA is shown below.

tcp-map BGP
tcp-options range 19 19 allow
!
class-map BGP
match port tcp eq bgp
!
policy-map global_policy
class BGP
set connection random-sequence-number disable
set connection advanced-options BGP
!

That would be all for now.
Further Reading

BGP through ASA configuration exmaple
RFC 2385: Protection of BGP Sessions via the TCP MD5 Signature Option

Amplebrain.

21 yr old CCIE : Interview with CCIE Agent

I was going thru CCIE flyer October Edition when I stumbled on Peter Ehiwe's interview. Peter is my friend, classmate and study partner. Details of the interview can be found here.

Quote of the day: "Peter you are so young just 21 years old. I have shoes older than you!" - Eman Conde (CCIE Agent) :D

Way to go bro!

Amplebrain.

Shooting yourself in the leg

When doing personal study/'research', whether for the CCIE lab or some other exam, we get used to some practices that save time and aid troubleshooting. Many students have a template of initial config on their routers. Here is an example of what I would have on mine.

alias exec s sh ip interface brief
no ip domain-lookup
line con 0
logging synchronous
no exec-timeout

and a few other commands.

It is also common to turn on debugs when trying to troubleshoot a problem or understand a protocol.

While these practice definitely saves time, it should ONLY be used in a lab environment and the routers should be adequately CLEANED up before being put into production.

Recently. I got a call from a friend, he just put in a box that he used to study sometime ago into production and his router stopped resolving hostnames to ip addresses. The DNS server was properly configured and he had pointed to it using the ip name server command.

While reading through this post, the answer is obvious, but in a production environment with many issues and phone calls, it is a lot more difficult to decipher and you would probably need another pair of eyes going through your config.

We figured out that he had the no ip domain-lookup configured from one of his practice sessions and forgot to take out the command during clean-up. The issue was resolved and everything was fine.

Moral of the story: Cisco would arm you with a Gun and they wouldn't stop you from shooting yourself with a gun. Lab environment and production environments are totally different.

Turning on debugs in a produvtion environment could be a lot worse, It is important for a network engineer to be able to handle logs appropriatelyy but that's going to be a post for another day.

Have fun with your job and with your studies.

Amplebrain.

Is Cisco Superstitous?

Cisco systems has released the IOS 15.0M - Mainstream version.
The sudden jump from the IOS 12.4T series to the 15.0 is remarkable. Why did they chose to skip 13.x and 14.x - could the software development team be Tetraphobic or Triskaidekaphobic?
I doubt that the are tetraphobic though - Since we had 12.4T :-)

What's new? New Features in the 15.0 IOS release can be found here.

More cool features. More fun stuff..

Enjoy!

Amplebrain :-)

NAT and IPSEC Interoperability

After close to three weeks of silence... Here is the post I promised in my last post.

I have decided to avoid configurations in this post. The theory is boring enough :-)

We are going to examine two scenarios;

Scenario 1: The VPN device also performs NAT.

If the edge router/ASA does NAT and VPN, there are two basic options available;
1. Exclude the interesting traffic from the NAT pool
On a router, a route-map can be used to reference an access-list which excludes the VPN traffic from being 'NATTED'

On the ASA, the nat 0 command is used for nat exemption

2. If NAT is enabled for the VPN traffic. The order of operation must be understood.

The Cisco IOS order of operations performs NAT Translation before the crypto map is matched. The access-list specified on the crypto map must match the GLOBAL (Translated) address. Encryption occurs after translation.

The return traffic, decryption occurs before, before NAT Translation is performed.

Scenario 2: There is a NAT device on the path.
Remote Access VPN clients might have to establish a tunnel through a router (might be the local gateway) performing NAT. The inherent problems with this are described in RFC 3715.

The solution to this problems are described in RFCs 3947 and 3948. From a configuring standpoint, there's little to be done. The peers automagically detect a NAT detects a NAT device in between and switches to UDP encapsulation for NAT by default. The new UDP packets must be allowed by any access-lists for this to work.

Since NAT configuration is common in many network environments, It is required for network engineers to have a thorough understanding of the concept.

For Further Reading:

NAT Order of Operation

IPSec NAT Transparency

RFC 3715 IPsec-NAT Compatibility Requirements

RFC 3947 Negotiation of NAT-Traversal in the IKE

RFC 3945 UDP Encapsulation of IPsec ESP Packets

SSL VPNS Part 2: Anyconnect VPN Client

The SSL VPNS can operate in three modes, I have discussed the first 2 in a previous post. In this post, I would describe the Anyconnect VPN Client.

To set up the anyconnect VPN client, The Anyconnect VPN Client is stored on the flash and then downloaded and installed on the client. The VPN client can be removed after the session is terminated and can be left on the client PC depending on the router configuration. If the VPN client is left on the PC, subsequent connections would not require downloading the anyconnect client on the PC.

The anyconnect-win-2.3.2016-k9.pkg is the latest release of the anyconnect client on cisco site. You need a CCO account to download this.

Steps.
1. Copy the VPN Client to the memory of the Router.

WEBGATEWAY#copy tftp flash:/webvpn/svc.pkg
Address or name of remote host []? 10.10.10.2
Source filename []? anyconnect-win-2.3.2016-k9.pkg
Destination filename [/webvpn/svc.pkg]?
Loading anyconnect-win-2.3.2016-k9.pkg from 10.10.10.2 (via FastEthernet0/0): !!!!!!!!!!!
[OK - 2672571 bytes]
Verifying checksum... CCCCC OK


2. Install the client on the router
WEBGATEWAY(config)#webvpn install svc flash:/webvpn/svc.pkg

SSLVPN Package SSL-VPN-Client : installed successfully
WEBGATEWAY(config)#

3. Set up the local pool

WEBGATEWAY(config)#ip local pool ANYCONNECT 192.168.1.5 192.168.1.50

4. Configure the webvpn context to support anyconnect.

WEBGATEWAY(config)#webvpn context SSL
WEBGATEWAY(config-webvpn-context)#policy gr SSLVPN
WEBGATEWAY(config-webvpn-group)#function svc?
svc-enabled svc-required

WEBGATEWAY(config-webvpn-group)#function svc-enabled
! svc-enabled allows fall back to thinclient and clientless mode if ! anyconnect fails.
WEBGATEWAY(config-webvpn-group)#svc address-pool ANYCONNECT
WEBGATEWAY(config-webvpn-group)#svc keep-client-installed
! keeps the vpn client on the client after the session has been terminated

TEST Here are some snapshots from my PC








Test connectivity to the internal network..

But connectivity to the local LAN is lost...


To configure split Tunneling

WEBGATEWAY(config-webvpn-group)#svc split include 192.168.1.0 255.255.255.0

TEST Disconnect and reconnect. ;)


Anyconnect is up and running! :-)

N.B: When setting up SSLVPN on GNS3 using windows vista (like I did), ensure that the VPN client is copied to flash:/webvpn/svc.pkg as the router would not be able to modify the file system of the flash when you use the webvpn install command.

2. You might need to recreate a trustpoint after reloading the router.

3. If you are using the self signed certificate and Internet explorer, ensure that the webvpn gateway address is added to your trusted sites otherwise the anyconnect download would fail.

In real world scenarios, we might need to setup VPN and NAT for enhanced security (and connectivity), In the next post, I would discuss the nteroperability of NAT and VPNs.

Ciao.

Amplebrain.

Remote Access VPNS: SSL VPNS

The SSL VPN (aka webvpn) is the most flexible kind of Remote access VPN connection. All you need is an SSL enabled browser - Internet Explorer, Mozilla, Safari etc. I would go right to the configuration.

Network Diagram:



Web Gateway Configuration:

-Configure AAA for authenticaton:
aaa new-model
!
!
aaa authentication login VPN local

Configure the webvpn gateway and put it INSERVCIE
! webvpn gateway GATE
ip address 12.12.12.1 port 443
http-redirect port 80 !makes the router to listen on port 80
inservice !

Immediately after a webvpn gateway command is entered, a self-signed certificate is generated. This CA can be changed using the ssl trustpoint command.
Next the webvpn context is created...
webvpn context SSL
secondary-color blue
secondary-text-color white
!

Next, a URL-List is created;
url-list "list1"
heading "Available Pages"
url-text "Home Page" url-value "books.durable.com" !

For Thin client connection, a port-forwarding list is created.

!
port-forward "Ports"
local-port 3065 remote-server "TELNET" remote-port 23 description "telnet"
!
The pieces are tied together using the policy group command.
!
policy group SSLVPN
url-list "list1"
port-forward "Ports"
banner "Login Successful"
timeout idle 300
timeout session 3600
!

Next we set the default group policy, the AAA authentication list and add a gateway to the context.

default-group-policy SSLVPN
aaa authentication list VPN
gateway GATE
inservice
!

TESTING
I prefer to test with the end user - Here are some snapshots.



After successful authentication, we have;



When you click start, you have;

Finally, lets try to telnet to localhost port 3065


Just as we want it :-)


Up Next: Anyconnect :-)


Ciao.


Amplebrain.

GET VPN - Implementation Issues

Cisco's implementation of GETVPN uses "header preservation" - the header of the IP Packet is preserved and the payload is encrypted. As a result, GETVPN is not suitable for IPSEC VPN across the internet (except the inside network uses public ip addresses). A workaround is to use GRE tunnels.
Besides this obvious caveat, there are some more subtle security issues with GETVPN. Jan Bervar highlights some of these issues in Fragments.

That said, IMHO, GETVPN is still a nice implementation of VPNs.

Site to Site VPNS - Introducing Cisco's GETVPN

As I mentioned in a previous post, there are many kinds of Site to Site VPNS that can be implemented on a cisco router.
There are many resource materials on the internet on Basic Point-to-Point Site-to-Site IPSEC VPNS. I do not intend to add to the tons of materials already out there.

GRE/IPSEC VPNS are implemented similarly as all traffic is passed through the GRE tunnel (encapsulated with GRE) and the GRE traffic is now encapsulated with IPSEC. Here the GRE traffic is the Interesting traffic.

DMVPN involves setting up VPNS when they are needed between sites. This involves a combination of NHRP, mGRE, CEF and IPSEC. Petr Lapukhov, 4xCCIE, an instructor at INE has a detailed technical post on DMVPN, which can be found on the INE blog.
Boštjan Šuštar also has another technical article on DMVPN that explains it from a real world perspective. It can be found at the NIL IPCorner. I strongly recommend that you go through both materials. I dont think I have anything to add to these; they have everything on DMVPNs covered :-)
Besides, Boštjan was probably a CCIE before i could even spell a router ;)

And now, GETVPN :-)
GETVPN is cisco's new VPN technology (from IOS 12.4(6)T). The concept is simple.
VPN Sites for an organisation are in a group. The group consists of one or more key servers (more than one key server is advised for redundancy).
The group memers would request for the SAs from the server. The server is actually configured with all the SA parameters. the server just sends out the SA to the members, The server also sends the traffic to be considered INTERESTING to the members. they DO NOT negotiate SAs between each other. This Hub and spoke mechanism is used to download the SAs.

The actual IPSEC communicaion occurs on a full mesh topology as the spokes just encrypt the traffic based on the information downloaded fron the key server.

Implementation:
Diagram:


Basic Configuration
Key Server:

conf t
hostname R1
interface Serial 0/0
ip address 172.16.14.1 255.2552.255.0
end

Group member 1

conf t
hostname R2
interface Serial0/0
ip address 172.16.24.2 255.255.255.0
end
interface Loopback0
ip address 192.168.2.1 255.255.255.0
end

Group Member 2

conf t
hostname R3
interface Serial0/0
ip address 172.16.24.2 255.255.255.0
end
int loopback 0
ip address 192.168.3.1 255.255.255.0
end

Server Configuration;

access-list 103 permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp key cisco address 172.16.24.2
crypto isakmp key cisco address 172.16.34.3
!
crypto ipsec transform-set TRANSF esp-3des esp-md5-hmac
!
crypto ipsec profile GETVPN
set transform-set TRANSF
!
crypto gdoi group VPN
identity number 1
!
server local
!
rekey retransmit 10 number 3
registration interface Serial0/0
sa ipsec 10
!
profile GETVPN
match address ipv4 103
!


Group Member Configuration (Identical on both sides):

crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 172.16.14.1
crypto gdoi group VPN
identity number 1
server address ipv4 172.16.14.1
crypto map GETVPN 10 gdoi
set group VPN
interface s0/0
crypto map GETVPN

Test :-)

R2(config-if)#do sh cry ipsec sa

interface: Serial0/0
Crypto map tag: GETVPN, local addr 172.16.24.2

protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
current_peer 172.16.14.1 port 848
PERMIT, flags={}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 172.16.24.2, remote crypto endpt.: 172.16.14.1
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
current outbound spi: 0x38FEDAF9(956226297)

inbound esp sas:
spi: 0x38FEDAF9(956226297)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 5, flow_id: SW:5, crypto map: GETVPN
sa timing: remaining key lifetime (k/sec): (4415223/1967)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x38FEDAF9(956226297)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 6, flow_id: SW:6, crypto map: GETVPN
sa timing: remaining key lifetime (k/sec): (4415223/1960)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

Next, we would try to Ping and watch the encaps/decaps field

R2(config-if)#do ping 192.168.3.1 sou lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 176/356/552 ms
R2(config-if)#do sh cry ipsec sa

interface: Serial0/0
Crypto map tag: GETVPN, local addr 172.16.24.2

protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
current_peer 172.16.14.1 port 848
PERMIT, flags={}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 172.16.24.2, remote crypto endpt.: 172.16.14.1
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
current outbound spi: 0x38FEDAF9(956226297)

inbound esp sas:
spi: 0x38FEDAF9(956226297)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 5, flow_id: SW:5, crypto map: GETVPN
sa timing: remaining key lifetime (k/sec): (4415222/1920)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x38FEDAF9(956226297)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 6, flow_id: SW:6, crypto map: GETVPN
sa timing: remaining key lifetime (k/sec): (4415222/1917)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

The icmp packets are encrypted in IPSEC

R2(config-if)#do sh cry isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
172.16.14.1 172.16.24.2 GDOI_IDLE 1003 0 ACTIVE

IPv6 Crypto ISAKMP SA

On the server.

R1#sh cry gdoi
Group Information
Group Name : VPN
Group Identity : 1
Group Members Registered : 2
Group Server : Local
Group Rekey Lifetime : 86400 secs
Rekey Retransmit Period : 10 secs
Rekey Retransmit Attempts : 3
IPSec SA Number : 10
IPSec SA Rekey Lifetime : 3600 secs
Profile Name : GETVPN
SA Rekey
Remaining Lifetime : 3010 secs
access-list 103 permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255

Group Member List for Group VPN :
Member ID : 172.16.24.2
Member ID : 172.16.34.3

Everything is up and running. :-)

I have already posted on EZVPNS, so the only VPN configuration left is the SSL VPN. I would try to get that done in the coming week. :-)

Ciao.

Amplebrain.

Cloud Computing - Security Threats?

Cloud computing appears to be the next phase of computing. The new Google operating system would operate on the cloud computing platform.

While it definitely has its pros, the black hat USA conference last week has drawn our attention to some security threats with cloud computing. More info can be found on readwriteweb.

Again, we have to deal with it :-)

Ciao.

Why cant we just trust the internet??

Hello,
I have been studying Internet and WAN security lately and I just think it would be a lot better if the internet was secure. So let's start a campaign for "Ethical Internet Practices ;)".
Well, I have to come to terms with reality. The internet is going to remain UNSAFE for a long time. So we are going to deal with it. What options do we have?

1. Provide WAN infrastructure for all our private traffic: While this would be 'SAFE', it is no longer scalable as we have branch offices everywhere and even telecommuters. Some employees don't even know the location of the corporate offices anymore (they all work from home :-) ). Besides, this way too expensive, I'm sure your boss would not buy that either!

2. Secure our traffic and use the internet as our WAN infrastructure. We would kill two birds with one stone and we would still be friends with the finance department. :-) Welcome to the world of VIRTUAL PRIVATE NETWORKING
As a network engineer, i know VPNS have been around for a while and they have grown and become very scalable. Thankfully cisco gives us many options to suite our peculiar needs.
Broadly we have two kinds of VPN

1. Site to Site VPNS:
-IPSec VPNS
-GRE/IPSEC for communiction of routing protocols
-Dynamic Multipoint VPNS (Hub and Spoke and Spoke to Spoke)
-Group Encrypted Transport (GET) VPNS

2. Remote Access VPNS (for telecommuters)
-SSL VPN (also known as webVPN)
-Easy VPN

I don't want to get into the configuration details yet but I would post some more technical details soon.
As you must have already noticed, I am a cisco advocate and my configuration would be mostly cisco-oriented.
Feel free to post your personal experience with these technologies.

Later.

Amplebrain.

Easy VPN Configuration – Paradox

I have always wondered what was easy about the EzVPN, I got my hands dirty with it and found out that Easy VPN doesn't live up to its name (from the network engineer's perspective). Its pretty easy from the end user's perspective.

The cisco easy VPN solution involves two parties; The Easy VPN Server and The Easy VPN Remote.
The Easy VPN Server contains all the configurations and pushes the VPN settings to the client.
The Easy VPN Remote side can be a cisco device (Router, PIX/ASA firewall) or a PC with the Cisco VPN Client installed.
There are many parts to the EzVPN configuration. I do not intend to make this post unecessarily long and boring so I would try to keep things simple.

Base configuration:
Server
Hostname VPNSERVER
interface Serial0/0
ip address 172.16.1.2 255.255.255.0
ip ospf 1 area 0
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface Loopback2
ip address 192.168.3.1 255.255.255.0
!
Client
Hostname VPNCLIENT
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
!
interface Serial0/0
ip address 172.16.2.2 255.255.255.0
ip ospf 1 area 0

Easy VPN Server Configuration
-Create a local pool
ip local pool EZVPNPOOL 192.168.1.15 192.168.1.50
Configure AAA
aaa new-model
!
aaa authorization network VPNGRP local
-Create Access List for Split tunneling (Without Split tunneling, all traffic is sent to the server and the clients would lose access to the internet - In the case of VPN CLIENTS, access to the LAN is lost)
ip access-list extended SPL
permit ip 192.168.0.0 0.0.255.255 any
-Create the Client Configuration on the server. The groupname and key must match on the client side
!
crypto isakmp client configuration group EZVPNGRP
key s3cr3t
dns 192.168.1.5
wins 192.168.1.6
pool EZVPNPOOL
acl SPL
!
-Create the ISAKMP Policy
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
!
Note: Only Diffie-Helman group 2 is supported in EZVPN Configuration.
-Create the dynamic crypto map
crypto dynamic-map EZVPNDYN 10
set transform-set TRANSFORM
reverse-route
!reverse route is set so that the server can learn of client networks automatically
-Create the ‘Real’ Crypto map and attach the dynamic crypto map
!
crypto map EZVPNMAP isakmp authorization list VPNGRP
crypto map EZVPNMAP client configuration address respond
crypto map EZVPNMAP 65535 ipsec-isakmp dynamic EZVPNDYN
!
-Configure Xauth to authenticate the clients
!
aaa authentication login EZVPN local
username amplebrain password 0 cisco
!
crypto isakmp client configuration group EZVPNGRP
save-password
!The save password feature allows the clients authentication to be saved throughout !the process of establishing the VPN tunnel
-Apply the Configuration to the interfaces.
int s0/0
crypto map EZVPNMAP
THE EASY VPN REMOTE: The easy VPN Remote can be in three modes;
1. client: Here an address is assigned to the router (from the local pool configured) using an available loopback interface and the inside network is automatically translated to the that address using PAT.
2. Network-Extension: the inside network is considered to be an extension of the VPN Server's network. No address is allocated from the pool.
3. Network-Extension-Plus: the inside network is still considered to be an extension of the VPN Server's network. An address is allocated from the pool to a loopback interface of the router for testing connectivity. Only the inside network and the loopback interface can reach the VPN network.

The configuration:


crypto ipsec client ezvpn EZVPN
connect auto
group EZVPNGRP key s3cr3t
mode network-plus
peer 172.16.1.2
username amplebrain password cisco
xauth userid mode local
interface FastEthernet0/0
crypto ipsec client ezvpn EZVPN inside
!
interface Serial0/0
crypto ipsec client ezvpn EZVPN

The xauth userid mode local command tells the router to use the locally configured username and password for extended authentication.

TEST

VPNCLIENT#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.10.10.1 YES manual up up
Serial0/0 172.16.2.2 YES NVRAM up up
NVI0 unassigned NO unset up up
Loopback0 192.168.1.20 YES manual up up
Notice that loopback 0 has been added with IP address 192.168.1.20 from the local pool.

On the Server,
VPNSERVER(config)#do sh ip rou
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 2 subnets
C 172.16.1.0 is directly connected, Serial0/0
O 172.16.2.0 [110/128] via 172.16.1.1, 01:39:56, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
S 10.10.10.0 [1/0] via 172.16.2.2
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, Loopback0
S 192.168.1.20/32 [1/0] via 172.16.2.2
C 192.168.3.0/24 is directly connected, Loopback2
The Routes are a result of the RRI. You have to redistribute static if you are running a routing protocol on the inside of the VPN server.
Back on the Remote Router,
VPNCLIENT#ping 192.168.1.1 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
The Packets are lost in the cloud.
VPNCLIENT#ping 192.168.1.1 so lo0
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.20
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 264/342/480 ms


On the Inside Host,

To test Split Tunelling,
Now, its all up and running.
I would post more VPN stuff later.
Amplebrain