Transcription
VPN with Mobile Devices revisited55. DFN Betriebstagung Oktober 2011 BerlinProf. Dr. Andreas SteffenInstitute for Internet Technologies and ApplicationsHSR Hochschule für Technik Rapperswilandreas.steffen@hsr.ch
Problemkreise bei Mobile Devices Multihoming bei mehreren Netzwerkkarten (UMTS, WLAN, etc) IKEv2 MOBIKE Protokoll (RFC 4555) Routing im Innern des Tunnels bei dynamischen IP Adressen Vergabe von virtuellen IP Adressen durch Pool oder DHCP Verfügbarkeit des Gateways High Availability & Load Sharing Durch Malware verseuchte Mobile Devices Trusted Network Connect & Platform Trust Service18.10.2011, dfn berlin 2011 tech.pptx 2
VPN with Mobile Devices revisited55. DFN Betriebstagung Oktober 2011 BerlinMOBIKE – Mobility and Multihoming Protocol
IKEv2 Remote Access Szenario#ipsec.secrets for roadwarrior carol#ipsec.secrets for gateway moon: RSA carolKey.pem "nH5ZQEWtku0RJEZ6": RSA moonKey.pem#ipsec.conf for roadwarrior carol#ipsec.conf for gateway moonconn homekeyexchange ikev2leftsourceip %configleftcert carolCert.pemleftid carol@strongswan.orgleftfirewall yesright moon.strongswan.orgrightid @moon.strongswan.orgrightsubnet 10.1.0.0/16auto startconfig setupplutostart no #IKEv1 not neededconn rwkeyexchange ikev2leftsubnet 10.1.0.0/24leftcert moonCert.pemleftid @moon.strongswan.orgleftfirewall yesright %anyrightsourceip 10.3.0.0/24auto add18.10.2011, dfn berlin 2011 tech.pptx 4
VPN Multihoming Szenario IGSM/UMTSC2VInternetC3C1VPN ClientPublic WLANG2SG1Local WLANG3IntranetVPN Gateway18.10.2011, dfn berlin 2011 tech.pptx 5
VPN Multihoming Szenario II Lokale WLAN Verbindung, UMTS Interface im StandbyC1C1C1C1- - -G1:G1:G1:G1:IKE SA Req #0 [IKE SA Res #0 [IKE AUTH Req #1IKE AUTH Res #1SA KESA KE[ IDi[ IDrIPsec SA: C1 - G1No N(NATD S IP) N(NATD D IP) ]No N(NATD S IP) N(NATD D IP) . ]N(MOBIKE SUP) N(ADD 4 ADDR C2) . ]N(MOBIKE SUP) N(ADD 4 ADDR G2) N(ADD 4 ADDR G3) ]IPsec Policy: V/32 - S/32 VPN Client verlässt lokales WLAN und schaltet Defaultroute auf UMTS umC2C2C2C2C2C2- - - - ReqReqResReqRes#2#2#2#2#3#3IPsec SA: C2 - G2[[[[[[]]]]N(UPD SA ADDR) N(NATD S IP) N(NATD D IP) N(COOKIE2) ]N(NATD S IP) N(NATD D IP) N(COOKIE2) ]IPsec Policy: V/32 - S/32 Der IPsec Tunnel muss nicht neu aufgebaut werden.Es wird nur die IPsec SA via IKEv2 MOBIKE (RFC 4555) aufdatiert Knacknuss: Wie sollen die gefundenen Routen priorisiert werden?18.10.2011, dfn berlin 2011 tech.pptx 6
VPN with Mobile Devices revisited55. DFN Betriebstagung Oktober 2011 BerlinVirtual IP Address Pools & DHCP Support
VPN Routing ohne Virtuelle IP AdresseVPN GatewayFirewall blockt!C1C1G1VPN TunnelG2VPN Clientungeschützt!SIntranetDDefault Gateway18.10.2011, dfn berlin 2011 tech.pptx 8
VPN Routing mit Virtueller IP Adresse Virtuelle IP und DNS Information via IKEv2 Configuration PayloadVPN GatewayV1C1G1V PoolG2VPN TunnelVPN ClientSIntranetRoute: V Pool via G2DICMP RedirectDefault Gateway18.10.2011, dfn berlin 2011 tech.pptx 9
Flüchtiger RAM-basierter IP Address Pool Konfiguration in ipsec.confconn rw.rightsourceip 10.3.0.0/24auto add Statistikipsec leasesLeases in pool 'rw', usage: 2/255, 2 nline'carol@strongswan.org' Referenzieren eines RAM-basierten Poolsconn rw1.rightsourceip %rwauto add18.10.2011, dfn berlin 2011 tech.pptx 10
Persistenter SQL-basierter IP Address Pool I SQLite sec.d/tables.sql Erstellen der SQLite Datenbankcat /etc/ipsec.d/table.sql sqlite3 /etc/ipsec.d/ipsec.db Verbinden mit der SQLite Datenbank# /etc/strongswan.conf - strongSwan configuration filelibhydra {plugins {attr-sql {database sqlite:///etc/ipsec.d/ipsec.db}}}18.10.2011, dfn berlin 2011 tech.pptx 11
Persistenter SQL-basierter IP Address Pool II Definition des Poolsipsec pool --add bigpool --start 10.3.0.1 --end 10.3.0.254 --timeout 48allocating 254 addresses. done. Konfiguration in ipsec.confconn rw.rightsourceip %bigpoolauto add Statistikipsec pool –-statusnamestartendbigpool 10.3.0.110.3.0.254timeout48hsize254online1 ( 0%)usage2 ( 0%)ipsec pool --leases --filter pool bigpoolnamebigpoolbigpooladdress status startendidentity10.3.0.1 online Oct 22 23:13:50 2009carol@strongswan.org10.3.0.2 valid Oct 22 23:14:11 2009 Oct 22 23:14:25 2009 dave@strongswan.org18.10.2011, dfn berlin 2011 tech.pptx 12
VPN Gateway als ARP und DHCP Proxy VPN Gateway verlangt vom DHCP Server lokale IP Adresseund sendet sie via IKEv2 Configuration Payload an VPN Client.VPN GatewayL1C1G1VPN TunnelL1G2LokalesLANVPN ClientL PoolSDARP BroadcastsDHCP Server VPN Gateway beantwortet stellvertretend für VPN Client ARP Anfragen.Dadurch werden IP Pakete an den VPN Client automatisch getunnelt.18.10.2011, dfn berlin 2011 tech.pptx 13
strongSwan SOHO Lösung für Windowsnetzewww.revosec.ch18.10.2011, dfn berlin 2011 tech.pptx 14
VPN with Mobile Devices revisited55. DFN Betriebstagung Oktober 2011 BerlinHigh Availability mit ClusterIP
strongSwan High-Availability ArchitekturIntranetPlainSecurity Gateway 1IKE/IPsec SA SyncSocketHA FailoverPluginBus IFBus IFHA FailoverPluginHA SyncPluginSocketSocketBus IFSocketSocketBus IFIKEv2 charonDaemonHeartbeatDaemonHeartbeatDaemonIKEv2 charonDaemonSocketSocketSocketKernel IFIKEXFRMIPsec Policies / IPsec SAs eth1Linux NetlinkClusterIPeth2eth0eth1ESPeth2Bus IFBus IFSocketKernel IFSocketXFRMIKEIKE/IPsec SA SyncHA SyncPluginSecurity Gateway 2IPsec Policies / IPsec SAsLinux NetlinkClusterIPeth0ESPInternet18.10.2011, dfn berlin 2011 tech.pptx 16
Lösungsansatz Die äusseren eth0 und inneren eth1 Interfaces von SG1 und SG2teilen sich je eine Phantom IP Adresse mit zugehöriger MulticastMAC Adresse. Dadurch erhalten beide SGs alle verschlüsselten ESP Pakete auf eth0und synchronisieren so ständig die Anti-Replay Sequenznummern. Auf der Basis von ClusterIP (Hash über Source IP und SPI des ESPPackets) entscheidet jeder SG für welche IPsec SAs er zuständig ist. ClusterIP (Hash über Destination IP und SPI der IPsec SA) wird auchausgangsseitig auf die Klartextpakete von eth1 angewendet. Für IKEv2 ist nur ein Master SG zuständig. Alle IKEv2 und ESPSchlüssel werden auf dem Slave SG gespiegelt. Fällt ein SG aus, übernimmt der andere sofort sämtliche IPsec SAs.Fällt der Master SG aus, übernimmt sofort der Slave SG sofort dieIKEv2 Verbindungen mit quasi-synchronisierten Sequenznummern.18.10.2011, dfn berlin 2011 tech.pptx 17
VPN with Mobile Devices revisited55. DFN Betriebstagung Oktober 2011 BerlinTrusted Network Connect (TNC) &Platform Trust Service (PTS)
TNC Policy EnforcementallowPolicyEnforcement PointTNC ServerCorporate NetworkblockisolateHost withTNC ClientPolicy k10.2.0.0/16Source: Jörg Vieweg, FH Hannover18.10.2011, dfn berlin 2011 tech.pptx 19
strongSwan Konfiguration auf der PEP Seiteconn rw-allowrightgroups allowleftsubnet 10.1.0.0/16also rw-eapauto addconn rw-isolaterightgroups isolateleftsubnet 10.2.0.0/16also rw-eapauto addconn rw-eapleft 192.168.0.1leftcert moonCert.pemleftid @moon.strongswan.orgleftauth eap-ttlsleftfirewall yesrightauth eap-radiusrightid *@strongswan.orgrightsendcert neverright %any18.10.2011, dfn berlin 2011 tech.pptx 20
IF-PEP Protokoll auf dem strongSwan T]04[NET]04[ENC]04[IKE]04[IKE]04[IKE]received RADIUS Access-Accept from server '10.1.0.10'received RADIUS attribute Tunnel-Type: tag 0, value 9received RADIUS attribute Filter-Id: 'allow'RADIUS authentication of 'carol@strongswan.org' successfulEAP method EAP TTLS succeeded, MSK establishedgenerating IKE AUTH response 11 [ EAP/SUCC ]sending packet: from 192.168.0.1[4500] to 192.168.0.100[4500]received packet: from 192.168.0.100[4500] to 192.168.0.1[4500]parsed IKE AUTH request 12 [ AUTH ]authentication of 'carol@strongswan.org' with EAP successfulauthentication of 'moon.strongswan.org' (myself) with EAPIKE SA rw-allow[1] established 100[carol@strongswan.org]02[CFG] received RADIUS Access-Accept from server '10.1.0.10'02[IKE] received RADIUS attribute Tunnel-Type: tag 0, value 902[IKE] received RADIUS attribute Filter-Id: 'isolate'02[IKE] RADIUS authentication of 'dave@strongswan.org' successful02[IKE] EAP method EAP TTLS succeeded, MSK established02[ENC] generating IKE AUTH response 11 [ EAP/SUCC ]02[NET] sending packet: from 192.168.0.1[4500] to 192.168.0.200[4500]01[NET] received packet: from 192.168.0.200[4500] to 192.168.0.1[4500]01[ENC] parsed IKE AUTH request 12 [ AUTH ]01[IKE] authentication of 'dave@strongswan.org' with EAP successful01[CFG] constraint check failed: group membership required01[CFG] selected peer config 'rw-allow' inacceptable01[CFG] switching to peer config 'rw-isolate‚01[IKE] authentication of 'moon.strongswan.org' (myself) with EAP01[IKE] IKE SA rw-isolate[2] established 200[dave@strongswan.org]18.10.2011, dfn berlin 2011 tech.pptx 21
Network Endpoint Assessment (RFC ectors(1 . 1 . K)(1(1.K)K)NEA ClientPARFC 5792PA-TNCPBRFC lectorsCollectorsValidators(1 . 1 . K)(1(1.K)K)NEA Server18.10.2011, dfn berlin 2011 tech.pptx 22
strongSwan als TNC Client und TNC ServerRFC 5792RFC 579318.10.2011, dfn berlin 2011 tech.pptx 23
strongSwan als TNC MAP 1, dfn berlin 2011 tech.pptx 24
Danke für 2011, dfn berlin 2011 tech.pptx 25
DHCP Server G2 D VPN Tunnel L Pool L1 ARP Broadcasts L1 VPN Gateway verlangt vom DHCP Server lokale IP Adresse und sendet sie via IKEv2 Configuration Payload an VPN Client. VPN Gateway beantwortet stellvertretend für VPN Client ARP Anfragen. Dadurch werden IP Pakete an den VPN Client automatisch getunnelt.
