March 3rd, 2010
One of the typical tasks it transforming routers table between two routers through public routers (for example via internet). So all data moving through public space has to be encrypted. And one of the best solution it use IPSec for encryption. However one of the disadvantage of IPSec it is working only with unicast traffic. Thereby, we will use GRE tunnel to transform broadcast and multicast traffic. Another word we will encapsulate multicast traffic into unicast and then encrypt it by IPSec.
One of the typical topology:
Let’s configure:
First of all create simple routing between routers.
R1:
R1#configure terminal
R1(config)#interface fastEthernet 1/0
R1(config-if)#ip address 10.0.1.1 255.255.255.0
//add gateway by default
R1(config)#ip route 0.0.0.0 0.0.0.0 10.0.1.2
R2:
R2#configure terminal
R2(config)#interface fastEthernet 1/0
R2(config-if)#ip address 10.0.2.1 255.255.255.0
R2(config)#ip route 0.0.0.0 0.0.0.0 10.0.2.2
Checking the connection between routers:
On the second stage we have to establish GRE tunnels:
R1(config)#interface tunnel 0
R1(config-if)#ip address 174.10.0.1 255.255.255.252
R1(config-if)#tunnel source fastEthernet 1/0
R1(config-if)#tunnel destination 10.0.2.1
R2(config)#interface tunnel 0
R2(config-if)#ip address 174.10.0.1 255.255.255.252
R2(config-if)#tunnel source fastEthernet 1/0
R2(config-if)#tunnel destination 10.0.1.1
Let’s check how it work.
On the third stage we will establish IPSec tunnel between routers:
R1:
R1(config)#crypto isakmp enable
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#encryption aes
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#hash sha
R1(config-isakmp)#exit
R1(config)#crypto isakmp key 0 cisco address 10.0.2.1
R1(config)#access-list 101 permit gre host 10.0.1.1 host 10.0.2.1
R1(config)#crypto ipsec transform-set IPSEC esp-aes esp-sha-hmac
R1(cfg-crypto-trans)#mode transport
R1(cfg-crypto-trans)#exit
R1(config)#crypto map GRE 10 ipsec-isakmp
R1(config-crypto-map)#match address 101
R1(config-crypto-map)#set transform-set IPSEC
R1(config-crypto-map)#set peer 10.0.2.1
R1(config-crypto-map)#exit
R1(config)#interface fastEthernet 1/0
R1(config-if)#crypto map GRE
For R2 we have to issue same configure command except ip address of peer. Change IP 10.0.2.1 to 10.0.1.1
Let’s check out IPSec tunnel:
Now we can easely transform EIGRP or OSPF data from one router to another. To check it in our example let’s add router process OSPF or EIGRP and add tunnel network to it and any other if iwe need.
In case of EIGRP we have add next command on both routers R1 and R2:
router eigrp 100
network 174.10.0.0 0.0.0.3
Categories: VPN
Tags: crypto, GRE Tunnel, IPSec
December 30th, 2009
This is switch function intended for defense from attack with using ARP protocol. For instance, ARP-spoofing, which allow intercept traffic between hosts, that located in one broadcast domain.
Dynamic ARP Inspection control only ARP packets and can’t directly influence on user’s traffic or other protocols.
For proper work Dynamic ARP Inspection, it is necessary to specify which switch ports will be trusted and which will be untrusted.
• Untrusted – ports, which are connected with clients hosts. For untrusted ports always execute some ARP protocol inspections.
• Trusted – posts, which are connected with other switches. Packets received from these ports are not required in any inspections.
Some specific features DAI:
• Dynamic ARP inspection is supported on access ports, trunk ports, EtherChannel ports, and private VLAN ports.
• Dynamic ARP inspection is an ingress security feature; it does not perform any egress checking.
• Dynamic ARP inspection depends on the entries in the DHCP snooping binding database to verify IP-to-MAC address bindings in incoming ARP requests and ARP responses. Make sure to enable DHCP snooping to permit ARP packets that have dynamically assigned IP addresses.
Note: Dynamic ARP Inspection become available from IOS 12.2(50)SE release.
How it works?
Switch intercept all ARP-requests and ARP- answers on untrusted ports and before send it further check for MAC address conformity with IP address.
Checking conformity based on DHCP snooping binding database and static arp records.
Let us consider next topology:
On the switches SW1 and SW2 turn on DHCP Snooping.
Port Fa0/1 on the SW2 and Fa0/2 on the SW1 is trusted as on untrusted ports all DHCP packet from DHCP Server (and arp traffic) will be rejected.
First of all we have to configure DHCP snooping.
Configuring DHCP Snooping
On the switch SW1 turn on DHCP snooping:
SW1(config)#ip dhcp snooping
SW2(config)#ip dhcp snooping
Turn on DHCP snooping in the VLAN, which have to be protected with it.
SW1(config)#ip dhcp snooping VLAN 1
(Option) You can assign ip address authorized DHCP-server, which has to accessible via trusted port:
sw2(config)#ip dhcp-server 10.10.0.1
Configuring of the trusted ports:
SW1(config)# interface fastethernet0/1
SW1(config)#ip dhcp snooping trust
SW1(config)# interface fastethernet0/2
SW1(config)#ip dhcp snooping trust
SW2(config)# interface fastethernet0/1
SW2(config)#ip dhcp snooping trust
Configuring Option 82 (it is very important)
For clients hosts we need disable inserting option 82:
switch(config)# no ip dhcp snooping information option
Now we need check how work dhcp snooping:
Force client computer to get new ip address and find record about it in dhcp snooping database
By using command:
SW2#show ip dhcp snooping binding
Configuring Dynamic ARP Inspection
Turn on DAI in VLANs:
SW1(config)# ip arp inspection vlan 1
Configuring of the trusted ports:
SW1(config)#int f0/1
SW1(config-if)#ip dhcp snooping trust
SW2(config)#int f0/1
SW2(config-if)#ip dhcp snooping trust
And on the port which connected with other switch:
SW1(config)# interface fastethernet0/1
SW1(config-if)# ip arp inspection trust
SW1(config)# interface fastethernet0/2
SW1(config-if)# ip arp inspection trust
As dynamic ARP inspection is an ingress security feature (it does not perform any egress checking), we do not need in our case make port f0/1 on SW2 as trusted.
To check how work ARP inspection you can use next commands:
show ip arp inspection statistics vlan 1 (Check the dynamic ARP inspection statistics)
Sources:
http://www.xgu.ru/wiki/DHCP_snooping
https://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_50_se/configuration/guide/swdynarp.html
Categories: Security Layer 2
Tags: arp, DHCP Snooping, Dynamic ARP inspection
December 23rd, 2009
LWAPP is the name of a protocol that can control multiple Wi-Fi wireless access points at once. This can reduce the amount of time spent on configuring, monitoring or troubleshooting a large network. The system will also allow network administrators to closely analyze the network.
LWAPP was proposed by Airespace, as a standard protocol to provide interoperability among any brand of access point. Its purpose was to standarardize “lightweight” access points with the Internet Engineering Tak Force (IETF), but it was not approved as a standard. Airespace was purchased by Cisco Systems.
LWAPP now is a generic protocol with a binding definition for the 802.11 wireless LAN protocol. As I said LWAPP defines how access point communicate with wireless LAN controllers. This communication can be either by means of native, Layer 2 Ethernet frames, or Layer 3 via IP packets. In the Cisco LWAPP implementation, Layer 3 LWAPP packets are carried in UDP packets.
LWAPP messages carry one of two types of payload:
LWAPP Data Messages, which are encapsulated and forwarded data frames send from and to wireless clients.
LWAPP Control Messages, which are management messages exchanged between the wireless LAN controller and the access point.
The LWAPP protocl header contains a controll bit (the C-bit) which identifies data control packets. When Layer 3 LWAPP is used, the LWAPP data and contorl packets are sent to separate UDP ports. Because both data and control frames can be fragmented, the payload LWAPP data or control message can be fragmented.
How does an Access Point (AP) bind with a Wireless LAN Controller (WLC) to form a complete working access point? The two devices must bring up a tunnel between them to carry 802.11 – related messages and also client data. The tunneled data can be switched or routed across the campus network.
Actually, LWAPP consists of the two tunnels:
LWAPP control messages – Exchanges that are used to configure the LAP and menage its operation. THe control messages are authenticated and encrypted so that the LAP is securely contolled by only the WLC.
LWAPP data - Packets to and from wireless clients assiciated with the LAP. The data is encapsulated within LWAPP, but is not encrypted or otherwise secured between the LAP and WLC.
Every LAP and WLC must also authenticate each other with digital certificates. An X.509 certificate is pre-installed in each device when it is purchased.
Lightweight AP Operation
The lightweight AP is designed to be a “zero-tough” configuration. The LAP must find a WLC and obtain all of its configuration paramets, so you never have to actually configure it through its console port or over the network.
The following sequence of steps detail the bootstrap process that an LAP must complete before it becomes active.
- The LAP obtains an IP address from a DHCP server.
- The LAP learns the IP addresses of any available WLCs.
- The LAP sends a join request to the first WLC in its list of addresses. If that one fails to answer, the next WLC is tried. When a WLC accepts the LAP, it sends a join reply back to the LAP, effectively binding the two devices.
- The WLC compares the LAP’s code image release to the code release stored locally. If they differ, the LAP downloads the code image stored on the WLC and reboots itself.
- The WLC and LAP build a secure LWAPP tunnel for management traffic and an LWAPP tunnel (not secured) for wireless client data.
LWAPP devices can communicate in two mode LWAPP Layer 2 and Layer 3.
LWAPP Layer 2 Transport Mode
LWAPP communication between the access point and the wireless LAN controller can be in native, Layer 2 Ethernet frames.
As you can see from this figure, the LWAPP Control and Data messages are encapsulated in Ethernet frames using Ethertype “0xBBBB”. In Layer 2 LWAPP mode, although the access points may get an IP address via DHCP, all LWAPP communications between the access point and WLC are in Ethernet encapsulated frames, not IP packets. The access points must be on the same Ethernet network as the WLC. For this reason, Layer 2 LWAPP mode may not be suitable for scalability purposes in most deployments.
LWAPP Layer 3 Transport Mode
Layer 3 LWAPP Control and Data messages are transported over the IP network in UDP packets. This transport architecture is inherently more flexible and scalable than Layer 2 LWAPP and is the generally preferred solution. Layer 3 LWAPP is supported on all Cisco WLC platforms and lightweight access points.
LWAPP Control and Data messages are encapsulated in UDP packets that are carried over the IP network. The only requirement is established IP connectivity between the access points and the WLC. The LWAPP tunnel uses the access point’s IP address and the WLC’s AP Manager interface IP address as endpoints. On the access point side, both LWAPP Control and Data messages use an ephemeral port that is derived from a hash of the access point MAC address as the UDP port. On the WLC side, LWAPP Data messages always use UDP port 12222. On the WLC side, LWAPP Control messages always use UDP port 12223.
Lightweight AP Association and Roaming
Wireless clients must negotiate an association with lightweight APs, as with any 802.11 wireless network. However, the split-MAC architecture has an interesting effect on client associations. Remember that an LAP handles mostly real-time wireless duties, so it will just pass the client’s association requests on up to the WLC. In effect, the wireless clients negotiate their associations with the WLC directly. This is important for two reasons:
- All client associations can be managed in a central location.
- Client roaming becomes faster and easier; associations can be maintained or handed off at the
controller level.
With autonomous APs, a client roams by moving its association from one AP to another. The client must negotiate the move with each AP independently, and the APs must also make sure any buffered data from the client is passed along to follow the association. Autonomous roaming occurs only at Layer 2; some other means must be added to support Layer 3 roaming.
With lightweight APs, a client still roams by moving its association. From the client’s point of view, the association moves from AP to AP; actually it moves from WLC to WLC, according to the AP-WLC bindings.
Intra-Controller Roaming
In the next figure, a wireless client has an active wireless association at location A. The association is with WLC1 through AP1. As you might expect, all traffic to and from the client passes through the LWAPP tunnel between AP1 and WLC1.
The client begins moving and roams into the area covered by AP2. For this example, notice two things: The cells provided by AP1 and AP2 both use the SSID “MyWLAN,” which
enables the client to roam between them. In addition, both AP1 and AP2 are joined to a single controller, WC1.
Inter-Controller Roaming
In some cases, a client might roam from one controller to another. For example, a large wireless network might consist of too many LAPs to be supported by a single WLC. The LAPs could also be distributed over several controllers for load balancing or redundancy purposes.
In the next figure, a wireless client is using an association with WLC1 through AP1. This is similar to our previous figure, but now each of the adjacent LAP cells belongs to a different WLC. All the client’s traffic passes through the LWAPP tunnel from AP1 to WLC1.
When the client moves into AP2’s cell, the same SSID is found, and the client can move its association to WLC2. As long as the two controllers (WLC1 and WLC2) are located in the same
IP subnet, they can easily hand off the client’s association. This is done through a mobilitymessage exchange where information about the client is transferred from one WLC to the other. Once the mobility exchange occurs, the client begins using the LWAPP tunnel between AP2 and WLC2. The client’s IP address has not changed; in fact, the roaming process was completely transparent to the client.
I will continue write about WLAPP in the next articles…
Sources:
http://en.wikipedia.org/wiki/LWAPP
http://www.cisco.com/en/US/docs/wireless/technology/controller/deployment/guide/dep.html#wp1050339
Book: CCNP Self-Study BCMSN Official Exam Certification Guide.
Categories: Wireless
Tags: LWAPP
December 22nd, 2009
For VLAN assignment we have to configure two ACS components group (properties of group and group mapping) and authorization.
In the navigation bar, click External User Databases. Then, click Database Group Mappings.
Click the external user database name for which you want to configure a group mapping.
In this example, it is Windows database.
In the resultant Domain Configurations page, click New configuration.
Note: By default you see only the domain \DEFAULT on this page.
The Define New Domain Configuration page appears..
In the Detected Domains box of this page, you should be able to see the Windows user database LAB. Click Submit.
The new Windows domain LAB appears in the list of domains in the Domain Configurations page.
Click the LAB domain.
The Group Mappings for the Domain: LAB table appears.
Click Add mapping.
The Create new group mapping for Domain: LAB page opens. The group list displays group names that are derived from the LAB database. In this Group set, you should be able to see the group vlan20 created in the AD of this lab domain.
Choose vlan20 from the group list, then click Add to selected.
In the ACS group drop-down box, choose Group20 to which you want to map users who belong to AD group: vlan 20.
Click Submit.
The group mapped to the ACS list appears at the bottom of the database groups column as shown in the example. The asterisk (*) at the end of each set of groups indicates that users who are authenticated with the external user database can belong to other groups besides those in the set.
Configure ACS Authorization Components or RADIUS Authorization Components (RAC)
RACs are sets of RADIUS attributes that are applied to switch during network authorization. After you group a set of RADIUS attributes in a RAC, you can make the RAC available when configuring network access profiles and use it as an enforcement command for the switch, sent in the RADIUS Access Accept packet.
Step 1. To configure RACs, choose Shared Profile Components > RADIUS Authorization Components and click the Add button for each new RAC you want to create. Each RAC can contain one or more vendor RADIUS attributes, including Cisco IOS/PIX 6.0 and IETF.
Step 2. Specify RAC entries, attribute assignments, and values. Create these RAC configurations for a IEEE 802.1x scenario (NAC Layer 2 IEEE 802.1x).
| Attribute |
Vendor |
Use Case |
Definition |
| Tunnel-Type |
IETF |
IEEE 802.1x |
Tunnel-Type (802) defined in RFC 3580 |
| Tunnel-Medium-Type |
IETF |
IEEE 802.1x |
Tunnel-Medium-Type (VLAN) defined in RFC 3580 |
| Tunnel-Private-Group-ID |
IETF |
IEEE 802.1x |
Tunnel-Private-Group-ID defined in RFC 3580. This attribute is used to tell the NAD which local VLAN the switch should assign to a port to which a user is connected. Cisco NADs accept both strings (VLAN name) and integers (VLAN ID) in this attribute. This attribute needs to be sent along with attributes 64 and 65. |
In my case it was:
| RAC Name |
Vendor |
Assigned Attributes |
Value |
| 802.1x_Compliant_User |
IETF |
Tunnel-Type (64) |
VLAN |
|
IETF |
Tunnel-Medium-Type (65) |
802 |
|
IETF |
Tunnel-Private-Group-ID (81) |
default |
Do not forget set up authorization on your switch, in case of Cisco device:
Switch(config)#aaa authorization network default group radius
Categories: Security, VLAN
Tags: ACS, VLAN Assignment
December 22nd, 2009
- In the navigation bar, click External User Databases. Then, click Unknown User Policy.
- In order to allow unknown user authentication, enable the Unknown User Policy: a) Select the Check the following external user databases option. b) Select the Windows Database in the External Databases list and click –> (right arrow button) to move it from External Databases to the Selected Databases list. In order to remove a database from the Selected Databases list, select the database, and then click <– (left arrow button) to move it back to the External Databases list.
- Click Submit.
The ACS saves and implements the Unknown User Policy configuration that you created.
Categories: Security
Tags: ACS, Windows users
