VPN zwischen einer Endian FW und Checkpoint NG55

[nice2cu]

Hi @ all!

Eine kleine Filiale von uns betreibt eine Endian FW (Community release 2.1.2) mit IPSEC (Openswan 2.4.7))

Hier am zentralen Standort betreiben wir eine CP Firewall (This is Check Point VPN-1(TM) & FireWall-1(R) NG with Application Intelligence (R55) HFA_18, Hotfix 771 - Build 011)auf einer SecureGuard (Linux 2.4.18-5)

Jetzt meine Frage, seit 3 Tagen verusche ich einen Tunnel zwischen den beiden aufzubauen.
Keyexchange funktioniert und die Checkpoint glaubt auch das der Tunnel zwischen den beiden GW steht
Wenn ich das Netz auf der Gegenseite zu Pingen versuche kommen plötzlich die Fehlermeldungen:
IKE: Quick Mode Received Notification from Peer: invalid id information
IKE: Quick Mode Received Notification from Peer: invalid message id

Von der Endian Seite ist es mir überhaupt nicht möglich einen Ping in das entfernte Netz abzusetzen (ich sehe nichts im Firewalllog der CP)

Diverse Konfigurationen in den ipsec.conf haben nur minimale Veränderungen gebracht.

Jetzt meine Frage, ist es überhaupt möglich unter dieser Konstellation einen funktionierende VPN zu initieren?

Wenn Nein, gibt es eine (aktuelle) Linux Distribution in Form eines GW/Firewall Packages mit der ich zwischen den beiden eine funktionierende VPN Strecke aufbauen kann.
Ich habe diverse Teilanleitungen gefunden wo es zumindest mit FreeS/WAN und CP NG(X) gehen soll.
Diese Konfigs habe ich annähernd (sofern es möglich war) nachvollzogen und wieder nichts, kein funtionierendes VPN!

Hier eine der vielfältigsten Logauszüge der Endian:
(IKE: Quick Mode Received Notification from Peer: invalid id information)
und
(IKE: Quick Mode Received Notification from PEer: invalid message id)
Die Endian(Openswan) meldet:
(cannot respond to IPsec SA request because no connection is known for 192.168.120.0/24===2xx.xxx.xxx.245...2xx.xxx.xxx.242)
und
(sending encrypted notification INVALID_ID_INFORMATION to 2xx.xxx.xxx.242:500)
und
(Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xc7c73d69 (perhaps this is a duplicated packet))
und
(sending encrypted notification INVALID_MESSAGE_ID to 2xx.xxx.xxx.242:500)

Weiters fällt mir auf das der Tunnel aus Sicht der Openswan aus Sicht der grafischen Oberfläche mit einem Grünen "offen" steht im Logfile aber dies zu finden ist.
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: initiating Main Mode
Feb 28 09:34:43 ipsec__plutorun: 104 "sbgSENECsbg" #1: STATE_MAIN_I1 initiate
Feb 28 09:34:43 ipsec__plutorun ...could not start conn "sbgSENECsbg"
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: STATE_MAIN_I2: sent MI2, expecting MR2
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: I did not send a certificate because I do not have one.
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: STATE_MAIN_I3: sent MI3, expecting MR3
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: Main mode peer ID is ID_IPV4_ADDR: '2xx.xxx.xxx.242'
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1024}
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #1: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#1}
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #2: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Feb 28 09:34:43 pluto[381] "sbgSENECsbg" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xbda5f3ac <0xb7e6d9a6 xfrm=3DES_0-HMAC_MD5 NATD=none DPD=none}

Hier die ipsec.conf der Endian:
version 2

config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
uniqueids=yes
nat_traversal=no
virtual_private=%v4:172.16.0.0/12,%v4:192.168.120.0/24,%v4:!10.132.100.0/24

conn %default
keyingtries=%forever
disablearrivalcheck=no

conn sbgSENECsbg
right=2xx.xxx.xxx.245
rightsubnet=192.168.120.0/24
rightnexthop=%defaultroute
left=2xx.xxx.xxx.242
leftsubnet=10.132.100.0/24
leftnexthop=%defaultroute
keyexchange=ike
aggrmode=no
auth=esp
ike=3des-md5
esp=3des-md5
pfs=no
compress=no
rekey=yes
ikelifetime=8h
keylife=8h
dpddelay=30
dpdtimeout=120
dpdaction=hold
authby=secret
auto=start

conn block
auto=ignore

conn private
auto=ignore

conn private-or-clear
auto=ignore

conn clear-or-private
auto=ignore

conn clear
auto=ignore

conn packetdefault
auto=ignore

Vielleicht hat ja hier jemand eine Idee was ich falsch gemacht habe! :-(

[mhauser]

Hallo nice2all,

erstmal herzlich Willkommen hier im Forum.
Openswan kann eine VPN Verbindung mit CheckPoint aufbauen. Hier liegt es lediglich an der Konfiguration damit das funktioniert.
Ich habe deine Konfiguration in einer VMware nachgestellt, lediglich auf der CheckPoint Seite habe ich ein aktuelles Release verwendet. Dies spielt aber erstmal keine Rolle.
Die EndianFW hat als externe IP 212.253.6.245, lokales Netz 192.168.120.0/255.255.255.0
Die CheckPoint hat als externe IP 212.253.6.242, lokales Netz 10.132.100.0/255.255.255.0

Unter Endian hab ich folgendes eingestellt:
Unter VPN/IPSec: LocalVPN/Hostname die externe IP-Adresse der Endian-FW 212.253.6.245
Die Konfiguration an sich:
Name: splat
Endian firewall side: left
Local Subnet: 192.168.120.0/255.255.255.0
Remote Host/IP: 212.253.6.242
Remote subnet: 10.132.100.0/255.255.255.0
Remark: connect-to-cp
Enabled: aktiviert.
Use a Pre-Shared Key: 123456789 (hier natürlich ein sicheres Passwort mit Sonderzeiche usw. verwenden)
Dann auf Advanced geklickt:
IKE Encryption: AES (128 bit) und 3DES aktiviert (dies ist so Standard, sollte man auf AES256 stellen)
IKE Integrity: MD5 und SHA1
IKE Lifetime: 1h (Standard bei Openswan)
IKE Grouptype: MODP-1024
ESP Encryption: AES (128 bit) und 3DES aktiviert
ESP Integrity: MD5 und SHA1
ESP Keylife: 8h
ESP Grouptype: Phase1Group
Use only proposed settings. aktiviert
Das ganze dann mit save gesichert.

Nun die CheckPoint Seite.
Ich hab ich ein Interoperable Devices für die Endian Firewall angelegt.
Unter IP-Adress ist die externe IP Adresse 212.253.6.245 eingetragen.
Unter Topology ist die externe sowie die interne Netze angelegt.
Unter VPN Domain wieder manual defined und dort das Netzobjekt 192.168.120.0/24 ausgewählt.
Bei VPN auf traditional mode configuration und Pre-Shared-Secrets aktiviert und dort das gleiche secret eingestellt: 123456789
Mit OK das ganze speichern.
Unter dem Reiter VPN Manager eine neue Star Community angelegt.
Als Center Gateway ist das CheckPoint Gateway ausgewählt.
Unter Satellite Gateway das interoperable Device, also die Endian Firewall.
Unter VPN Properties habe ich beide mal AES128 und SHA1 ausgewählt. (Für Phase1 und Phase2)
Bei Advanced Settings/Advanced VPN Properties:
Phase1: Diffi-Hellman-Group: Group2 1024 bit
Und 480 Minuten.
Bei Phase2 sind die 3600 Sekunden geblieben.
Mit OK gespeichert.

Beim CheckPoint Gateway die externe IP-Adresse eingetragen sein (Network Objects/CheckPoint CheckPoint Gateway Properties
Ebenso muss unter Check Point Products VPN aktiviert sein.
Unter Topology VPN Domain habe ich auf manual defind gestellt und dort das Netzobjekt für 10.132.100.0/24 ausgewählt.
Mit OK gespeichert.

Danach wurde dann der Tunnel aufgebaut.
Dies sieht man auch schön im LOG der CheckPoint.
Danach mit einem Client aus dem encryption Netz von der CheckPoint (10.132.100.2) das interne Interface der EndianFW angepingt (192.168.120.1).

Bitte nochmal die Einstellungen vergleichen. Für Phase1 und Phase2. Daran hakt es meistens.

Bis dann 

Michael

[nice2cu]

Hallo Michael!

Zuerst mal Dank für Deine Mühe(n).

Ich habe das jetzt bei mir ebenso nochmals nachgestellt.
Um ganz sicher zu sein habe ich auch die Endian frisch installiert und ebenso konfiguriert wie du es getan hast.
Einziger Unterschied, ich habe überall AES-256 genommen da ich bei der späteren Konfiguration auf der CP Seite beim VPN Object in den VPN Porperties hier nur AES-246 zur Auswahl habe. (witziger Weise b ei Phase 2 steht es mir zur Verfügung)

Einen weiteren Unterschied zu Deiner Konfig habe ich in der VPN Star Konfiguratin unter dem Punkt Shared Secret und dort das Hackerl "use only shared secret for all external members" gesetzt da sonst beim Aufbau der FW Regel folgende Fehlermeldung(en) kommen.
IKE: Main Mode Failed to match proposal: AES-256, SHA1, Pre-shared secret, Group 2 (1024 bit)
IKE: Main Mode Sent Notification to Peer: no proposal chosen

Wenn ich wie gesagt dort das Hackerl habe und das Shared Secret angebe baut sich der Tunnel laut FW Log auf!
Siehe:
IKE: Main Mode completion.
IKE: Quick Mode Sent Notification: Responder Lifetime
IKE: Quick Mode completion
IKE IDs: subnet: 10.132.100.0 (mask= 255.255.255.0) and subnet: 192.168.120.0 (mask= 255.255.255.0)

(soweit war ich bereits schon immer bei meinen diversen Konfigurationen)

Wenn ich jedoch von der Checkpoint auf eine interne Adresse des gegenüberliegenden GW pinge kommen wieder folgende Meldungen:
IKE: Quick Mode Received Notification from Peer: invalid id information
IKE: Quick Mode Received Notification from Peer: invalid message id

    

Vielleicht sollte ich auch noch erwähnen das ich noch einen VPN ERFOLGREICH zu einer Checkpoint FW-1 (V4.1) betreibe.

Irgendwie dreh ich mich egal welche Konfiguration probiere im Kreis und komm zu keinem Ende.

Lg, Robert

[nice2cu]

Was ich festgestellt habe, die Checkpoint geht davon aus das der Tunnel steht der dann in der Folge diese Fehlermeldung siehe oben auslöst.
Wenn ich auf der Endian Seite ipsec verify eingebe sehe ich das der Tunnel nicht steht:

root@senecwall:/var/efw/vpn # ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan 2.4.7 (klips)
Checking for IPsec support in kernel                            [OK]
Checking for RSA private key (/etc/ipsec.secrets)               [DISABLED]
  ipsec showhostkey: no default key in "/etc/ipsec.secrets"
Checking that pluto is running                                  [OK]
Two or more interfaces found, checking IP forwarding            [OK]
Checking NAT and MASQUERADEing                             
Checking tun0x1016@212.xxx.xxx.242 from 192.168.120.0/24 to 10.132.100.0/24     [FAILED]
  CUSTOMPOSTROUTING from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel 0.0.0.0/0 -> 10.132.100.0/24
        [FAILED]
  REVERSENAT from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel 0.0.0.0/0 -> 10.132.100.0/24
        [FAILED]
  REDNAT from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel 0.0.0.0/0 -> 10.132.100.0/24
        [FAILED]
  POSTPORTFW from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel 0.0.0.0/0 -> 10.132.100.0/24
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

 

[nice2cu]

noch eins: Logfile beim Starten des Tunnels auf der Endian:
Mar  3 16:32:39 efw-1204555790 pluto[4843]: forgetting secrets
Mar  3 16:32:39 efw-1204555790 pluto[4843]: loading secrets from "/etc/ipsec.secrets"
Mar  3 16:32:39 efw-1204555790 pluto[4843]: added connection description "sbgSENECsbg"
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: initiating Main Mode
Mar  3 16:32:39 efw-1204555790 sudo:   nobody : TTY=unknown ; PWD=/home/httpd/cgi-bin ; USER=root ; COMMAND=/usr/sbin/ipsec auto --status
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: STATE_MAIN_I2: sent MI2, expecting MR2
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: I did not send a certificate because I do not have one.
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: STATE_MAIN_I3: sent MI3, expecting MR3
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: Main mode peer ID is ID_IPV4_ADDR: '212.xxx.xxx.242'
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #57: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#56}
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #57: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #57: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #57: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #57: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x97ddc262 <0x0cdaf750 xfrm=AES_256-HMAC_SHA1 NATD=none DPD=none}

[mhauser]

Hallo Robert,

Du schreibst Du pingst von der CheckPoint, probier es doch bitte mal aus dem encryption Netz.
Hier verhält sich Openswan und CheckPoint etwas anders.  Bei Openswan ist die externe IP Adresse nicht bestandteil der enryption Zone.
Ich bin mir ziemlich sicher das dieser Ping funktionieren wird.

Bis dann

Michael

[nice2cu]

ne du, verhält sich genauso.
Ping läuft ins Nirana.
Fehlermeldungen sind die gleichen.

irgendwas stimmt zumindest auf der Endian Seite ned:
siehe nochmals Auszug ipsec verify
Checking tun0x1016@212.xxx.xxx.242 from 192.168.120.0/24 to 10.132.100.0/24     [FAILED]
  CUSTOMPOSTROUTING from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel 0.0.0.0/0 -> 10.132.100.0/24
        [FAILED]
  REVERSENAT from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel 0.0.0.0/0 -> 10.132.100.0/24
        [FAILED]
  REDNAT from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel 0.0.0.0/0 -> 10.132.100.0/24
        [FAILED]
  POSTPORTFW from 0.0.0.0/0 to 0.0.0.0/0 kills tunnel 0.0.0.0/0 -> 10.132.100.0/24

[mhauser]

Hallo Robert,

bei mir ist auf der Endian FW auch kein tun device vorhanden. Deswegen sieht die Ausgabe von ipsec verify bei mir identisch aus.

nachdem auf der Endian im Log steht:

Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #56: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}

und danach ein

Mar  3 16:32:39 efw-1204555790 pluto[4843]: "sbgSENECsbg" #57: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x97ddc262 <0x0cdaf750 xfrm=AES_256-HMAC_SHA1 NATD=none DPD=none}

muss die VPN Verbindung stehen.

Ebenso das gleiche auf der CheckPoint Seite:

IKE: Main Mode completion.
IKE: Quick Mode Sent Notification: Responder Lifetime
IKE: Quick Mode completion
IKE IDs: subnet: 10.132.100.0 (mask= 255.255.255.0) and subnet: 192.168.120.0 (mask= 255.255.255.0)

Hast Du das Routing überprüft?
Entweder default Route auf beiden FW oder eben Netz Routen, z.b. auf der Endian muss das interne Netz von der CheckPoint (10.132.100.0/255.255.255.0
) nach extern geroutet werden und umgekehrt?
Lässt das Firewall Regelwerk den Ping zu aus den Netzen?
Wie sieht die Ausgaben bei Endian von ipsec auto --status aus?
Während der PING läuft auf der Endian/CheckPoint ein tcpdump -i (externes IF) -f esp ausführen, dabei sollte das in etwas so aussehen:
11:00 :02.195387 IP 212.253.6.242 > 212.253.6.245: ESP(spi=0xbcefd682,seq=0xea)
Falls auf der CheckPoint FW das Log aktiviert ist so sollte hier ein enrypt/decrypt zu sehen sein.

Bis dann
Michael

[nice2cu]

Also Konfig sieht so aus:
Defaultrouter in das Internet für CP und Endian ist 212.152.174.241 (derzeit zum testen hier im Hauslan)
Auf beiden Seiten komme ich von den Clientnetzen in das Internet:
Route sieht bevor der Tunnel steht so aus:
root@senecwall:/var/efw/vpn # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
212.xxx.xxx.240 0.0.0.0         255.255.255.248 U     0      0        0 eth0
212.xxx.xxx.240 0.0.0.0         255.255.255.248 U     0      0        0 ipsec0
192.168.120.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
0.0.0.0         212.xxx.xxx.241 0.0.0.0         UG    0      0        0 eth0

Nachdem der Tunnel steht so:
root@senecwall:/var/efw/vpn # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
212.xxx.xxx.240 0.0.0.0         255.255.255.248 U     0      0        0 eth0
212.xxx.xxx.240 0.0.0.0         255.255.255.248 U     0      0        0 ipsec0
10.132.100.0    212.xxx.xxx.241 255.255.255.0   UG    0      0        0 ipsec0
192.168.120.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
0.0.0.0         212.xxx.xxx.241 0.0.0.0         UG    0      0        0 eth0


ipsec auto --status
000 interface ipsec0/eth0 212.xxx.xxx.245
000 interface ipsec0/eth0 212.xxx.xxx.245
000 %myid = (none)
000 debug none
000 
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 
000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,6,36} trans={0,6,72} attrs={0,6,48}
000 
000 "sbgSENECsbg": 192.168.120.0/24===212.xxx.xxx.245---212.xxx.xxx.241...212.xxx.xxx.241---212.xxx.xxx.242===10.132.100.0/24; erouted; eroute owner: #6
000 "sbgSENECsbg":     srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec _updown;
000 "sbgSENECsbg":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "sbgSENECsbg":   policy: PSK+ENCRYPT+TUNNEL+UP; prio: 24,24; interface: eth0; encap: esp;
000 "sbgSENECsbg":   dpd: action:hold; delay:30; timeout:120;
000 "sbgSENECsbg":   newest ISAKMP SA: #5; newest IPsec SA: #6;
000 "sbgSENECsbg":   IKE algorithms wanted: BLOWFISH(7)_256-SHA1(2)-2, flags=strict
000 "sbgSENECsbg":   IKE algorithms found:  BLOWFISH(7)_256-SHA1(2)_160-2,
000 "sbgSENECsbg":   IKE algorithm newest: AES_CBC_256-SHA1-MODP1024
000 "sbgSENECsbg":   ESP algorithms wanted: AES(12)_256-SHA1(2), flags=strict
000 "sbgSENECsbg":   ESP algorithms loaded: AES(12)_256-SHA1(2), flags=strict
000 "sbgSENECsbg":   ESP algorithm newest: AES_256-HMAC_SHA1; pfsgroup=<N/A>
000 
000 #6: "sbgSENECsbg":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 26770s; newest IPSEC; eroute owner
000 #6: "sbgSENECsbg" used 999s ago; esp.1fed2663@212.xxx.xxx.242 esp.cedeea89@212.xxx.xxx.245 tun.1006@212.xxx.xxx.242 tun.1005@212.xxx.xxx.245
000 #5: "sbgSENECsbg":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1508s; newest ISAKMP; nodpd
000 

Hab auf beiden Firewalls Regeln die alles zulassen!
Sehe auch im Log nichts geblocktes.

[mhauser]

Hallo Robert,
ich vermute hier liegt noch ein Fehler in der Phase 2 Konfiguration vor.
Wenn Du aus dem internen Netz hinter der CP FW einen Ping in das internet Netz der Endian FW absetzt erscheint dann im CP Log ein encrypt Paket?
Oder wird hier versucht das Paket im Klartext zu versenden?
Wie sieht die Konfiguration seitens CP für die enrcyption Zone aus?

Danke

Michael

[nice2cu]

 

Wahnsinn, so viel Zeit habe ich noch nie für einen VPN Tunnel ver..... tan.

Zuerst Tunnel neu aufbauen Meldungen im CP Log:
IKE: Main Mode completion.
IKE: Quick Mode Sent Notification: Responder Lifetime
IKE: Quick Mode completion
IKE IDs: subnet: 10.132.100.0 (mask= 255.255.255.0) and subnet: 192.168.120.0 (mask= 255.255.255.0)


Dann pinge ich von einem PC im CP NET (10.132.100.106) einen Accespoint im Endiannetz (192.168.120.2)
CP LOG:
IKE: Quick Mode Received Notification from Peer: invalid id information
IKE: Quick Mode Received Notification from Peer: invalid message id
IKE: Quick Mode Received Notification from Peer: invalid message id
IKE: Quick Mode Received Notification from Peer: invalid message id
.
.
.
encryption failure: no response from peer.
.
.
ICMP: Echo Request ICMP Type: 8 ICMP Code: 0 encryption fail reason: Packet is dropped because there is no valid SA - please refer to solution sk19423 in SecureKnowledge Database for more information

Für mich sieht es nach wie vor so aus als ob von der Endian aus der Tunnel nicht steht und deswegen diese auch nicht oder falsch auf die verschlüsselten Packete reagiert.

Wie gesagt, wenn ich von einem PC aus dem Endiannetz (192.168.120.200) einen Ping oder ein Telnet auf die CP VPN Adresse 10.132.100.1 aufsetze sehe ich im CP Log einen Eintrag. Diese Kommunikatinspackete sind unverschlüsselt (Source 192.168.120.200)
ICMP: Echo Request ICMP Type: 8 ICMP Code: 0 message_info: Address spoofing
message_info: Address spoofing (bei Telnet)

LG, Robert

[nice2cu]

...schön langsam glaube ich das es mit der CP Version zu tun hat.

Hier ein Thread: http://archives.free.net.ph/message/20041125.160305.5ebea20e.en.html

 

[mhauser]

Hallo Robert,

nein. Ich hab es gerade mit einer R55 HFA_18 probiert. Auch da funktioniert es.
Es liegt an der Einstellung von der Phase2. Da stimmt was nicht mit der VPN Domain (encryption Netze).
Evtl. hast Du hier mehrere Netze und/oder auch hosts eingetragen. Hier versucht CheckPoint diese zusammen zufassen (supernetting).
Damit kommt die Gegenstelle dann nicht mit klar. Schau Dir das bitte nochmal ganz genau an was die Phase2 Einstellungen betrifft.

servus
Michael

[mhauser]

Hallo Robert,

mir ist noch was eingefallen.
Wie sieht die Einstellung bei dem CheckPoint Getway unter VPN/VPN Advanced aus. Ist dort ein Haken bei Support Key Exchange for subnets?

Danke

Michael

[nice2cu]

Ich weiß nicht ob ich diese Einstellungen auch schon mal probiert hab.
hab es jetzt auf jeden Fall man druchgespielt, beide Varianten.
Mal auf dem CP & Endian Objekt aktiviert und deaktiviert.

nix is :-(

Ich hab mittlerweile die Beta3 der Endian instlaliert.
Ein wenig anderes Verhalten abe rim Großen und Ganzen ähnlich.
Ich kann von beiden Seiten jetzt die Phase2 auslösen die zu dem invalid message id Fehler führen.