First, make sure you are running ASA Software version 8.0(3) or better. The previous versions have a bug when the iPhone connects that will boot all other users connected to the VPN.

On the ASA, we need to get the VPN configured.  First, the ACLs for split-tunneling, no NAT and VPN access:

Since this config will authenticate to the local ASA, we need to have a username and password setup:

Now setup a DHCP pool for VPN clients:

Now create the crypto maps and apply them to the outside interface:

Setup ISAKMP:

Now create a remote access VPN policy. Make sure to add the split-dns value for your local domian. If you leave this out, the iPhone will not resolve DNS on the internal network!

Add the tunnel-group to allow the VPN connection:

Now to configure the iPhone. First, go to Settings -> General -> Network -> VPN. Then Add VPN Configuration. Select IPSec at the top and enter your information. The Server is the IP address or hostname of the ASA. The Account is the Username you created in the config above. The Group Name is the tunnel-group name created on the ASA.

To connect the VPN, go to Settings -> VPN (this appears after you create a VPN connection).  Just change the option to ON.

Once you see the VPN icon on the top bar, you are connected!

Apparently, this is a new security feature for the 7.0+ code for the ASA. Normally, the client and server send their MSS (Maximum Segment Size) while establishing the TCP connection. Once this occurs, neither the client or server should send a packet larger than their peer’s MSS. However, some HTTP servers do not recognize the MSS and send packets that are too large, and are thus dropped by the ASA.

The workaround for this is to allow the firewall to pass the packets whose data exceeds the MSS. Let’s say the server causing the problems ip is 192.168.10.9. First, create and access-list for any host accessing that server.

And then create a class map.

Create the policy map.

Apply the map to the outside interface.

If there is more than one site, just add the additional sites to the MSS_Exceeded_ACL access list or change it to allow all sites.

For more information about MSS and logging these events, check out the document from Cisco.

And then configure SSH to be allowed from the inside interface:

Now you will be able to login using the default username and password of pix/cisco, Or you can configure AAA and setup your own usernames. Doing this will make the pix username no longer work for SSH.

First, a username needs to be created:

And then configure AAA:

Done!

And then specified to not perform NAT:

I then needed to add another line to the InsideNoNAT_ACL, and that is where I received the error.

All this error message is saying is that the new line in the access-list was not added to the active NAT table, but was added to the access-list. Upon doing some searching, I read in several places that a reboot fixed the problem. While this is true, it is not necessary. All that needs to be done is to remove and reapply the nat statement.

This rebuilds the NAT rules and applies all rules in the ACL. Much better than a reload!

Then apply the access-list to the outside interface.

This will allow only ping. If you would like to allow trace route, you will also need to allow time-exceeded.

Solution 2: Use access-list to allow ping and trace route from the internet to your dmz/inside servers.
To do this, we are going to build off of what we did above, so you should already have this in the config.

Now all we need to do is allow echo into the network.

Even though we are allowing icmp, we still need to have a static mapping to allow the packets to reach the DMZ.

Of course, you will need to have a static mapping for every server you want to have reachable from the internet.

Solution 3: This is a bit more complex, but will allow higher security level interfaces to ping/trace route lower security level interfaces without the use of access-lists. To do this, we will tell the ASA to inspect icmp in a service policy. If you are using a ASA, you should have a default policy in the base config called global_policy.

global_policy:

To add icmp inspection.

We first need to set the ports we want to use to be a trunk. Here we are forcing dot1q.

Now we need to setup the port channels. These channels will be used as 1 and aggregate bandwidth between them.

Note: There is an option at the end of this command to specify the admin group. This is how the CatOS groups the ports. If you do not specify the admin group, the CatOS will automatically assign one. This is something to watch out for if you set each port separately.

Now, turn the port channel on.

That is it for the CatOS. The config for the IOS is quite a bit different. First, create a port channel interface and make it a trunk.

Assign ports to the port channel group.

Just connect the ports and everything should come up. To check on the CatOS.

Here, both ports 3/9 and 3/10 show as connected and on the same admin channel.

And for the IOS.

The last line is the important one. Notice that is shows both ports are in port channel 1.

To configure and IOS to IOS etherchannel, just repeat the exact steps for the IOS on the second switch.
That’s all there is to it.

The very first step to complete as soon as you are ready to put a new switch on a network and join it to the domain, is to make sure that the vtp mode is set to transparent. Setting the mode to transparent ensures that the “Configuration Revision” is set to 0. If the switch has been used in a lab and has vlans configured and a configuration revision that is higher than the domain server, even if the switch being added is in client mode, it will overwrite the server and propagate all of it’s vlans across the network.

This is directly taken from Cisco’s website:

A recently added switch can cause problems in the network. It can be a switch that was previously used in the lab, and a good VTP domain name was entered. The switch was configured as a VTP client and was connected to the rest of the network. Then, you brought the trunk link up to the rest of the network. In just a few seconds, the whole network can go down.

If the configuration revision number of the switch that you inserted is higher than the configuration revision number of the VTP domain, it propagates its VLAN database through the VTP domain.

This occurs whether the switch is a VTP client or a VTP server. A VTP client can erase VLAN information on a VTP server. You can tell this has occurred when many of the ports in your network go into the Inactive state but continue to assign to a nonexistent VLAN.

To make sure this does not happen, before you connect the switch to the network, make sure to set the vtp mode to transparent.

Now that this switch won’t overwrite the server, configure the vtp domain and password, and then change the mode to client.

Show the vtp status to confirm.

And then a show vlan and check the output to make sure all the vlans have propagated.

The only rule you really need when adding switches is to make sure the switch is in TRANSPARENT mode first.

The first requirement is to make sure that your trunks between switches are up and working.

And the output should look something like:

If there are not any ports listed as a trunk, that needs to be fixed before proceeding. Now that we know the switches are communicating, we can proceed to look at the current vtp configuration.

And you should get:

If the VTP Operating Mode is not “Transparent” on all of the switches, it needs to be set to transparent to prevent problems later.

This will reset the Configuration Revision to 0. It is very important that all switches have the configuration revision reset!

Now, on the switch that you want to be the vtp server; set the domain, password, and then change it to server mode.

Make sure all of the vlans that you need are on this switch. Once they are, setup the other switches as clients.

Check the VTP status on the client to confirm the vtp status has changed and the vlans have been configured.

Everything is now configured. Vlan additions can now be made on the switch that is in server mode and they will be propagated down to all of the clients.

Adding a switch to an already established vtp domain is basically the same, just make sure to set the switch to transparent mode first. For more details, check Adding a Cisco switch to a vtp domain.

Come to find out, Microsoft deprecated MSCHAP v1 from Vista! Vista only supports MSCHAP v2, CHAP, and PAP. Cisco does not support MSCHAP v2 in the 6.x line of software for the PIX. Unfortunately, I was connecting to a Pix 501 and did not have the option to upgrade to version 7.x software which does support MSCHAP v2.

Since the only option left is to use CHAP, I had reconfigured the VPN connection in Vista. To do this:

Go to Properties of the VPN connection

-> Security Tab

-> Select Advanced (custom settings)

-> Click Settings

-> Set Data encryption to optional

-> Then check CHAP under Allow these protocols

Now I am able to connect without any problems.

Please note that CHAP should not be considered secure. While it is better than PAP in that is uses encryption, it is only one-way and therefore should be used with caution.

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml