IPCop-Forum.de

www.ipcop-forum.de


IPCop-Community
CL-Systems
Home Home   Doku Doku   Links Links   Downloads Downloads
UnIPCop Der (Un)IPCop   IFS IPCop-ForumSpy
CopTime CopTime   Galerie IPCop-Galerie   IPCop Userkarte Userkarte
Aktuelle Zeit: 18.10.2017, 20:15

Alle Zeiten sind UTC+02:00




Ein neues Thema erstellen  Auf das Thema antworten  [ 6 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: Ipsec klappt nicht
BeitragVerfasst: 15.08.2017, 14:28 
Offline
Deputy Sergeant
Themenstarter
Deputy Sergeant

Registriert: 08.02.2016
Beiträge: 45
Hallo zusammen,
ich habe eine Netzt zu Netzt Verbindung mit pre-shared Key eingerichtet.
Leider verbinden sich die beiden Cops nicht.

Ich habe mich an diese Anleitung gehalten:
https://www.andysblog.de/ipcop-ipsec-un ... verbindung

In den Logs habe ich auch Fehlermeldungen, mit denen ich leider nicht weiter kommen.

Gruß
Achim

IPCOP 1
Code:
14:22:07   pluto[1928]   "PreussenTelekom" #7753: received and ignored informational message
14:22:07   pluto[1928]   "PreussenTelekom" #7753: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
14:21:37   pluto[1928]   "PreussenTelekom" #7754: sending encrypted notification INVALID_ID_INFORMATION to x.x.x.x:500
14:21:37   pluto[1928]   "PreussenTelekom" #7754: no suitable connection for peer '192.168.0.94'
14:21:37   pluto[1928]   "PreussenTelekom" #7754: Main mode peer ID is ID_IPV4_ADDR: '192.168.0.94'
14:21:28   pluto[1928]   "PreussenTelekom" #7752: max number of retransmissions (2) reached STATE_MAIN_R2
14:21:27   pluto[1928]   "PreussenTelekom" #7753: received and ignored informational message
14:21:27   pluto[1928]   "PreussenTelekom" #7753: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
14:21:17   pluto[1928]   "PreussenTelekom" #7754: sending encrypted notification INVALID_ID_INFORMATION to x.x.x.x:500
14:21:17   pluto[1928]   "PreussenTelekom" #7754: no suitable connection for peer '192.168.0.94'
14:21:17   pluto[1928]   "PreussenTelekom" #7754: Main mode peer ID is ID_IPV4_ADDR: '192.168.0.94'
14:21:07   pluto[1928]   "PreussenTelekom" #7754: sending encrypted notification INVALID_ID_INFORMATION to x.x.x.x:500
14:21:07   pluto[1928]   "PreussenTelekom" #7754: no suitable connection for peer '192.168.0.94'
14:21:07   pluto[1928]   "PreussenTelekom" #7754: Main mode peer ID is ID_IPV4_ADDR: '192.168.0.94'
14:21:07   pluto[1928]   "PreussenTelekom" #7754: STATE_MAIN_R2: sent MR2, expecting MI3
14:21:07   pluto[1928]   "PreussenTelekom" #7754: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
14:21:07   pluto[1928]   "PreussenTelekom" #7754: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed
14:21:07   pluto[1928]   "PreussenTelekom" #7754: STATE_MAIN_R1: sent MR1, expecting MI2
14:21:07   pluto[1928]   "PreussenTelekom" #7754: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
14:21:07   pluto[1928]   "PreussenTelekom" #7754: responding to Main Mode


IPCOP2
Code:
14:26:47   pluto[3472]   "PreussenTelekomAusfall" #20: received and ignored informational message
14:26:47   pluto[3472]   "PreussenTelekomAusfall" #20: ignoring informational payload, type INVALID_ID_INFORMATION msgid=00000000
14:26:47   pluto[3472]   "PreussenTelekomAusfall" #20: discarding duplicate packet; already STATE_MAIN_I3
14:26:27   pluto[3472]   "PreussenTelekomAusfall" #20: received and ignored informational message
14:26:27   pluto[3472]   "PreussenTelekomAusfall" #20: ignoring informational payload, type INVALID_ID_INFORMATION msgid=00000000
14:26:27   pluto[3472]   "PreussenTelekomAusfall" #20: discarding duplicate packet; already STATE_MAIN_I3
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: received and ignored informational message
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: ignoring informational payload, type INVALID_ID_INFORMATION msgid=00000000
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: STATE_MAIN_I3: sent MI3, expecting MR3
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): i am NATed
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: STATE_MAIN_I2: sent MI2, expecting MR2
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: received Vendor ID payload [RFC 3947] method set to=115
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: received Vendor ID payload [Dead Peer Detection]
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: received Vendor ID payload [Openswan (this version) 2.6.42 ]
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #20: initiating Main Mode to replace #19
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #19: starting keying attempt 2 of an unlimited number
14:26:17   pluto[3472]   "PreussenTelekomAusfall" #19: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
14:25:37   pluto[3472]   "PreussenTelekomAusfall" #19: received and ignored informational message
14:25:37   pluto[3472]   "PreussenTelekomAusfall" #19: ignoring informational payload, type INVALID_ID_INFORMATION msgid=00000000
14:25:37   pluto[3472]   "PreussenTelekomAusfall" #19: discarding duplicate packet; already STATE_MAIN_I3
14:25:17   pluto[3472]   "PreussenTelekomAusfall" #19: received and ignored informational message


Nach oben
   
 Betreff des Beitrags: Re: Ipsec klappt nicht
BeitragVerfasst: 15.08.2017, 14:54 
Offline
VPN-Experte
VPN-Experte
Benutzeravatar

Registriert: 04.02.2007
Beiträge: 260
Wohnort: Landsberg, Bayern, Deutschland
Servus,

könntest du den Inhalt der ipsec.conf und ipsec.secret Dateien beider Cops posten? Aus den Logs entnehme ich das ein Cop hinter einem Router steht, ist das richtig?

Grüße
TwoFace

_________________
Über mich
Guggst du IPSec VPN hinter Routern
Bild


Nach oben
   
 Betreff des Beitrags: Re: Ipsec klappt nicht
BeitragVerfasst: 16.08.2017, 11:39 
Offline
Deputy Sergeant
Themenstarter
Deputy Sergeant

Registriert: 08.02.2016
Beiträge: 45
Hallo TwoFace,
ja einer sitzt hinter einem Router der Telekom. Es ist der lancom 1784. Vermutlich gibt es dort ein Problem mit dem Portweiterleiten.

[img]
http://www.directupload.net/file/d/4816 ... 3f_png.htm
[/img]

Bei dem Ipcop 2 läuft schon erfolgreich eine VPN Verbindung zu einem anderen Ipcop,

Gruß Achim

Ipcop 1

Code:
# Do not modify 'ipsec.conf' directly since any changes you make will be
# overwritten whenever you change IPsec settings using the web interface!
#

version 2.0

config setup
        protostack=netkey
        klipsdebug="none"
        plutodebug="none"
        uniqueids=yes
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.2.0/255.255.255.0,%v4:!192.168.3.0/255.255.255.0,%v4:!192.168.0.1/255.255.255.0

conn %default
        keyingtries=0
        disablearrivalcheck=no
        leftupdown=/usr/local/bin/ipsecupdown.sh

# AusfallVPN
# net-2-net to RED
conn PreussenTelekomAusfall
        left=217.x.x.x.
        leftsubnet=192.168.2.0/255.255.255.0
        right=178.x.x.x
        rightsubnet=192.168.0.1/255.255.255.0
        ike=aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
        esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
        ikelifetime=1h
        keylife=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        pfs=yes
        authby=secret
        auto=start


ipsec.secret :

: RSA /var/ipcop/certs/hostkey.pem
217.x.x.x 178.x.x.x : PSK 'Test123456'


Ipcop 2
Code:
version 2.0

config setup
        protostack=netkey
        klipsdebug="none"
        plutodebug="none"
        uniqueids=yes
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.0.0/255.255.255.0,%v4:!192.168.2.0/255.255.255.0,%v4:!192.168.2.0/255.255.255.0

conn %default
        keyingtries=0
        disablearrivalcheck=no
        leftupdown=/usr/local/bin/ipsecupdown.sh

# copPreussen
# net-2-net to RED
conn copPreussen
        left=178.x.x.x
        leftsubnet=192.168.0.0/255.255.255.0
        right=78.x.x.x
        rightsubnet=192.168.2.0/255.255.255.0
        leftcert=/var/ipcop/certs/hostcert.pem
        rightcert=/var/ipcop/certs/copPreussencert.pem
        ike=aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
        esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
        ikelifetime=1h
        keylife=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        pfs=yes
        authby=rsasig
        leftrsasigkey=%cert
        rightrsasigkey=%cert
        auto=start

# AusfallVPN
# net-2-net to RED
conn PreussenTelekom
        left=178.x.x.x
        leftsubnet=192.168.0.0/255.255.255.0
        right=217.x.x.x.
        rightsubnet=192.168.2.0/255.255.255.0
        ike=aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024





ipsec.secret :

: RSA /var/ipcop/certs/hostkey.pem
178.x.x.x 217.x.x.x : PSK 'Test123456'


Nach oben
   
 Betreff des Beitrags: Re: Ipsec klappt nicht
BeitragVerfasst: 17.08.2017, 08:22 
Offline
Deputy Sergeant
Themenstarter
Deputy Sergeant

Registriert: 08.02.2016
Beiträge: 45
Moin,
bin jetzt wieder ein Stück weiter, der Lancom lässt die Verbindung jetzt durch:
Aber da gibt es wohl Probleme mit der IP von RED 192.168.0.94, ist das richtig ?

Der Netzwerkanschluss von RED geht bei dem Lancom in ETH1. Der Ipcop bezieht seine IP per DHCP für RED vom Lancom und bekommt die 192.168.0.94.
Der IPCOP funktioniert so wunderbar, außer VPN :-(

Gruß

Code:
08:12:41   pluto[2086]   packet from 178.x.x.x:500: initial Main Mode message received on 192.168.0.94:500 but no connection has been authorized with policy=PSK
08:12:41   pluto[2086]   packet from 178.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
08:12:41   pluto[2086]   packet from 178.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 115
08:12:41   pluto[2086]   packet from 178.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115
08:12:41   pluto[2086]   packet from 178.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 115
08:12:41   pluto[2086]   packet from 178.x.x.x:500: received Vendor ID payload [RFC 3947] method set to=115
08:12:41   pluto[2086]   packet from 178.x.x.x:500: received Vendor ID payload [Dead Peer Detection]
08:12:41   pluto[2086]   packet from 178.x.x.x:500: received Vendor ID payload [Openswan (this version) 2.6.42 ]
08:12:01   pluto[2086]   packet from 178.x.x.x:500: initial Main Mode message received on 192.168.0.94:500 but no connection has been authorized with policy=PSK


Nach oben
   
 Betreff des Beitrags: Re: Ipsec klappt nicht
BeitragVerfasst: 17.08.2017, 08:57 
Offline
Deputy Sergeant
Themenstarter
Deputy Sergeant

Registriert: 08.02.2016
Beiträge: 45
wird immer besser, meine ich. :-)
Kann noch mal einer über die Logs schauen, bitte? Da steckt der Fehler den ich nicht sehe.

Ich habe jetzt die zugewiesene IP 192.168.0.94 unter, Öffentliche IP oder FQDN für das ROTE Interface oder <%defaultroute>, eingetragen. Dort stand die Öffentliche ip 217.x.x.x.

Danke!

Ipcop 1:

Code:
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: sending notification PAYLOAD_MALFORMED to 178.x.x.x:4500
08:47:42   pluto[12258]   | 11 18 38 9c f9 02 5f 21 fd e7 f2 37 1b 86 14 49
08:47:42   pluto[12258]   | payload malformed after IV
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: malformed payload in packet
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: next payload type of ISAKMP Hash Payload has an unknown value: 167
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: Dead Peer Detection (RFC 3706): enabled
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1536}
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: new NAT mapping for #7, was 178.x.x.x:500, now 178.x.x.x:4500
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: Main mode peer ID is ID_IPV4_ADDR: '178.x.x.x'
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: STATE_MAIN_R2: sent MR2, expecting MI3
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): i am NATed
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: STATE_MAIN_R1: sent MR1, expecting MI2
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
08:47:42   pluto[12258]   "PreussenTelekomAusfall" #7: responding to Main Mode
08:47:42   pluto[12258]   packet from 178.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
08:47:42   pluto[12258]   packet from 178.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 115
08:47:42   pluto[12258]   packet from 178.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115
08:47:42   pluto[12258]   packet from 178.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 115
08:47:42   pluto[12258]   packet from 178.x.x.x:500: received Vendor ID payload [RFC 3947] method set to=115
08:47:42   pluto[12258]   packet from 178.x.x.x:500: received Vendor ID payload [Dead Peer Detection]
08:47:42   pluto[12258]   packet from 178.x.x.x:500: received Vendor ID payload [Openswan (this version) 2.6.42 ]
08:46:02   pluto[12258]   "PreussenTelekomAusfall" #4: DPD: Restarting Connection
08:46:02   pluto[12258]   "PreussenTelekomAusfall" #4: DPD: No response from peer - declaring peer dead
08:46:01   pluto[12258]   "PreussenTelekomAusfall" #6: Informational Exchange message must be encrypted
08:45:51   pluto[12258]   "PreussenTelekomAusfall" #5: rekeying state (STATE_MAIN_I3)
08:45:51   pluto[12258]   "PreussenTelekomAusfall" #5: rekeying state (STATE_MAIN_I3)
08:45:51   pluto[12258]   "PreussenTelekomAusfall" #3: DPD: Restarting Connection
08:45:51   pluto[12258]   "PreussenTelekomAusfall" #3: DPD: No response from peer - declaring peer dead
08:45:31   pluto[12258]   "PreussenTelekomAusfall" #6: sending notification PAYLOAD_MALFORMED to 178.x.x.x:4500
08:45:31   pluto[12258]   | 65 59 bd ef e6 d7 7c 7c c1 e2 4d 90 1e 1e 9b 4e
08:45:31   pluto[12258]   | payload malformed after IV




Ipcop 2
Code:
08:48:12   pluto[1928]   | payload malformed after IV
08:48:12   pluto[1928]   "PreussenTelekom" #9128: malformed payload in packet
08:48:12   pluto[1928]   "PreussenTelekom" #9128: next payload type of ISAKMP Hash Payload has an unknown value: 137
08:47:42   pluto[1928]   "PreussenTelekom" #9128: received 1 malformed payload notifies
08:47:42   pluto[1928]   "PreussenTelekom" #9128: sending encrypted notification INVALID_ID_INFORMATION to 217.x.x.x:4500
08:47:42   pluto[1928]   "PreussenTelekom" #9128: we require peer to have ID '217.x.x.x', but peer declares '192.168.0.94'
08:47:42   pluto[1928]   "PreussenTelekom" #9128: Main mode peer ID is ID_IPV4_ADDR: '192.168.0.94'
08:47:42   pluto[1928]   "PreussenTelekom" #9128: received Vendor ID payload [CAN-IKEv2]
08:47:42   pluto[1928]   "PreussenTelekom" #9128: STATE_MAIN_I3: sent MI3, expecting MR3
08:47:42   pluto[1928]   "PreussenTelekom" #9128: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
08:47:42   pluto[1928]   "PreussenTelekom" #9128: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed
08:47:42   pluto[1928]   "PreussenTelekom" #9128: STATE_MAIN_I2: sent MI2, expecting MR2
08:47:42   pluto[1928]   "PreussenTelekom" #9128: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
08:47:42   pluto[1928]   "PreussenTelekom" #9128: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
08:47:42   pluto[1928]   "PreussenTelekom" #9128: received Vendor ID payload [RFC 3947] method set to=115
08:47:42   pluto[1928]   "PreussenTelekom" #9128: received Vendor ID payload [Dead Peer Detection]
08:47:42   pluto[1928]   "PreussenTelekom" #9128: received Vendor ID payload [Openswan (this version) 2.6.42 ]
08:47:32   pluto[1928]   "PreussenTelekom" #9128: initiating Main Mode to replace #9127
08:47:32   pluto[1928]   pending Quick Mode with 217.x.x.x "PreussenTelekom" took too long -- replacing phase 1
08:46:07   pluto[1928]   "PreussenTelekom" #9126: max number of retransmissions (2) reached STATE_MAIN_R2
08:46:01   pluto[1928]   "PreussenTelekom" #9127: sending notification PAYLOAD_MALFORMED to 217.x.x.x:4500
08:46:01   pluto[1928]   | 5c 2a e8 21 fc e1 9b 57 39 8d 7a 60 94 93 3f bd
08:46:01   pluto[1928]   | payload malformed after IV
08:46:01   pluto[1928]   "PreussenTelekom" #9127: malformed payload in packet
08:46:01   pluto[1928]   "PreussenTelekom" #9127: next payload type of ISAKMP Hash Payload has an unknown value: 249
08:45:31   pluto[1928]   "PreussenTelekom" #9127: received 1 malformed payload notifies
08:45:31   pluto[1928]   "PreussenTelekom" #9127: sending encrypted notification INVALID_ID_INFORMATION to 217.x.x.x:4500
08:45:31   pluto[1928]   "PreussenTelekom" #9127: we require peer to have ID '217.x.x.x', but peer declares '192.168.0.94'
08:45:31   pluto[1928]   "PreussenTelekom" #9127: Main mode peer ID is ID_IPV4_ADDR: '192.168.0.94'
08:45:31   pluto[1928]   "PreussenTelekom" #9127: received Vendor ID payload [CAN-IKEv2]
08:45:31   pluto[1928]   "PreussenTelekom" #9127: STATE_MAIN_I3: sent MI3, expecting MR3
08:45:31   pluto[1928]   "PreussenTelekom" #9127: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
08:45:31   pluto[1928]   "PreussenTelekom" #9127: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed
08:45:31   pluto[1928]   "PreussenTelekom" #9127: STATE_MAIN_I2: sent MI2, expecting MR2
08:45:31   pluto[1928]   "PreussenTelekom" #9127: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
08:45:31   pluto[1928]   "PreussenTelekom" #9127: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
08:45:31   pluto[1928]   "PreussenTelekom" #9127: received Vendor ID payload [RFC 3947] method set to=115
08:45:31   pluto[1928]   "PreussenTelekom" #9127: received Vendor ID payload [Dead Peer Detection]
08:45:31   pluto[1928]   "PreussenTelekom" #9127: received Vendor ID payload [Openswan (this version) 2.6.42 ]
08:45:31   pluto[1928]   "PreussenTelekom" #9127: initiating Main Mode to replace #9122
08:45:31   pluto[1928]   pending Quick Mode with 217.x.x.x "PreussenTelekom" took too long -- replacing phase 1
08:45:27   pluto[1928]   "PreussenTelekom" #9126: sending encrypted notification INVALID_ID_INFORMATION to 217.x.x.x:500



Nach oben
   
 Betreff des Beitrags: Re: Ipsec klappt nicht
BeitragVerfasst: 06.09.2017, 09:52 
Offline
VPN-Experte
VPN-Experte
Benutzeravatar

Registriert: 04.02.2007
Beiträge: 260
Wohnort: Landsberg, Bayern, Deutschland
Hallo,

Zitat:
Vermutlich gibt es dort ein Problem mit dem Portweiterleiten.
Kannst du das ESP-Protokoll auch noch auf den Cop weiterleiten. Port 4500 UDP brauchst du nur wenn der Router kein ESP-Protokoll weiterleiten kann.

Zitat:
Ich habe jetzt die zugewiesene IP 192.168.0.94 unter, Öffentliche IP oder FQDN für das ROTE Interface oder <%defaultroute>, eingetragen.
Ich habe auch mehrere IPCops die mit VPN miteinander verbunden sind. Bei Öffentliche IP, FQDN für das ROTE Interface habe ich jeweils die ROTE-IP des Cops eingetragen. Diese stehen bei mir dann auch in der ipsec.secrets.

Weiterhin würde ich die ROTE-IP des Cops fest einstellen und nicht per DHCP vergeben.

Du kannst mal probieren die ID's in der ipsec.secrets wegzulassen. Also so:
Code:
: RSA /var/ipcop/certs/hostkey.pem
: PSK 'Test123456'
oder mit der roten IP:
Code:
: RSA /var/ipcop/certs/hostkey.pem 
192.168.0.94 178.x.x.x: PSK 'Test123456'
oder evtl. auch
Code:
: RSA /var/ipcop/certs/hostkey.pem 
192.168.0.94 %any: PSK 'Test123456'


Laut man-page gehört das secret in Auführungszeichen (") und nicht in Hochkommas ('), kann es gerade nicht verifizieren weil ich Zertifikate benutze.

Grüße
Christian

_________________
Über mich
Guggst du IPSec VPN hinter Routern
Bild


Nach oben
   
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen  Auf das Thema antworten  [ 6 Beiträge ] 

Alle Zeiten sind UTC+02:00


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.

Suche nach:
Gehe zu Forum:  
Powered by phpBB® Forum Software © phpBB Limited
Deutsche Übersetzung durch phpBB.de