Booches.nl

Cisco Aironet: multiple SSID’s

I have been playing with some Cisco Aironet’s today. Configuration is quite simple and straightforward, but maybe not for everyone:

• Broadcast two SSID’s, unsecure and secure
• Authentication via WPA version 2 pre-shared key
• Management IP adres in management VLAN

You are maybe thinking: “stand-alone access points, why no WLAN controller?” I agree, but be honest. Would you use a WLAN controller for less then 5 access points?

The snippet below shows the most important configuration for such a scenario.

dot11 mbssid
dot11 vlan-name secure vlan 11
dot11 vlan-name default vlan 1
dot11 vlan-name unsecure vlan 13
dot11 vlan-name management vlan 10
!
dot11 ssid unsecure
vlan 13
authentication open
authentication key-management wpa version 2
mbssid guest-mode
wpa-psk ascii <wpa pre-shared key>
!
dot11 ssid secure
vlan 11
authentication open
authentication key-management wpa version 2
mbssid guest-mode
wpa-psk ascii <wpa pre-shared key>
!
bridge irb
!
interface Dot11Radio0
no ip address
no ip route-cache
!
encryption vlan 13 mode ciphers aes-ccm tkip
!
encryption mode ciphers aes-ccm tkip
!
encryption vlan 11 mode ciphers aes-ccm tkip
!
ssid unsecure
!
ssid secure
!
speed  basic-1.0 basic-11.0 basic-54.0
channel 2412
station-role root
!
interface Dot11Radio0.11
encapsulation dot1Q 11
no ip unreachables
no ip proxy-arp
no ip route-cache
no cdp enable
bridge-group 11
bridge-group 11 block-unknown-source
no bridge-group 11 source-learning
no bridge-group 11 unicast-flooding
bridge-group 11 spanning-disabled
!
interface Dot11Radio0.13
encapsulation dot1Q 13
ip access-group internet-only in
no ip unreachables
no ip proxy-arp
no ip route-cache
no cdp enable
bridge-group 13
bridge-group 13 subscriber-loop-control
bridge-group 13 block-unknown-source
no bridge-group 13 source-learning
no bridge-group 13 unicast-flooding
bridge-group 13 spanning-disabled
!
interface FastEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
!
interface FastEthernet0.10
encapsulation dot1Q 10 native
no ip unreachables
no ip route-cache
no cdp enable
bridge-group 10
no bridge-group 10 source-learning
bridge-group 10 spanning-disabled
!
interface FastEthernet0.11
encapsulation dot1Q 11
no ip unreachables
no ip route-cache
no cdp enable
bridge-group 11
no bridge-group 11 source-learning
bridge-group 11 spanning-disabled
!
interface FastEthernet0.13
encapsulation dot1Q 13
no ip unreachables
no ip route-cache
no cdp enable
bridge-group 13
no bridge-group 13 source-learning
bridge-group 13 spanning-disabled
!
interface BVI10
ip address 10.1.1.200 255.255.255.0
no ip route-cache
!
ip default-gateway 10.1.1.1
!
bridge 1 route ip

I hope this helps when you are configuring a Cisco Aironet with multiple SSID support.

Upgrade CS MARS

A customer was running CS MARS with version 4.3.6. Lately the Cisco IPS sensor was upgraded to version 7.x. This version wasn’t supported anymore by CS MARS version 4.3.6. That is why the CS MARS needed to be upgraded to 6.x. I don’t have a lot of experience with CS MARS and I couldn’t find a way to upgrade from 4.3.6 to 6.x.

The only way to upgrade from 4.3.6 to 6.x is by re-imaging the server. At first I started with securing the current configuration. The current configuration can be saved to a NFS server. I secured the current configuration and event data with the following commands:

[pnadmin]$ pnexp
pnexp > export config 10.1.1.1:/home/NFS
pnexp > export data 10.1.1.1:/home/NFS

The next question I had was: which CS MARS version to download? Searching the documentation I only found a upgrade procedure for upgrade 4.3.6 to 6.0.1. The latest version is version 6.0.5, but I couldn’t find any documentation about upgrading directly from 4.3.6 to version 6.0.5. I decided to upgrade from 4.3.6 to 6.0.1 and then directly to 6.0.5.

Re-imaging the server took about an hour. The installation process didn’t take a lot of time, most of the time was spend on the process of creating an oracle database. After re-imaging I had to import the configuration from the NFS server.

Hmmm…. the server has a fresh installation, so no IP address or whatsoever. First I had to find the default username and password to login to CS MARS. The default username and password is pnadmin. I configured an IP address using the following command:

[pnadmin]$ ifconfig eth0 10.1.1.2 255.255.255.0

Next I was able to access CS MARS through SSH. I imported the configuration and the event data using the following commands:

[pnadmin]$ pnimp
pnimp > import config 10.1.1.1:/home/NFS
pnimp > import data 10.1.1.1:/home/NFS

The complete configuration, including hostname, dns servers and license, and the event data was nicely restored. Next I wanted to upgrade from version 6.0.1 to directly version 6.0.5. Stunned I was at that moment, I discovered that the different upgrades need to be installed sequentially. The different upgrades have multiple dependencies amongst each other. It is possible to install the upgrade packages through the web interface, but I got some dependency failures during this process.

The only way for me, and I think the best way, was installing the upgrades packages through a SSH session. I let the CS MARS download the required packages directly from the Cisco website by using valid CCO credentials. The first step involved checking which upgrade packages were available using the following command:

[pnadmin]$ pnupgrade
CSMARS Upgrade………..[25541]
——————————————————————————–
Package Name Type Version URL
——————————————————————————–
csmars-6.0.5.3358.zip BD 6.0.5.3358.34 http://software-sj.cisco.com/cisco/crypto/3DES/ciscosecure/cs-mars/csmars-6.0.5.3358.zip
csmars-6.0.4.3229.zip BD 6.0.4.3229.33 http://software-sj.cisco.com/cisco/crypto/3DES/ciscosecure/cs-mars/csmars-6.0.4.3229.zip
csmars-6.0.3.3190-customer-patch.zip B 6.0.3.3190 http://software-sj.cisco.com/cisco/crypto/3DES/ciscosecure/cs-mars/csmars-6.0.3.3190-customer-patch.zip
csmars-6.0.3.3188.zip BD 6.0.3.3188.32 http://software-sj.cisco.com/cisco/crypto/3DES/ciscosecure/cs-mars/csmars-6.0.3.3188.zip
csmars-6.0.2.3102.zip BD 6.0.2.3102.31 http://software-sj.cisco.com/cisco/crypto/3DES/ciscosecure/cs-mars/csmars-6.0.2.3102.zip

The above upgrade packages are available. The packages need to be installed sequentially, so I started with version 6.0.2.3102.31 using the following command:

[pnadmin]$ pnupgrade -d -u <CCO username>:<CCO password> <upgrade package URL>

CS MARS starts downloading the specific upgrade package. The –d parameter tell CS MARS to ask first before installing the upgrade package, because a reboot is required after the installation. I repeated this step for all subsequent upgrade packages.

Now CS MARS is running version 6.0.5 (3358) 34 and the IPS can be added to CS MARS. It took some time, but I am still curious if I could re-image the server directly to version 6.0.5.

802.1Q between Catalyst 3750 en PowerConnect 6226

Configuring a 802.1Q connection isn’t that difficult, but you need to know the command line interface and the appropriate commands. Today I configured a 802.1Q connection between a Cisco Catalyst 3750G and a Dell PowerConnect 6226, while configuring I played a little with the trunking options on the PowerConnect and I noticed the following:

• The Dell PowerConnect 6226 doesn’t support the configuration of a native vlan in switchport mode trunk

To solve this problem you should use the switchport mode general commands. I configured the 802.1Q connection on the Dell PowerConnect 6226 with the following commands:

interface ethernet 1/g24
description ’802.1Q C3750G’
switchport mode general
switchport general pvid 10
no switchport general acceptable-frame-type tagged-only
switchport general allowed vlan remove 1
switchport general allowed vlan add 10 untagged
switchport general allowed vlan add 255 tagged
switchport general allowed vlan add 1128 tagged
switchport general allowed vlan add 1129 tagged
exit

The command no switchport general acceptable-frame-type tagged-only prevents the switch from discarding untagged frames at ingress. I configured the Cisco Catalyst 3750 with the following commands:

interface GigabitEthernet1/0/4
description 802.1Q DELL POWERCONNECT 6226
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 10,255,1128,1129
switchport mode trunk
switchport nonegotiate
no ip address
no mdix auto
end

The above configuration is working perfectly. Packets from VLAN 10 are sent untagged over the link and all other VLAN’s are sent tagged over the link. I guess it would be easier if the switch supported the configuration of a native VLAN in trunking mode.

Policy NAT on Cisco router

A colleague of mine had to implement an IPSec VPN tunnel from a customer to a supplier. The customer has a Cisco router for connecting to the Internet, so nothing special. The router is already setup and in production. Configuring an extra IPSec VPN tunnel isn’t very hard, the most important part is the negotiation of Phase 1 and Phase 2 credentials for the IPSec VPN connection.

This particular situation was different, because the customer has to NAT his local IP addresses into the VPN tunnel. I don’t actual configure this quiet often on routers, but more on firewalls. I setup a testing environment with GNS3 to do my own configuration.

The testing environment is displayed below. When connecting from the LAN from R1 (10.1.1.0/24) to the Internet normal NAT overload in configured. In the picture the network behind R3 represents the Internet. When connecting from R1 to R2, the source IP address (Inside Local) is translated to an address from the pool 10.22.44.0/24 (Inside Global). There is also a static NAT mapping for IP address 10.1.1.222 into the VPN tunnel (10.22.44.222).

At first I configured the environment like showed above. I configured the different interfaces and the corresponding IP addresses. Router R1 and R2 use router R3 as default gateway. The configuration of the specific routers is attached at the end of the post.

The first snippet shows the necessary NAT configuration on R1 for the Internet connection.

interface Loopback0
description INSIDE
ip address 10.1.1.1 255.255.255.0
ip nat inside
!
interface FastEthernet0/0

description OUTSIDE
ip address 212.123.212.9 255.255.255.248
ip nat outside
duplex auto
speed auto

!
ip nat inside source list ACL-NAT interface FastEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 212.123.212.11
!
ip access-list extended ACL-NAT
permit ip 10.1.1.0 0.0.0.255 any

When trying to ping Lo0 on router R3, I see the following NAT table on router R1.

R1#ping 192.168.3.1 source 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 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/46/76 ms
R1#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:3   10.1.1.1:3         192.168.3.1:3      192.168.3.1:3

This proves that regular NAT overloading works perfectly with the current configuration. Next I configured the Policy IPSec VPN between routers R1 and R2. The configuration isn’t that spectacular, you should pay attention to the NAT statements and ACL statements. I even configured reverse route injection for the LAN network of R2. When enabling reverse route injection a route with the remote network (172.16.2.0) pops up in the routing table. This feature can be used when redistributing static routes into a routing protocol like EIGRP.

Next I will show some snippets, with some comments, of the configuration of router R1.

\\ Specifying the Phase I and Phase II properties for the IPSec VPN

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key VPN@Booches address 212.123.212.10
!
crypto ipsec transform-set VPN-TS esp-aes 256 esp-sha-hmac
!
crypto map CM-VPN-R2 10 ipsec-isakmp
set peer 212.123.212.10
set transform-set VPN-TS
match address VPN-R2
reverse-route

!

\\ Loopback interface with 2 IP addresses for testing purposes

\\ Secondary IP address is used for static policy NAT testing

interface Loopback0
ip address 10.1.1.222 255.255.255.0 secondary
ip address 10.1.1.1 255.255.255.0
ip nat inside

!

\\ Outside interface with the crypto map applied to this interface
interface FastEthernet0/0
description OUTSIDE
ip address 212.123.212.9 255.255.255.248
ip nat outside
duplex auto
speed auto
crypto map CM-VPN-R2

!

ip nat translation timeout 30

\\ NAT pool for dynamic policy NATZ
ip nat pool LAN-R2 10.22.44.1 10.22.44.254 netmask 255.255.255.0

\\ Default NAT for regular Internet related traffic
ip nat inside source list ACL-NAT interface FastEthernet0/0 overload

\\ NAT statement for dynamic policy NAT and static policy NAT
ip nat inside source list ACL-POLICY-NAT pool LAN-R2 overload
ip nat inside source static 10.1.1.222 10.22.44.222 route-map RM-STATIC-NAT extendable

!

\\ ACL to define traffic to be NATted for regular Internet related traffic

ip access-list extended ACL-NAT
deny   ip 10.1.1.0 0.0.0.255 172.16.2.0 0.0.0.255
deny   ip 10.22.44.0 0.0.0.255 172.16.2.0 0.0.0.255
permit ip 10.1.1.0 0.0.0.255 any

\\ ACL to define traffic to be dynamic policy NATted into IPSec VPN tunnel
ip access-list extended ACL-POLICY-NAT

deny   ip host 10.1.1.222 172.16.2.0 0.0.0.255
permit ip 10.1.1.0 0.0.0.255 172.16.2.0 0.0.0.255

\\ ACL to define traffic to be static policy NATted into IPSec VPN tunnel
ip access-list extended ACL-STATIC-POLICY-NAT
permit ip host 10.1.1.222 172.16.2.0 0.0.0.255

\\ ACL to define interesting traffic for the IPSec VPN tunnel
ip access-list extended VPN-R2
permit ip 10.22.44.0 0.0.0.255 172.16.2.0 0.0.0.255
!

\\ Route map static to configure static policy NAT statement
route-map RM-STATIC-NAT permit 10
match ip address ACL-STATIC-POLICY-NAT

I issued some ping commands and looked at the IP NAT Translations table to test the environment. The test results are displayed below.

SOURCE 10.1.1.1 (R1) – DESTINATION 172.16.2.1 (R2) & 212.123.212 (R3)

R1#ping 172.16.2.1 source 10.1.1.1
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/52/120 ms
R1#ping 212.123.212.11 source 10.1.1.1
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/48/84 ms
R1#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:29  10.1.1.1:29        212.123.212.11:29  212.123.212.11:29
icmp 10.22.44.1:28     10.1.1.1:28        172.16.2.1:28      172.16.2.1:28

SOURCE 10.1.1.222 (R1) – DESTINATION 172.16.2.1 (R2) & 212.123.212 (R3)

R1#ping 172.16.2.1 source 10.1.1.222
Packet sent with a source address of 10.1.1.222
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/48/84 ms
R1#ping 192.168.3.1 source 10.1.1.222
Packet sent with a source address of 10.1.1.222
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/44/60 ms
R1#sh ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:37  10.1.1.222:37      192.168.3.1:37     192.168.3.1:37
icmp 10.22.44.222:36   10.1.1.222:36      172.16.2.1:36      172.16.2.1:36

 

SOURCE 172.16.2.1 (R2) – DESTINATION 10.22.44.222 (R1)

R2#ping 10.22.44.222 source 172.16.2.1

Packet sent with a source address of 172.16.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/53/112 ms

All ICMP testing gave positive results and policy-based NAT on the Cisco router is working perfectly.

Configurations:

• Router R1
• Router R2
• Router R3

Microsoft IAG

It has been a while since my last post, but time is short these days.

Today I had to troubleshoot a Microsoft IAG appliance. Microsoft IAG stands for Microsoft Intelligent Application Gateway. And indeed, intelligent it is. NOT. I have seen and configured multiple SSL VPN solutions like Juniper SA, Citrix Access Gateway, Citrix Secure Gateway and Cisco WebVPN. But to be honest, Microsoft IAG is the worst of all.

Microsoft IAG is installed on an appliance and is closely related to Microsoft ISA 2006, which is also installed on the server. Whenever you make some configuration changes to IAG, you have to active the new configuration inside IAG. After activating the configuration, I looked at the new ISA firewall policies and I really couldn’t believe my eyes. IAG configured ISA automatically, when activating the configuration.

A simple portal, where 2 websites and OWA are published and a network connect (SSL IP VPN), results in approximately 10 firewall policy rules in ISA. Okay, I could live with that, but I shivered while taking a closer look at the rules. It is not easy to discover what purpose a specific rule has, without looking to the different tabs while editing the rule.

Besides the crazy management of the appliance, me and a colleague had a lot of problems when testing the appliance. Currently the network connector is not supported on Windows Vista and you receive a lot of (useless) errors when using Internet Explorer 8. The logging functionality is also very basic and hard to find. I had problems with configuring and testing the network connector with the non-split tunneling and disable local area network access option, I couldn’t find any useful logging about the problem. For some reason only specific traffic is routed into the VPN tunnel. I ended up configuring split-tunneling and only route specific network segments into the SSL VPN tunnel.

My opinion till now, Microsoft IAG cannot be compared with other SSL VPN appliances I have seen. I guess Microsoft IAG could test positive when using the appliance in a solely Windows environment, where only Windows services, like OWA and SharePoint, are published to the internet.

Maybe the solution is a lot cheaper compared with the Juniper and Citrix solution, but for know I would rather buy a Cisco ASA 5505 or Cisco ASA 5510. I would definitely not configure the Microsoft IAG as a cooperate firewall terminating the Internet connection.