Posts Tagged 'Cisco'

VPN Verbindungsprobleme zwischen strongSwan 4.1.11 und Cisco Router mit IOS 15.0(1)M7

Bei einem kürzlichen Test ließ sich partout keine IPSec Verbindung zwischen einem Linux mit strongSwan und dem Cisco Router 881 aufbauen; bei jedem Verbindungsaufbau seitens strongSwan kam es zu folgendem Fehler:

vpn:~# ipsec up linux-cisco
002 "linux-cisco" #17326: initiating Main Mode
104 "linux-cisco" #17326: STATE_MAIN_I1: initiate
003 "linux-cisco" #17326: received Vendor ID payload [RFC 3947]
002 "linux-cisco" #17326: enabling possible NAT-traversal with method 3
106 "linux-cisco" #17326: STATE_MAIN_I2: sent MI2, expecting MR2
003 "linux-cisco" #17326: ignoring Vendor ID payload [Cisco-Unity]
003 "linux-cisco" #17326: received Vendor ID payload [Dead Peer Detection]
003 "linux-cisco" #17326: ignoring Vendor ID payload [3bdf474ef95bfef528d85476c8e3efbc]
003 "linux-cisco" #17326: received Vendor ID payload [XAUTH]
003 "linux-cisco" #17326: NAT-Traversal: Result using RFC 3947: no NAT detected
108 "linux-cisco" #17326: STATE_MAIN_I3: sent MI3, expecting MR3
003 "linux-cisco" #17326: discarding duplicate packet; already STATE_MAIN_I3
010 "linux-cisco" #17326: STATE_MAIN_I3: retransmission; will wait 20s for response
003 "linux-cisco" #17326: discarding duplicate packet; already STATE_MAIN_I3
003 "linux-cisco" #17326: discarding duplicate packet; already STATE_MAIN_I3
010 "linux-cisco" #17326: STATE_MAIN_I3: retransmission; will wait 40s for response
003 "linux-cisco" #17326: discarding duplicate packet; already STATE_MAIN_I3
031 "linux-cisco" #17326: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message
000 "linux-cisco" #17326: starting keying attempt 2 of at most 3, but releasing whack

Auf dem Cisco Router war zeitgleich folgendes zu sehen:

cisco-881#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
51.243.239.41   223.23.80.47    MM_KEY_EXCH       2019 ACTIVE

cisco-881#show crypto session
Crypto session current status

Interface: FastEthernet4
Session status: DOWN-NEGOTIATING
Peer: 223.23.80.47 port 500
  IKE SA: local 51.243.239.41/500 remote 223.23.80.47/500 Inactive
  IKE SA: local 51.243.239.41/500 remote 223.23.80.47/500 Inactive
  IPSEC FLOW: permit ip 192.168.5.0/255.255.255.0 190.0.0.0/255.255.0.0
        Active SAs: 0, origin: crypto map

In strongSwan war der Tunnel wie folgt definiert:

conn linux-cisco
        left=223.23.80.47
        leftsubnet=190.0.0.0/16
        #
        keyexchange=ikev1
        #
        ike=aes-sha-modp1536
        esp=aes-sha1
        #
        right=51.243.239.41
        rightsubnet=192.168.5.0/24
        #
        keylife=1h
        ikelifetime=4h
        #
        authby=secret
        auto=start

Und auf dem Cisco-Router sah die Definition so aus:

crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 5
 lifetime 14400
crypto isakmp key PSK address 223.23.80.47
!
!
crypto ipsec transform-set linux-cisco esp-aes esp-sha-hmac
!
crypto map linux-cisco 10 ipsec-isakmp
 set peer 223.23.80.47
 set transform-set linux-cisco
 set pfs group2
 match address 103
!
!
interface FastEthernet4
 description WAN
 ip address 51.243.239.41 255.255.255.248
 ip access-group 101 in
 duplex auto
 speed auto
 crypto map linux-cisco
!
access-list 103 permit ip 192.168.5.0 0.0.0.255 190.0.0.0 0.0.255.255

Das Problem ließ sich dadurch beheben, in dem die Verschlüsselungsdefinition von AES auf AES128 angepasst wurde:

conn linux-cisco
        left=223.23.80.47
        leftsubnet=190.0.0.0/16
        #
        keyexchange=ikev1
        #
        ike=aes128-sha-modp1536
        esp=aes128-sha1
        #
        right=51.243.239.41
        rightsubnet=192.168.5.0/24
        #
        keylife=1h
        ikelifetime=4h
        #
        authby=secret
        auto=start

Anschließend ließ sich die Verbindung problemlos aufbauen:

vpn:~# ipsec up linux-cisco
002 "linux-cisco" #17332: initiating Main Mode
104 "linux-cisco" #17332: STATE_MAIN_I1: initiate
003 "linux-cisco" #17332: received Vendor ID payload [RFC 3947]
002 "linux-cisco" #17332: enabling possible NAT-traversal with method 3
106 "linux-cisco" #17332: STATE_MAIN_I2: sent MI2, expecting MR2
003 "linux-cisco" #17332: ignoring Vendor ID payload [Cisco-Unity]
003 "linux-cisco" #17332: received Vendor ID payload [Dead Peer Detection]
003 "linux-cisco" #17332: ignoring Vendor ID payload [3bdf474e9d021e282b05ba8c081723e4]
003 "linux-cisco" #17332: received Vendor ID payload [XAUTH]
003 "linux-cisco" #17332: NAT-Traversal: Result using RFC 3947: no NAT detected
108 "linux-cisco" #17332: STATE_MAIN_I3: sent MI3, expecting MR3
002 "linux-cisco" #17332: Peer ID is ID_IPV4_ADDR: '51.243.239.41'
002 "linux-cisco" #17332: ISAKMP SA established
004 "linux-cisco" #17332: STATE_MAIN_I4: ISAKMP SA established
002 "linux-cisco" #17333: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+MOBIKE {using isakmp#17332}
112 "linux-cisco" #17333: STATE_QUICK_I1: initiate
003 "linux-cisco" #17333: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
002 "linux-cisco" #17333: sent QI2, IPsec SA established {ESP=>0xa022fd69 0xa022fd69 <0x177a68e7}

Zur Ergänzung noch die funktionierende Verbindung auf Cisco-Seite:

cisco-881#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
51.243.239.41   223.23.80.47   QM_IDLE           2023 ACTIVE


cisco-881#show crypto session
Crypto session current status

Interface: FastEthernet4
Session status: UP-ACTIVE
Peer: 223.23.80.47 port 500
  IKE SA: local 51.243.239.41/500 remote 223.23.80.47/500 Active
  IPSEC FLOW: permit ip 192.168.5.0/255.255.255.0 190.0.0.0/255.255.0.0
        Active SAs: 2, origin: crypto map
Advertisements

Cisco WLC 5508: Web Authentifizierung mittels RADIUS und Active Directory

Neben der Möglichkeit, Benutzer für ein Gäste-WLAN lokal auf dem Wireless LAN Controller zu pflegen, kann die Authentifizierung auch über einen RADIUS Server mit z.B. Active Directory als Benutzerdatenbank realisiert werden. Als RADIUS Server eignet sich z.B. der in Windows Server 2008 R2 enthaltene Network Policy Server (NPS).

Nach der Installation des NPS als zusätzliche Rolle auf dem Server steht die entsprechende MMC unter „Administrative Tools“ bereit:

Als erstes wird in der Dropdownliste der Punkt „RADIUS server für 802.1X Wireless or Wired Connections“ gewählt und mit einem Klick auf „Configure 802.1X“ der Assistent zur Konfiguration gestartet. Im folgenden Fenster wird als Typ „Secure Wireless Connections“ ausgewählt und ein Name für die Richtlinie eingegeben:

Im nächsten Schritt wird der Wireless LAN Controller als RADIUS Client hinzugefügt und ein PSK vergeben:

Das nächste Fenster zur Auswahl der Authentifizierungsmethode wird mit einem Klick auf „Next“ übersprungen und man gelangt zur Auswahl der Elemente, denen die Anmeldung am WLAN über die Web Authentifizierung gewährt werden soll – in diesem Fall einer Windows-Gruppe aus dem Active Directory:

Das darauffolgende Fenster „Configure Traffic Controls“ wird ebenfalls mit einem Klick auf „Next“ übersprungen und der Assistent im Anschluss mit einem Klick auf „Finish“ beendet:

Anschließend wird die soeben erstellte Network Policy im linken Bereich der MMC mit der rechten Maustaste angeklickt und in den Eigenschaften der Punkt „Constraints“ aufgerufen. Unter „Authentication Methods“ werden alle Punkte bis auf „Unencrypted Authentication (PAP, SPAP)“ deaktiviert:

Außerdem muss auf der Karteikarte „Settings“ unter „RADIUS Attributes“ das Attribut „Service-Type“ mit dem Wert „Framed“ entfernt werden:

Entfernt man das Attribut nicht, funktioniert die Authentifizierung zwar trotzdem, es wird dabei aber folgende Syslog Meldung protokolliert:

    02-03-2012 16:47:21 Local0.Notice wlc-5508-01 WLC-5508-01: *emWeb: Feb 03 16:47:22.054: %AAA-5-AAA_AUTH_NETWORK_USER: aaa.c:1368 Authentication failed for network user ‚layer9‘

Die Einrichtung des Network Policy Servers ist damit abgeschlossen und es folgen die Einstellungen auf dem Wireless LAN Controller. Zunächst muss der NPS bzw. RADIUS-Server auf dem WLC unter „Security“ hinzugefügt werden:

Anschließend wird der RADIUS-Server auch in den Sicherheitseinstellungen des entsprechenden WLANs hinterlegt:

Optional wird unter „Advanced“ der Timeout für Session auf einen höheren Wert als die standardmäßig eingestellten 1800 Sekunden gesetzt:

Wird der Wert nicht angepasst, muss sich der Client nach 30 Minuten erneut per Web Authentifizierung anmelden [1]:

    […] If the WLAN session timeout expires before the guest account lifetime, the client experiences a recurring session timeout that requires reauthentication.

Interessant auch in diesem Zusammenhang: Cisco WLC 5508 keeping web auth persistent.

Als nächstes sollte in den Eigenschaften des Controllers geprüft werden, ob der Punkt „Web Radius Authentication“ analog zu den Einstellungen des NPS auf „PAP“ steht:

Alternativ kann als Authentifizierung auch das sicherere Protokoll CHAP verwenden werden. Allerdings muss hierfür die entsprechende Option im NPS ausgewählt werden und für die Benutzer im Active Directory muss die Option „Store password using reversible encryption“ aktiviert sein. Ist Letzteres nicht aktiviert, wird im Eventlog des Network Policy Servers das Event 6273 protokolliert:

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
	Security ID:			NULL SID
	Account Name:			layer9
	Account Domain:			layer9
	Fully Qualified Account Name:	layer9\layer9

Client Machine:
	Security ID:			NULL SID
	Account Name:			-
	Fully Qualified Account Name:	-
	OS-Version:			-
	Called Station Identifier:		192.168.110.10
	Calling Station Identifier:		192.168.115.12

NAS:
	NAS IPv4 Address:		192.168.110.10
	NAS IPv6 Address:		-
	NAS Identifier:			WLC-5508-02
	NAS Port-Type:			Wireless - IEEE 802.11
	NAS Port:			1

RADIUS Client:
	Client Friendly Name:		wlc-5508-02
	Client IP Address:			192.168.110.10

Authentication Details:
	Connection Request Policy Name:	Web Auth for LAYER9-GUESTS
	Network Policy Name:		-
	Authentication Provider:		Windows
	Authentication Server:		nps.layer9.intern
	Authentication Type:		MD5-CHAP
	EAP Type:			-
	Account Session Identifier:		-
	Logging Results:			Accounting information was written to the local log file.
	Reason Code:			19
	Reason:				The user could not be authenticated using Challenge Handshake Authentication Protocol (CHAP). A reversibly encrypted password does not exist for this user account. To ensure that reversibly encrypted passwords are enabled, check either the domain password policy or the password settings on the user account.

…und die Authentifizierung schlägt fehl:

    *radiusTransportThread: Feb 06 11:07:16.616: 00:1b:77:70:94:ce Returning AAA Error ‚Authentication Failed‘ (-4) for mobile 00:1b:77:70:94:ce
    *radiusTransportThread: Feb 06 11:07:16.616: AuthorizationResponse: 0x3c3fd8b4

Damit ist die Einrichtung abgeschlossen und Mitglieder der auf dem NPS bzw. RADIUS-Server hinterlegten Windows-Gruppe sollten sich per Web Authentication am entsprechenden WLAN anmelden können:

Klappt alles, wird folgende Meldung im Syslog protokolliert:

    02-03-2012 15:45:49 Local0.Notice wlc-5508-01 WLC-5508-01: *emWeb: Feb 03 15:45:49.955: %AAA-5-AAA_AUTH_NETWORK_USER: aaa.c:1363 Authentication succeeded for network user ‚layer9‘

Sollte es bei der Authentifizierung Probleme geben, hilft in der Regel ein Blick ins Eventlog des Network Policy Servers sowie eine SSH Verbindung zur Konsole des Controllers und ein Debugging der Authentifizierung durch folgenden Befehl:

    debug aaa all enable

Neben der Authentifizierung über den RADIUS bzw. NPS kann übrigens auch ein Accounting darüber erfolgen. Das ist praktisch, da so einfach festgestellt werden kann, z.B. welcher Benutzer wie lange und mit welcher IP-Adresse das WLAN genutzt hat. Dazu wird auf dem NPS der Punkt „Accounting“ angeklickt und konfiguriert, an welchem Ort entsprechende Daten protokolliert werden sollen. In kleineren Umgebungen reicht das Logging in Textdateien im einfachen IAS-Format:

Auf dem WLC wird der NPS zusätzlich als RADIUS Accounting Server angelegt:

Anschließend wird der Accounting Server auch in den Eigenschaften des WLANs hinterlegt:

Ist das Accounting eingerichtet, kann die vom NPS generierte Logdatei mit einem Viewer wie z.B. dem IAS Log Viewer ausgewertet werden, so dass Informationen wie Anmeldeversuche, Verbindungsdauer, Client-IP Adresse und Datenvolumen sichtbar werden:

Wer ein Gäste WLAN einrichtet, sollte sich nach Möglichkeit übrigens ein offizielles SSL Zertifikat beschaffen und dieses an den Controller binden. So wird vermieden, dass Benutzer durch eine Sicherheitswarnung ihres Browsers verwirrt werden. Hilfreich in diesem Zusammenhang ist der Artikel Generate CSR for Third-Party Certificates and Download Chained Certificates to the WLC von Cisco.

Generell empfehlenswert sind außerdem die Artikel Wireless LAN Controller Web Authentication Configuration Example und Wireless Guest Access FAQ.

[1] Cisco Wireless LAN Controller Configuration Guide, Release 7.0