[MEGOLDVA] Windows L2TP/IPSec nem kommunikál Cisco ASA-val

Sziasztok!

Van egy régi Cisco ASA 5520-asunk. A rajta futó szoftver sem a legújabb:


show version

Cisco Adaptive Security Appliance Software Version 8.0(2)
Device Manager Version 6.0(2)

Mivel a Cisco IPSec VPN kliensnek már semmilyen támogatása nincs, és nem fut Windows 10-en, bekonfiguráltam a rendszert, hogy a Windows-ok a saját beépített natív L2TP/IPSec kliensükkel csatlakozzanak. Az IPSec PSK-val authentikál, a felhasználók pedig Active Directory-ból linuxos Freeradiuson keresztül. Ugyanez a felállás Cisco IPSec-kel kiválóan működött éveken át. Az L2TP kapcsolat konfigurációja így néz ki az ASA-ban:


crypto ipsec transform-set WIN10 esp-aes-256 esp-sha-hmac
crypto ipsec transform-set WIN10 mode transport
crypto ipsec transform-set WIN7 esp-3des esp-sha-hmac
crypto ipsec transform-set WIN7 mode transport
crypto dynamic-map DYNMAP 10 set transform-set WIN10 AES256 WIN7 3DES AES
crypto dynamic-map DYNMAP 10 set reverse-route
crypto map CMAP 99 ipsec-isakmp dynamic DYNMAP

crypto isakmp enable ipsec

crypto isakmp policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
crypto isakmp policy 20
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400

group-policy L2TP internal
group-policy L2TP attributes
 wins-server value 12.34.56.78
 dns-server value 12.34.56.78 12.34.56.79
 vpn-tunnel-protocol IPSec l2tp-ipsec
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value ROUTING_SPLIT
 default-domain value my.domain.hu
 intercept-dhcp enable
 address-pools value VPN_USERS

tunnel-group DefaultRAGroup general-attributes
 authentication-server-group myradiusservers
 accounting-server-group myradiusservers
 default-group-policy L2TP
tunnel-group DefaultRAGroup ipsec-attributes
 pre-shared-key *
 isakmp keepalive disable
tunnel-group DefaultRAGroup ppp-attributes
 no authentication chap
 no authentication ms-chap-v1
 authentication ms-chap-v2

Mind a Windows 7 mind a Windows 10 gépek látszólag sikeresen csatlakoznak. A Windows is sikeresnek mutatja a csatlakozást, és az ASA így úgy látja, hogy él a kapcsolat:


show vpn-sessiondb remote

Username     : nice                   Index        : 72
Assigned IP  : 12.35.56.78            Public IP    : 111.222.33.44
Protocol     : IKE IPsecOverNatT L2TPOverIPsecOverNatT
Encryption   : none 3DES AES256       Hashing      : SHA1
Bytes Tx     : 1281                   Bytes Rx     : 9853
Group Policy : L2TP                   Tunnel Group : DefaultRAGroup
Login Time   : 17:29:10 UTC Mon Mar 7 2016
Duration     : 0h:00m:32s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none

Mindazonáltal a VPN mégsem működik. IP-címet ugyan kap a kliens, de a routing táblát nem tölti le, és semmilyen érdemi kommunikáció nem megy át a tunnelen akkor sem, ha az állítom be a kliensen, hogy a default route-ot rendelje hozzá a kapcsolathoz.

Ezen felül van egy másik probléma is: A RADIUS szerver bizonyos felhasználók esetében visszaad egy karaktersorozatot a Class nevű attribútumban (az attribútum neve LDAP-ban radiusClass), amelyet az ASA arra használ, hogy a tunnel group alapértelmezett group policyjét lecserélje egy másikra, pl. azért, hogy a rendszergazda jogú felhasználók másik IP-cím tartományba kerüljenek, ahonnan magasabb jogosultsággal dolgozhatnak. Az IPSec típusú kapcsolatoknál ez a mechanizmus kiválóan működik, de az L2TP/IPSec kapcsolatok figyelmen kívül hagyják, és mindig az alapértelmezett group policyval csatlakoznak, pedig látom, hogy a RADIUS szerver elküldi a megfelelő attribútumot.

Hogy tudnám megoldani ezeket a problémákat? Valamit rosszul konfiguráltam be? Esetleg frissítenem kellene az ASA szoftverét? Hogy tudom letölteni, hogy nincs hozzá "contract"-om? Esetleg ezt a megoldást sem támogatja már a Cisco? :-(

Előre is köszönöm a segítséget.

Hozzászólások

A szoftvert mindenképpen frissítsd, mivel egy 10 pontos remote vulnerability van az ipsec kódban, távoli kódfuttatással ahogy kell. Elvileg a Cisco ad sw-t erre a hibára contract nélkül, egy e-mail-t kell írni nekik az első linken le van írva van hová.

A legrégebbi javított 8.2(5.59) még felmegy az 5520-ra ha csak 256M ram van benne. Ha több akkor újabb verziók is.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/c…

https://blog.exodusintel.com/2016/02/10/firewall-hacking/

2GB RAM van benne. Ha csak simán felfrissítem 8.0-ról 9.1-re, akkor mi lesz a konfigurációval? A frissítés felhúzza a magasabb verzió szintaxisára, vagy problémák fognak adódni, és kézzel kell szerkesztgetnem?

A NAT szintaktika változott(nagyon) a 8.3-ban, elvben konvertálja és megy, ki is írja a változásokat bootkor, meg az összes megváltozott beállítást. De 8.0.2-ról egy lépésben nem lehet 9.1-re állni. Talán 8.0->8.4.5->9.1.7(4) az upgrade path. De lehet még egy 8.2 is kell. Régen voltak ezek... Itt a 8.4-nál fog történni a lényeg. A 8.4->9.1 az eseménytelen.
Előtte konfig backup mindenképpen és az új nat szintaktikát nézd át :)

Kell a 8.2 és a 8.3 is.
Bővebben: http://www.cisco.com/c/en/us/td/docs/security/asa/asa92/upgrade/upgrade…

A 8.3-ban és a 8.4-ben alakították át a NAT-ot + az objektum kezelés is változott.
Hideg élelem, sok kávé és türelem. Na meg egy kalappal. :)

--------------------------------
...except the gyevi bíró

Az ROUTING_SPLIT access-list az standard v. extended ha utóbbi akkor az baj.

OK, simán felfrissítettem az ASA-t, és most már kommunikálnak a Windows kliensek a tunnelen kereszül, és a RADIUS alapú group policy választás is megy, de a split routing még mindig nem működik :-(

Tegyél fel egy Wireshark-ot a kliensre és dumpolj. A Windows amikor l2tp-n csatlakozik kiküld egy DHCPINFORM üzenetet erre kellene jönnie az ASA-tól válaszként a routing-nak option 121 v option 249-ben ez utóbbi azt hiszem az MS-es nem "szabványos" kód. Jön válasz az ASA-tól?
Azt látom hogy elvileg be van állítva ez az "intercept-dhcp enable" opció.

Kipróbáltam XP-n, mert ott lehet wiresharkolni a PPP interfészen. Azt látom, hogy a Windows elküldi a DHCP INFORM kérést, de az ASA nem küld rá választ. Egyelőre semmilyen debug vagy log üzenetből nem tudtam megállapítani, mi a probléma oka vagy hogy egyáltalán mi történik az ASA-n.