[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
Archivio: openbsd@sikurezza.org Soggetto: [openbsd] Vpn su molpteplici lan Mittente: Andrea Lissandrin Data: Tue, 12 Sep 2006 20:39:58 +0200 (CEST)
Salve, qualche anno fa abbiamo creato una vpn tra una box openbsd ed un firewall sonicwall pro. Tutto funziona regolarmente, le due classi private si trovano perfettamente in rete, qualche problema solo al riavvio di una delle due, dobbiamo riavviare anche l'altra, ma questo accade raramente. Il problema che ci troviamo ad affrontare ora, essendo stata aggiunta una classe dietro al sonicwall è questo. Dopo un riavvio, se dalle reti locali dietro al sonicwall facciamo una connessione verso le reti dietro alla box openbsd tutto funziona ed inizia a funzionare anche in senso contrario, se proviamo a farlo dalle reti dietro alla box openbsd, riusciamo a contattare solo una rete di Sonicwall, sempre con il dubbio che la connessione sia inizializzata comunque dal sonicwall magari a causa di qualche broadcast. Dai tools di diagnostica di nostra conoscenza, abbiamo visto che openbsd non ruota nel tunnel i pacchetti per la nuova rete remota, nonostante sia dichiarata all'interno di isakmpd.conf come [Net-remote1], la prima è la [Net-remote]. Abbiamo provveduto manualmente a creare con ipsecadm il tunnel e con i comandi ipsecadm show e netstat -rn abbiamo verificato che sono attivi e con i parametri uguali agli altri che funzionano, sia in che out. Il risultato qui è cambiato, in quanto i pacchetti non escono più ovviamente sulla rete internet ma vengono bloccati sulla box bsd. Sul firewall Sonicwall non riscontriamo dai log, nessun errore per questa SA e nemmeno nessun tentativo di instaurare il tunnel. Credo sia doveroso mettere uno schema con esempio per semplificare. ---- | | Sonicwall Pro ---- Lan 192.168.1.0/24 Lan2 192.168.2.0/24 ____ | | Openbsd ---- Lan 192.168.3.0/24 Lan2 192.168.4.0/24 Appena avviati i firewall, dalla rete 3.0 si riesce a fare un ping solo sulla rete 1.0. Dalla rete 1 e 2 invece si riesce ad attivare il tunnel e quindi pingare le reti 3 e 4, da qui inizia a funzionare anche il resto, quindi dalle reti 3 e 4 si raggiungono la 1 e la 2. Il tutto rimane attivo fino al prossimo riavvio. L'unica differenza notata dal risultato del comando ipsecadm show è che a differenza della SA creata manualmente, ci sono due voci in più, srcid e dstid, dove vengono mostrati gli indirizzi pubblici con la notazione /32. A proposito di questi, si legge nel manuale che in mancanza di questo parametro, vengono usati quelli di default, anche negli esempi visti in rete, infatti, non venivano specificati. Non credo che il problema sia relativo al fatto che uno dei due peer sia Sonicwall, la vpn infatti funziona, credo si sia sbagliato qualcosa nel creare il tunnel per la rete secondaria. Grazie in anticipo per il vs. aiuto. Andrea Isakmpd.conf: [General] Retransmits= 5 Exchange-max-time= 120 Listen-on= B.x.y.q policy-file= /etc/isakmpd/isakmpd.policy [Phase 1] A.x.y.q= nodoA [Phase 2] Connections= nomeconnessione [nodoA] Phase= 1 Transport= udp Local-address= B.x.y.q Address= A.x.y.z Configuration= Default-main-mode Authentication= key [nomeconnessione] Phase= 2 ISAKMP-peer= nodoA Configuration= Default-quick-mode Local-ID= Net-remote Remote-ID= Net-local [Net-local] ID-type= IPV4_ADDR_SUBNET Network= 192.168.3.0 Netmask= 255.255.255.0 [Net-local1] ID-type= IPV4_ADDR_SUBNET Network= 192.168.4.0 Netmask= 255.255.255.0 [Net-remote] ID-type= IPV4_ADDR_SUBNET Network= 192.168.1.0 Netmask= 255.255.255.0 [Net-remote1] ID-type= IPV4_ADDR_SUBNET Network= 192.168.2.0 Netmask= 255.255.255.0 [Default-main-mode] DOI= IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-MD5 [Default-quick-mode] DOI= IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-PFS-XF-SUITE [3DES-MD5] ENCRYPTION_ALGORITHM= 3DES_CBC HASH_ALGORITHM= MD5 AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_1024 Life= LIFE_28800_SECS [QM-ESP-3DES-SHA-PFS-XF-SUITE] Protocols= QM-ESP-3DES-SHA-PFS [QM-ESP-3DES-SHA-PFS] PROTOCOL_ID= IPSEC_ESP Transforms= QM-ESP-3DES-SHA-PFS-XF [QM-ESP-3DES-SHA-PFS-XF] TRANSFORM_ID= 3DES ENCAPSULATION_MODE= TUNNEL AUTHENTICATION_ALGORITHM= HMAC_SHA GROUP_DESCRIPTION= MODP_1024 Life= LIFE_600_SECS [LIFE_600_SECS] LIFE_TYPE= SECONDS LIFE_DURATION= 600,450:720 [LIFE_3600_SECS] LIFE_TYPE= SECONDS
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005