Posts Tagged ‘EoU’

I’ve always said that, when it comes to Cisco, my brains go boom, temperature increases and I end up having 30 Firefox tab trying to search on cisco.com what on earth some kinky cisco-ish feature does and _how_ precisely.

After the latest IPsec adventure with Cisco’s Customer Support (CCIE Security) which advised me to run commands that were not even available on my IOS (yes, I had previously given them my config and IOS version), I said that whenever I have Cisco-related issues I go straight to my team lead, the guy being able to fix no matter issue I encountered on Cisco – at least on the IPsec side…

Now, I’ve had the honor of having to move an EoU/WebAuth config from a 3750 to a 6500. While I was feeling pretty good about myself being able to configure and understand the way to configure EoU and WebAuth on Cisco (EoU is NAC L2, I am using L2 interfaces in a L2 vlan in mode access and use the “ip admission” command on the L2 interface, while WebAuth gets configured as a fallback to 802.1x using the “dot1x fallback dot1x-www” on the L2 interface), I have now realized that I am FAR FAR AWAY from the truth. I’ve woken up on this twisted 6500, where I have the possibily of configuring:

1. 802.1x – fair enough, I am not using 802.1x here anyways

2. NAC Layer 2 IP / LAN Port IP – which can be configured this way (as per Cisco’s KB)

Router# configure terminal
Router(config)# ip admission name nac eapoudp
Router(config)# access-list 5 permit any any
Router(config)# interface gigabitethernet 2/0/1
Router(config-if)# ip access-group 5 in
Router(config-if)# ip admission nac
Router(config-if)# exit
Router(config)# aaa new-model
Router(config)# aaa authentication eou default group radius
Router(config)# radius-server host admin key rad123
Router(config)# radius-server vsa send authentication
Router(config)# ip device tracking probe count 2
Router(config)# eou logging
Router(config)# end

3. LAN Port IP – which, ignoring their own definition from some KBs, now appears as a “Web-Based Authentication” and gets configured…nowhere says _how_

4. NAC Layer 3 IP / NAC Gateway IP – which should be enabled on L3 interfaces

Router(config)# ip admission name webauth1 proxy http

Router(config)# interface fastethernet 5/1

Router(config-if)# ip admission webauth1

Router(config-if)# authentication order webauth

Router(config-if)# exit

Router(config)# ip device tracking

Router(config)# ip admission proxy http login page file disk1:login.htm

Router(config)# ip admission proxy http success page file disk1:success.htm

Router(config)# ip admission proxy http fail page file disk1:fail.htm

Router(config)# ip admission proxy http login expired page file disk1:expired.htm

5. NAC Gateway IP – which is configured as auth-proxy, this way:

Router(config)# ip auth-proxy name webauth http inactivity-time 60

Router(config)#interface GigabitEthernet3/15

Router(config-if)# description WEBAUTH

Router(config-if)# switchport

Router(config-if)# switchport access vlan 502

Router(config-if)# switchport mode access

Router(config-if)# ip access-group www in

Router(config-if)# spanning-tree portfast edge

Router(config-if)# ip auth-proxy webauth

Router(config)# ip access-list extended www

Router(config)# permit tcp any any eq www

Router(config)# deny   ip any any

The “aaa authentication login default radius” is on. The “ip http server” is on. The “aaa authorization auth-proxy default group radius ” is on also.

Now, I am no EoU, WebAuth, and by far no Cisco guru, but, what gives? Why so many auth methods? And, specially, why the method I use to configure one way on a 3750 (WebAuth using the “auth-proxy” set of commands) is configured some other way on 6500 (WebAuth using the “ip admission <name> proxy http” set of commands) – while keeping the “auth-proxy” set of commands – which here do something else. Why is it so hard to be consistent all over your own set of devices?

I have done 802.1x on Summit (netlogin called in there), WebAuth on Summit and WebAuth on HP switches. None of them seemed so damn confusing 😦 I am lost.

Advertisements

I say definitely to Summit. A very peculiar device, that amazed me instantly.

It is one of the products of Extreme Networks, don’t know how big of a company, but I got to love their solution. Even one of the smallest and lowest performance solution they have (Summit48si)  distinguished by its loads of features, performance, ease of configuration and, above all, STABILITY, something I haven’t found at the mighty Cisco solution that everybody loves.

A while back I needed to do something very specific: I wanted to separate traffic coming from two networks on trunks. My device should have reunited all this traffic and forward it to a different machine that would NAT it forward on to my servers. Each done by any device easily. But – what I wanted more was at the authentication level. I wanted to do 802.1x authentication on trunks and forward the authenticated traffic to a secondary device that would do EAPoverUDP for some of the traffic and WebAuth for the rest of the traffic, all based on the ACLs configured on a separate Radius (ACS) server. Now, I won’t get into details about the EoU, WebAuth, nor ACS configuration, but rather describe what I have managed to do with Summit.

First of all, unlike other devices, this one allows the premises of my topology: it lets me configure 802.1x on a trunk port – which I wasn’t able to obtain from Cisco after long hours of pain and swearing. So, traffic is coming from my supplicants, on 3 ports of this Summit device, let’s say 1,2 and 3. Ports 1 and 2 carry only 802.1x authenticated traffic, while port 3 is a combination of 802.1x, EoU and WebAuth. So, I have defined 4 vlans: 1,2,3 and 4. As part of my traffic is only authenticated with 802.1x, I left the first 2 ports authenticated in 802.1x on vlan 1, and assigned the next port (3) on all of the other 3 vlans: 2,3 and 4. This is this the access portion of the topology.

The second part, I have to switch all this traffic through another device, that deals with EoU and WebAuth, so I have defined 5 “exit” ports: 1 for the 802.1x authenticated traffic that wouldn’t need any other authentication (this traffic I trust to be secure only as part of the Summit authentication), 2 ports for the mixed-authentication traffic (this traffic I have authenticated via 802.1x in Summit, and I trust it), and 2 more ports for the traffic I want to further re-authenticate: 1 for the mixed traffic that has 802.1x and EoU and that I intend to authenticate via EoU and 1 port for the mixed 802.1x and WebAuth traffic that I intend to authenticate via WebAuth further on. The scenario would look something like this:

top

—where:

-‘vlan 1’ is a layer 3 interface that forwards the traffic coming from the 802.1x already-authenticated ports from Summit and it is further authenticated via EoU here

– ‘vlan 2’ is a layer 3 interface that forwards the traffic coming from the 802.1x already-authenticated ports from Summit and it is further authenticated via WebAuth here

Some of the traffic is only authenticated via EoU and WebAuth, so I have to let it pass through Summit without asking it for credentials.

From these 2 vlans, the traffic passes back into the internal network where the servers reside – this is of no further interest in this case. Still, I had to create 2 vlans, because of the default gateways that I need to assigned to my supplicants. One would be the layer 3 address of vlan 1 and the second would be the layer 3 address of vlan 2.

The cool part of this entire topology is how to fragment the traffic in Summit, in order to make sure that each type of authentication takes place where it is supposed to.

Of course, the ports belonging to vlans 1 and 2 are “access mode” untagged ports. Ports from 11 to 15 on the Summit device are also untagged ports, while ports 1 and 2 are untagged in a specific 802.1x vlan (let’s say 111), ports 3, 4 and 5 are double-tagged on a separate vlan (as they have mixed traffic that is to be authenticated on EoU and WebAuth separately further on, let’s say 117 for traffic that is to be forwarded to EoU authentication ports and 118 for traffic that is to be forwarded to WebAuth authentication ports) and untagged on vlan 113 – also an 802.1x enabled access vlan (as they also carry 802.1x information). Now, all this funky division is necessary for the netlogin information (as Summit calls the 802.1x authentication).

And the actual config looks like this:

# Config information for VLAN v111.
configure vlan “v111” tag 111
configure vlan “v111” protocol “ANY”
configure vlan “v111” qosprofile “QP1”
# No IP address is configured for VLAN v111.
configure vlan “v111” add port 1 untagged
configure vlan “v111” add port 2 untagged
configure vlan “v111” add port 11 untagged
# Config information for VLAN v113.
configure vlan “v113” tag 113
configure vlan “v113” add port 3 untagged
configure vlan “v113” add port 4 untagged
configure vlan “v113” add port 5 untagged
configure vlan “v113” add port 12 untagged
configure vlan “v113” add port 13 untagged
# Config information for VLAN v117.
configure vlan “v117” tag 117
configure vlan “v117” protocol “ANY”
configure vlan “v117” qosprofile “QP1”
# No IP address is configured for VLAN v117.
configure vlan “v117” add port 14 untagged
configure vlan “v117” add port 3 tagged
configure vlan “v117” add port 4 tagged
configure vlan “v117” add port 5 tagged
#
# Config information for VLAN v118.
configure vlan “v118” tag 118
configure vlan “v118” protocol “ANY”
configure vlan “v118” qosprofile “QP1”
# No IP address is configured for VLAN v118.
configure vlan “v118” add port 15 untagged
configure vlan “v118” add port 3 tagged
configure vlan “v118” add port 4 tagged
configure vlan “v118” add port 5 tagged
The netlogin command has been issued for ports 1,2,3,4,5, but only on vlans 111 and 113.
# Network Login Configuration
enable netlogin port 1 vlan v111
enable netlogin port 2 vlan v111
enable netlogin port 3 vlan v113
enable netlogin port 4 vlan v113
enable netlogin port 5 vlan v113
configure netlogin base-url “network-access.net”
configure netlogin redirect-page “http://www.extremenetworks.com&#8221;
disable netlogin Session-Refresh  3
enable netlogin logout-privilege
disable netlogin web-based
enable netlogin dot1x
The show netlogin command shows, at any moment, the status of the port (per un/tagged vlan), looking something like this:
> sh netlogin ports 1 vlan v111
Port: 1 Vlan: v111
Port State:     Not Authenticated
Temp IP:        Unknown
DHCP:           Not Enabled

MAC                IP address      Auth   Type      ReAuth-Timer User
——————————————————————
When in non-authenticated state. When actually authenticating a supplicant, the command displays the MAC address, IP (if the case), auth type and name of the user.
And, to actually be able to _authenticate_ users, I have to define  a Radius server where to connect:
# Radius configuration
#
enable radius
configure radius primary shared-secret encrypted “ABC”
configure radius timeout 30
configure radius primary server 1.2.3.4 1645 client-ip 1.2.3.5
configure radius primary server 1.2.3.5 timeout 30
disable radius-accounting
The “1.2.3.5” IP is the Summit IP address, that I have assigned on a separate vlan. Of course, ACS should have defined this IP as a client with a password of “ABC” – encrypted form and profiles for my users.
But about ACS in the next episode 😛