AVG 8.0 will be fully supported in NAC 4.1.6

Currently NAC only supports installation checks for the paid version of AVG 8.0. The free version and definition file checks will be supported in version 4.1.6. From what I've been told, this version should be coming out sometime in July.

Resetting NAC Manager database

I've been writing some NAC labs and I wanted to figure out the best way to clear out the database and start from scratch. I found the instructions in the /perfigo/dbscripts/README file on the NAC Manager. Here are the relevant commands to clear out the database and start from scratch

To remove perfigo database issue:
-----------------------------
su -l postgres -c "psql -h 127.0.0.1 -p 5432 controlsmartdb < /perfigo/dbscripts/pg_droptable.sql"
su -l postgres -c "dropdb -h 127.0.0.1 -p 5432 controlsmartdb"
To install perfigo database issue:
-----------------------------
su -l postgres -c "createdb -h 127.0.0.1 -p 5432 controlsmartdb"
su -l postgres -c "psql -h 127.0.0.1 -p 5432 controlsmartdb < /perfigo/dbscripts/pg_createtable.sql"

*Note: Running the commands will remove the license file as well, so make sure you have the NAC Manager and Server license files before running the commands

Solution to slow CAM login

I just saw this in the 4.1(1) release notes. It's resolved caveat CSCsi23228. I haven't had to use it but it may be useful someday if I run into slow CAM login time
http://www.cisco.com/en/US/docs/security/nac/appliance/release_notes/411/411rn.html

CAM database performance degraded over time

Clean Access Manager performance degrades over time, users may experience slowness during login process and CAM web administration interfaces. The slowness may start to exhibit itself after an extensive number of database delete/insert/modify operations.

There are three workarounds for this issue which can be applied under different conditions.

Workaround 1

This can be applied during maintenance window when CAM is not in service. Note that this may take up several minutes, please do not interrupt the process.

1. service perfigo stop
2. su -l postgres
3. vacuumdb -h 127.0.0.1 -a -f
4. exit
5. service postgresql restart
6. service perfigo start

Workaround 2

This can be applied when system is in service with light load. Note that this may take up several minutes, please do not interrupt the process.
1. su -l postgres
2. vacuumdb -h 127.0.0.1 -a -f
3. exit

Workaround 3: This can be added as system daily cron job to prevent the potential slowness.

1. Create a file named "db_vacuum.sh" under "/etc/cron.daily" with the following content:
#!/bin/sh
su - postgres -c "vacuumdb -h 127.0.0.1 -a -f"
2. cd /etc/cron.daily
3. chmod +x db_vacuum.sh

DMVPN with NAT

It looks like Cisco has been fixing NAT issues with DMVPN. They fixed the NAT issue for spokes talking to the hub using NAT traversal. This is the same method that VPN clients use. It uses UDP port 4500 to send the IPSec traffic instead of IP protocol 50 (ESP) and IP protocol 51 (AH). Here's a link with more explanation.
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/dmvpn_dt_spokes_b_nat.html

In versions after 12.4(6)T, the spoke-to-spoke traffic with NAT is supported. Take a look at this link for more information.
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftgreips.html#wp1039515

Here's the important information from the link

In Cisco IOS Release 12.4(6)T or earlier, DMVPN spokes behind NAT will not participate in dynamic direct spoke-to-spoke tunnels. Any traffic to or from a spoke that is behind NAT will be forwarded using the DMVPN hub routers. DMVPN spokes that are not behind NAT in the same DMVPN network may create dynamic direct spoke-to-spoke tunnels between each other.

In Cisco IOS Release 12.4(6)T or later releases, DMVPN spokes behind NAT will participate in dynamic direct spoke-to-spoke tunnels. The spokes must be behind NAT boxes that are preforming NAT, not PAT. The NAT box must translate the spoke to the same outside NAT IP address for the spoke-spoke connections as the NAT box does for the spoke-hub connection. If there is more than one DMVPN spoke behind the same NAT box, then the NAT box must translate the DMVPN spokes to different outside NAT IP addresses. It is also likely that you may not be able to build a direct spoke-spoke tunnel between these spokes. If a spoke-spoke tunnel fails to form, then the spoke-spoke packets will continue to be forwarded via the spoke-hub-spoke path.

I tried this out in a Dynamips lab and it worked great.

Here's a diagram of the dynagen lab I created with the relevant config

How does Cisco NAC change your DHCP IP

When implementing NAC you may wonder how it changes your IP when you move back and forth betwen the untrusted and trusted VLANs. Back in the olden days, the only way to do this was to bounce the switch port. This caused the link to go down on the connected computer which kicked off a new DHCP request. Nowadays there's a method that works better when the switch port has an IP phone and a computer on the same