I recently deployed a Cisco ASA 5510 as VPN solution. We were replacing an old SideWinder VPN. There were a few post out on the internet, but I didn’t find a good step-by-step how to guide, so I figured I’d write one.

This tutorial assumes a few things:

• You have a working VPN tunnel using local authentication – You can use the VPN Wizard to do this. I will user connection profile “Test.”
• You have created a Active Directory Group – I will user VPN USERS in this example.
• You have created a read-only Active Directory user – I will use vpn user in this example.
• You have the DN’s for both the vpn user, and your base DN. You can use dsquery to obtain them – I will use the domain cisco.com in this example.

This configuration was performed on an ASA 5510 and and ASA 5505 version 8.2(2) with ASDM 6.25.

Adding the Active Directory server to the ASA

• On ASDM navigate to Configuration –>Remote Access VPN –>AAA/Local Users –>AAA Server Groups
• Under AAA Server Groups click add.
• Under name, give it a name. Select LDAP for the protocol.
• Select Reactivation mode Depletion.
• Dead Time 10 Minutes.
• Max Failed Attempts 3.
• Click OK and then click apply.

• Highlight the new server you just created, and click add under Servers in the Selected Group.
• Select the interface in which the server sits behind, this would normally be the inside interface.
• Server Type: Microsoft.
• Base DN: DC=<domain>,DC=<com> ie DC=cisco,DC=com, of course you would put your own domain instead of cisco.
• Scope: All levels beneath the Base DN
• Naming Attributes: sAMAccountName – be careful this is case sensitive.
• Login:CN=vpn user,CN=Users,DC=CISCO,DC=COM – This is the user you created .
• Login Password: Password for the user.
• LDAP Attribute Map : None.
• Leave the other LDAP Parameters blank and click OK and apply your configuration.

 

Adding the VPN Access Policy

• Navigate to Configuration –> Remote Access VPN –> Network (Client) Access –> Dynamic Access Policies.
• Select the DfltAccessPolicy and select edit.
• Change the Action to Terminate, and click ok. This will deny any connection by default.
• Click the Add button to create a new Access Policy.
• Specify a description.
• Under selection Criteria select User has ANY of the following Attributes, and click Add.
• Under AAA Attribute Type select LDAP.
• Attribute ID: memberOf, and click Get AD Groups
• All your Active Directory groups should populate, select the VPN USERS Group, and click ok.

• Under Action make sure continue is selected, and click ok and apply.

• Navigate to Configuration –> Remote Access VPN –> IPsec Connection Profiles.
• Either create a new profile or edit an existing profile.
• Under Server Group, choose LDAP, this is the server we added earlier.

 

• Click ok and apply your configuration.
• At this point you should be able to VPN and Authenticate via Active Directory, provided you are a member of the VPN Users group.

Works well - Notes

Step 1. Verify that the Date, Time, and Time Zone Values are Accurate

ASDM Procedure

1. Click Configuration, and then click Device Setup.

2. Expand System Time, and choose Clock.

3. Verify that the information listed is accurate.

   The values for Date, Time, and Time Zone must be accurate in order for proper certificate validation to occur.

   

Command Line Example

ciscoasa
ciscoasa#show clock 11:02:20.244 UTC Thu Jul 19 2007 ciscoasa#

Step 2. Generate a Certificate Signing Request

A certificate signing request (CSR) is required in order for the 3rd party CA to issue an identity certificate. The CSR contains your ASA's distinguished name (DN) string along with the ASA's generated public key. The ASA uses the generated private key to digitally sign the CSR.

ASDM Procedure

1. Click Configuration, and then click Device Management.

2. Expand Certificate Management, and choose Identity Certificates.

3. Click Add.

   

4. Click the Add a new identity certificate radio button.

5. For the Key Pair, click New.

   

6. Click the Enter new key pair name radio button. You should distinctly identify the key pair name for recognition purposes.

7. Click Generate Now.

   The key pair should now be created.

8. To define the Certificate Subject DN, click Select, and configure the attributes listed in this table:

   Table 4.1: DN Attributes

   Attribute	Description
   CN	FQDN (Full Qualified Domain Name) that will be used for connections to your firewall. EX: webvpn.cisco.com
   OU	Department Name
   O	Company Name (Avoid using Special Characters)
   C	Country Code (2 Letter Code without Punctuation)
   St	State (Must be spelled out completrly EX: North Carolina)
   L	City

   In order to configure these values, choose a value from the Attribute drop-down list, enter the value, and click Add.

   

   Note: Some 3rd party vendors require particular attributes to be included before an identity certificate is issued. If you are unsure of the required attributes, check with your vendor for details.

9. Once the appropriate values are added, click OK.

   The Add Identity Certificate dialog box appears with the Certificate Subject DN field populated.

10. Click Advanced.

    

11. In the FQDN field, enter the FQDN that will be used to access the device from the internet.

    This value should be same FQDN you used for the Common Name (CN).

12. Click OK, and then click Add Certificate.

    You are prompted to save the CSR to a file on your local machine.

    

13. Click Browse, choose a location in which to save the CSR, and save the file with the .txt extension.

    Note: When you save the file with a .txt extension, you can open the file with a text editor (such as Notepad) and view the PKCS#10 request.

14. Submit the saved CSR to your 3rd party vendor. Once you submit the CSR to your 3rd party vendor, they will provide you the identity certificate to be installed on the ASA.

Works well - GoDaddy / Starfield 5 year cert for $130

A lot of people use the Cisco IOS rate-limit feature. They have a real need. What they don't have is real documentation. Cisco itself hasn't produced a decent explanation of how rate-limit works. Yeah, there are some books that pretend to explain what the 'normal burst' and 'extended burst' settings do. But they STILL don't tell you how to figure them out in real life.

I'm going to tell you. And after I tell you, you're going to feel better. The network will be faster.

Why the burst settings matter?

A normal router interface is limited by the inherent speed of the wire. When incoming packets arrive faster than they can head out the interface, they are placed in the outgoing packet queue. Each interface has one, typically 40 packets in size. As packet flow reaches and surpasses the wire speed, this queue begins filling up. Those packets belong to someone -- a particular TCP connection. (We are ignoring other packet types, but that is okay.) When those packets end up in the queue, they are being delayed. This would be similar to ping times starting to rise. The TCP protocol notices this delay (because the receiving computer will take slightly longer to send back an ACKnowledgement packet), and the flow slows slightly. If too many packets fill the queue, they start dropping. When TCP sees dropped packets, it slows more significantly. This is how TCP works, and it works well.

What happens when you rate-limit instead of letting an interface reach line-speed?

When you rate-limit, the outgoing packet queue never comes in to play. When the rate-limit sees a flow exceeding the limit, it simply drops a packet. There is no outgoing queue to slow the packet momentarily. This is why there are two settings: the normal burst size, and the extended burst size. The size of the burst is essentially telling the router how tightly you want to apply the rate-limit. Too loose, and flows may momentarily exceed the limit by an undesirable amount. (What constitutes undesirable is completely up to you; some folks are using rate-limit to sell bandwidth, and others are using it to keep a line from ever reaching saturation and hence keep latency down.) When the extended burst is exceeded, ALL packets are dropped until the flow comes back under the limit. That will happen from time to time, but it is bad for consistent performance. The normal burst drop can occur many times as the flow oscillates around the rate-limit. The smaller the normal burst is, the more drops it can accomplish, which is good in moderation, bad when overdone. A good rate-limit can actually improve performance under heavy load versus no rate-limit. But a bad rate-limit screws up everything.

Too tight

Usually, the burst settings end up too tight. When they are set too tight, three things may happen: 1) The combined traffic flows will have trouble reaching the limit. 2) TCP flows will be jerky, resulting in un-smooth web page loading or wildly fluctuating download speeds. 3) A single TCP flow (ie a speed test) will NEVER get close to the limit. (Insufficient TCP Window size on server or client can also cause this)

Burst settings end up set too low because people are concerned that setting them higher is going to cause the rate-limit to be too loose. This isn't true; for every byte sent above the rate-limit, a byte must not be sent (or worse, dropped!) below the rate-limit. So don't be too tight with burst!

Just right

Cisco IOS reference manuals (certain editions, at least) say that normal burst should be (RATE-SPEED/8 * 1.5), and that extended burst should be double the normal burst. These suggested settings are great for smooth TCP, but they are sometimes too loose.

I'm a tightwad; what's the lowest burst I should use?

There is one more variable you should know in order to figure this out: The typical or highest-typical ping time. If you are in the US, accessing primarily US sites, a ping-time of 150ms is probably a safe tight-wad number.

So here is your formula for normal burst: (RATE-SPEED/8 / 20)

The formula for extended burst: NormalBurst + (RATE-SPEED/8 * 0.150)

Using an example of 20Mbps, your rate limit would be:

rate-limit out 20000000 125000 500000 conform-action transmit exceed-action drop

Cisco says extended burst should be double the normal burst, but that assumes you are also using their formula for normal burst. I don't assume that you are, which is why I specify extended burst as an amount that should be added to normal burst. In this way, you can use very small normal burst values, and still know what your extended burst should be in order to ensure smooth TCP performance.

Why is that the lowest?

150ms is your round-trip time (RTT). That is how long it takes a packet to be sent, and the acknowledgement to be received. Once a flow reaches this speed, and exceeds for a burst of the size/duration for one twentieth of a second, a packet will be dropped. The extended burst is the normal burst, plus the total bytes that can be transferred in the RTT. That is how long it takes TCP to notice that a packet was dropped and was never acknowledged. So, when you set the parameters thus, you are giving TCP enough time to "take the hint" of a single dropped packet before it gets the major punishment of all packets being dropped.

If you don't like these burst settings, and they are causing the flow to exceed the rate-limit too much or too often, I would suggest that it is NOT the burst sizes that you want to reduce, but the rate-limit speed itself. Knock it down a percent or two and see if that helps you out.

Oh, so you want to push the envelope, and want to have even lower settings? Well, in that case, you could use 24000 for the normal, and 399000 for the extended. The important thing is that you've still got one RTT between the first packet drop and the complete packet drop. You may not get full speed at this level, but it will be smooth. The potential harm is that with only a 24000 burst, the router is looking too closely at the flow. In our 20Mbps example, 24000 bytes is only one-hundredth of the per second speed of the flow. When you measure the flow this tightly, the rate limit will end up being applied too often, when the overall speed is actually not in excess of the rate-limit. For instance, a web browser that suddenly opens a bunch of connections as a page is loaded could (although statistically unlikely) cause a 24,000 byte burst as that handful of connections are opened and their first 2 or 3 packets are sent without waiting for acknowledgement. Use your judgment. If your judgment sucks, use bigger numbers for the burst, and smaller numbers for the speed.

An exception: These rules don't apply on high speed links with hundreds of TCP (or other) connections. If the router starts to drop all packets, the randomness works in your favor. It is likely that every packet dropped is part of a different TCP connection than every other packet dropped. No single download through this link should expect to use more than 2% of the link capacity in order for this to apply. In this case, the extended burst value can approach the normal burst value without impeding TCP performance.

 

Good explanation - Notes

When patents attack Android

8/03/2011 12:37:00 PM

I have worked in the tech sector for over two decades. Microsoft and Apple have always been at each other’s throats, so when they get into bed together you have to start wondering what's going on. Here is what’s happening:

Android is on fire. More than 550,000 Android devices are activated every day, through a network of 39 manufacturers and 231 carriers. Android and other platforms are competing hard against each other, and that’s yielding cool new devices and amazing mobile apps for consumers.

But Android’s success has yielded something else: a hostile, organized campaign against Android by Microsoft, Oracle, Apple and other companies, waged through bogus patents.

They’re doing this by banding together to acquire Novell’s old patents (the “CPTN” group including Microsoft and Apple) and Nortel’s old patents (the “Rockstar” group including Microsoft and Apple), to make sure Google didn’t get them; seeking $15 licensing fees for every Android device; attempting to make it more expensive for phone manufacturers to license Android (which we provide free of charge) than Windows Phone 7; and even suing Barnes & Noble, HTC, Motorola, and Samsung. Patents were meant to encourage innovation, but lately they are being used as a weapon to stop it.

A smartphone might involve as many as 250,000 (largely questionable) patent claims, and our competitors want to impose a “tax” for these dubious patents that makes Android devices more expensive for consumers. They want to make it harder for manufacturers to sell Android devices. Instead of competing by building new features or devices, they are fighting through litigation.

This anti-competitive strategy is also escalating the cost of patents way beyond what they’re really worth. The winning $4.5 billion for Nortel’s patent portfolio was nearly five times larger than the pre-auction estimate of $1 billion. Fortunately, the law frowns on the accumulation of dubious patents for anti-competitive means — which means these deals are likely to draw regulatory scrutiny, and this patent bubble will pop.

We’re not naive; technology is a tough and ever-changing industry and we work very hard to stay focused on our own business and make better products. But in this instance we thought it was important to speak out and make it clear that we’re determined to preserve Android as a competitive choice for consumers, by stopping those who are trying to strangle it.

We’re looking intensely at a number of ways to do that. We’re encouraged that the Department of Justice forced the group I mentioned earlier to license the former Novell patents on fair terms, and that it’s looking into whether Microsoft and Apple acquired the Nortel patents for anti-competitive means. We’re also looking at other ways to reduce the anti-competitive threats against Android by strengthening our own patent portfolio. Unless we act, consumers could face rising costs for Android devices — and fewer choices for their next phone.

UPDATE August 4, 2011 - 12:25pm PT

It's not surprising that Microsoft would want to divert attention by pushing a false "gotcha!" while failing to address the substance of the issues we raised. If you think about it, it's obvious why we turned down Microsoft’s offer. Microsoft's objective has been to keep from Google and Android device-makers any patents that might be used to defend against their attacks. A joint acquisition of the Novell patents that gave all parties a license would have eliminated any protection these patents could offer to Android against attacks from Microsoft and its bidding partners. Making sure that we would be unable to assert these patents to defend Android — and having us pay for the privilege — must have seemed like an ingenious strategy to them. We didn't fall for it.

Ultimately, the U.S. Department of Justice intervened, forcing Microsoft to sell the patents it bought and demanding that the winning group (Microsoft, Oracle, Apple, EMC) give a license to the open-source community, changes the DoJ said were “necessary to protect competition and innovation in the open source software community.” This only reaffirms our point: Our competitors are waging a patent war on Android and working together to keep us from getting patents that would help balance the scales.

Posted by David Drummond, Senior Vice President and Chief Legal Officer

Follow this folks - its rare to see!