Wireless AP 1142 - Convert to controller based or standalone mode

If you are faced with the task of installing 1100 series APs into a controller environment but somehow "standalone" APs were procured, don't panic! Here is the fix:

1. Note the AP's IP address by "show cdp neigh detail"
2. http:// to the address to manage (Cisco/Cisco... case sensitive ID and pass!)
3. Go to the software tab and update to the correct image

If your controller is a hop or two or more away, don't forget to adjust DHCP option 43 and option 60 values!

Cisco 2600 AP - Convert to Stand-Alone mode

Follow these simple steps:

1. Download the stand-alone image from Cisco.com (.tar)
2. Rename the file to ...tar.default
3. Make sure you have a console connection to the 2600 AP - this will you verify the name of the file the AP expects to boot from using TFTP.
4. Change your IP address to 10.0.0.2 /8
5. Run a TFTP  server on your laptop or PC
6. Plug the AP and your PC into two ports a switch that are in the same VLAN (no layer3 SVI necessary, I recommend creating a temporary VLAN such as 99 for example)
7. Make sure that the AP is connected to a PoE port if you don't have a power brick, BUT before you do that, press the MODE button and hold it down as the AP boots!!
8. Watch the console messages for the correct filename - ...tar.default should match exactly.
9. AP's LED will go blue and then after 15 seconds will go RED - you can let go of the MODE button now!
10. AP LED will blink green and it will intialize in stand-alone mode, and obtain a DHCP address.
11. You can manage it using http://

Cisco ASA: "LAND" attack - track false positves

A LAND attack is characterized by an IP packet whose source and destination IP addresses are the same. HOwever, sometimes on the ASA platform, it is possible to see false postives.


Consider the following example:

Jan 05 2012 16:21:36: %ASA-2-106017: Deny IP due to Land Attack from 192.168.2.71 to 192.168.2.71

Jan 05 2012 16:21:37: %ASA-2-106017: Deny IP due to Land Attack from 192.168.2.71 to 192.168.2.71

What is really happening?

Upon closer examination, you notice that you have static tranlation setup:

static (inside, outside) 192.168.2.71 172.16.2.71

Now let's capture traffic b/w the private address and translated IP, and lo and behold, the mystery is solved! The server inside is trying to access "itself via its public IP address" (perhaps via a script that is running).

3 packets captured

1: 16:20:37.032469 172.16.2.71.58126 > 192.168.2.71.80: S 1304500266:1304500266(0) win 5840

2: 16:21:36.938168 172.16.2.71.58128 > 192.168.2.71.80: S 4035860468:4035860468(0) win 5840

3: 16:21:37.173559 172.16.2.71.58129 > 192.168.2.71.80: S 4123968769:4123968769(0) win 5840

3 packets shown   Notice how the time-stamps match!

Load balancing across two ISPs with ASA

Ah! You are the security engineer at a medium sized bank, and perhaps you want to expand your Internet access to include a 2nd ISP. You are already paying $$ for the 10Mbps and now you are going to cough up even more $$$ for the new 25 Mbps service. Your websites and email servers are well set, and they are using static translations on the first ISP public address. How can you bring the 2nd ISP online, load-balance traffic across both links but preserve what you have built thus far?


You configure a select set of static routes (with SLA tracking if necessary) and this forces some outbound traffic off to the new link:

route outside-new 128.0.0.0 255.0.0.0 x.x.x.x

Just select a few more of your favorite Internet targets.  You can enable the SLA tracking feature to add an element of dynamism!

and so on...


But, you notice that connections for the outside are not completing. You setup "logging console notifications" and observe uRPF drops! Now that's easy to explain: traffic to your static translations will come in via the old circuit but new more specific routes break uRPF on the ASA. The solutions is to check and disable "ip verify reverse-path" and Voila! you are back in business!

ERSPAN with Nexus 1000V

The value of ERSPAN cannot be overstated!  It provides the much needed visibility into virtualized environments that are rapidly becoming the de facto server paradigm these days.

Encapsulated remote span work by tunnelling packets to a remote analyzer platform such as the Network Analysis Module (in this case its a NAM blade in a Catalyst 6500).

The key to picking up copies of traffic from inside the virtual world is the "l3-control" capability in a Nexus 1000V port-profile as seen here:

port-profile type vethernet esx_300
  capability l3control  vmware port-group
  switchport mode access
  switchport access vlan 300
  no shutdown
  system vlan 300
  state enabled
And notice that it appears in the "system-uplink" profile:

port-profile type ethernet system-uplink
  vmware port-group
  switchport mode trunk
  switchport trunk allowed vlan 300-304
  pinning control-vlan 0
  pinning packet-vlan 0
  mtu 9000
  channel-group auto mode on mac-pinning
  no shutdown
  system vlan 300,303
  state enabled
Next, we costruct the ERSPAN session as follows:

monitor session 64 type erspan-source
  description n1K_ERSPAN_example
  source vlan 300,304 both
  destination ip 172.31.255.254
  erspan-id 700
  ip ttl 64
  ip prec 0
  ip dscp 0
  mtu 1500
  header-type 2
  no shut
We selected an ERSPAN id of 700 which helps identify the session on the remote NAM platform.

Assuming that IP routing is active, the ERSPAN session will show up automatically on the NAM under "data sources".  You will be able to specify filters and analyze traffic from any VLAN that the Nexus 1000V controls within the virtual world.  Here we are using VLAN 304 as an example.

Private VLANs de-constructed in 50 words!

Private VLANs can be de-constructed into 3 types of ports

"P" ports

"C" ports

"I" ports

Promiscuous "P" ports - no restrictions

Community "C" ports can talk to other "C" ports in same community, and to "P" ports

Isolated "I" ports can only talk to "P" ports

Phone Proxy with ASA 8.2

ASA 8.2 Phone Proxy feature allows the security appliance to proxy Certificate Authority function on behalf of the CUCM.  This allows phones registering from the outside to contact the ASA which then proxies the connection to the CUCM.  The “media termination point” feature, along with the ‘Certificate Trust List’ CTL on the ASA ensures that media streams are encrypted (SRTP).

Due to the fact that the “Phone Proxy” ASA is separate from the “Internet ASA” at Securiosity Companies, “outside NAT” had to be implemented to ensure that Phone-to-CUCM” traffic was not asymmetrically routed.  Please review the configuration on the ASA (contained in this document) for specific details of this solution.

We have also modified a service policy to inspect SIP, and the policy is attached to the “outside” interface.

The only ACL entry relaxed here is TFTP traffic to the CUCM’s translated address on the “outside” address of the ASA.



Trustpoint for MIC (7941 and 7961 phones)

crypto ca trustpoint CAP-RTP-001_trustpoint

 enrollment terminal

 crl configure

crypto ca trustpoint CAP-RTP-002_trustpoint

 enrollment terminal

 crl configure

crypto ca trustpoint Cisco_Manufacturing_CA_trustpoint

 enrollment terminal

 crl configure



Phone-Proxy configuration

tls-proxy ASA-tls-proxy

 server trust-point _internal_PP_ctl_phoneproxy_file

!

ctl-file ctl_phoneproxy_file

 record-entry cucm-tftp trustpoint phoneproxy_trustpoint address 192.168.2.227

! the following entry is optional (for use with CAPF w/ LSC only phones

 record-entry capf trustpoint capf_trustpoint address 192.168.2.227

 no shutdown

!

media-termination mymta

 address 208.87.143.229 interface outside

 address 172.18.0.182 interface inside

!

phone-proxy ASA-phone-proxy

 media-termination mymta

 tftp-server address 172.18.2.26 interface inside

 tls-proxy ASA-tls-proxy

 ctl-file ctl_phoneproxy_file

 no disable service-settings



FW basic configuration (ACLs and NAT)

! public address of TFTP server

static (inside,outside) 192.168.2.227 172.18.2.26 netmask 255.255.255.255

!

! the only ACL entry required

access-list list outside permit tcp any host 192.168.2.227 eq tftp

!

object-group type service CUCM-PROXY-PORTS

 service-object tcp 2443

 service-object tcp 5061

 service-object tcp 3804

 service-object udp tftp

 service-object udp range 1024 65535

!

access-list phone-proxy-traffic permit object-group CUCM-PROXY-PORTS any host 192.168.2.227 

!

! Outside NAT forces return traffic from CUCM to go through ASA-PP

! Without this traffic from CUCM will take natural 0’s route to Internet causing asymmetrical behavior

nat (outside) 555 access-list phone-proxy-traffic outside

global(inside) 555 interface

!

class-map sec_sip

 match port tcp eq 5061

class-map sec_sccp

 match port tcp eq 2443

!

!

policy-map voice_policy

 class sec_sccp

  inspect skinny phone-proxy ASA-phone-proxy 

 class sec_sip

  inspect sip phone-proxy ASA-phone-proxy 

!

service-policy voice_policy interface outside