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: 24.05.2017, 17:48

Alle Zeiten sind UTC+02:00




Ein neues Thema erstellen  Auf das Thema antworten  [ 17 Beiträge ]  Gehe zu Seite 1 2 Nächste
Autor Nachricht
BeitragVerfasst: 29.01.2017, 00:18 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 06.06.2016
Beiträge: 12
Guten Abend liebe IPCop Freunde :kaffee:

Ich habe das ein kleines Problemchen mit einem IPSec Tunntel zwischen IPCop 2.1.9 (Server) und IPCop 2.1.8 (Client).
Server und Client, daher, weil der Server eine öffentliche, statische IP Adresse hat und direkt am Netz hängt.
Client, weil das über ein LTE Surf-Stick geht und bekanntermaßen dort keine Portfreigaben möglich sind.

Bild

Einstellungen IPSec Server:
IPsec auf ROT: JA
Öffentliche IP oder FQDN für das ROTE Interface oder <%defaultroute>: srv.dyndns.org
Überschreibe Standard-MTU: LEER GELASSEN
Verzögerung bevor VPN gestartet wird (in Sekunden): LEER GELASSEN
Netz-zu-Netz-VPN neu starten, falls sich die Remote-IP-Adresse ändert (DynDNS): NICHT MARKIERT

Name: Vereinsnetz
Aktiviert: Ja
Host-IP-Adresse: RED (srv.dyndns.org)
Lokales Subnetz: 192.168.2.0/255.255.255.0
Lokale ID: @srv.dyndns.org
Remote Host/IP: stick.dyndns.org
Remote Subnetz: 192.168.1.0/255.255.255.0
Remote-ID: @stick.dyndns.org
Aktion für Dead-Peer-Detection: hold
Aktion wenn IPsec gestartet wird: add
Verwenden Sie einen pre-shared Schlüssel (PSK): thisismykey

Gibt es bei den Aktionen vielleicht bessere Einstellungen?
Weil nur die Surf-Stick Seite kann, darf und soll die Verbindung aufbauen.
Der Server soll daher nur "add"en der Verbindung (oder lieber route?) und bei toten Verbindungen lediglich "hold"en, weil restart geht nicht und clear könnte doch nicht tote Verbindungen löschen?

Daraus resultiert dann folgende ipsec.secrets.
Code:
: RSA /var/ipcop/certs/hostkey.pem
@srv.dyndns.org @stick.dyndns.org : PSK 'thisismykey'


Und folgende ipsec.conf.
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

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

#
# net-2-net to RED
conn Vereinsnetz
   left=srv.dyndns.org
   leftsubnet=192.168.2.0/255.255.255.0
   right=stick.dyndns.org
   rightsubnet=192.168.1.0/255.255.255.0
   leftid="@srv.dyndns.org"
   rightid="@stick.dyndns.org"
   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=hold
   pfs=yes
   authby=secret
   auto=add


Einstellungen IPSec Client:
IPsec auf ROT: JA
Öffentliche IP oder FQDN für das ROTE Interface oder <%defaultroute>: 192.168.1.1
Überschreibe Standard-MTU: LEER GELASSEN
Verzögerung bevor VPN gestartet wird (in Sekunden): LEER GELASSEN
Netz-zu-Netz-VPN neu starten, falls sich die Remote-IP-Adresse ändert (DynDNS): NICHT MARKIERT

Name: Vereinsnetz
Aktiviert: Ja
Host-IP-Adresse: RED (192.168.1.1)
Lokales Subnetz: 192.168.1.0/255.255.255.0
Lokale ID: @stick.dyndns.org
Remote Host/IP: srv.dyndns.org
Remote Subnetz: 192.168.2.0/255.255.255.0
Remote-ID: @srv.dyndns.org
Aktion für Dead-Peer-Detection: restart
Aktion wenn IPsec gestartet wird: start
Verwenden Sie einen pre-shared Schlüssel (PSK): thisismykey

Hier hab ich restart und start genommen, weil der Surf-Stick IPSec Client die Verbindung ja aufbauen soll und im Fehlerfall (Dead Peer) dann auch neu starten soll.

Daraus resultiert dann folgende ipsec.secrets.
Code:
: RSA /var/ipcop/certs/hostkey.pem
@srv.dyndns.org @stick.dyndns.org : PSK 'thisismykey'


Und folgende ipsec.conf.
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

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

#
# net-2-net to RED
conn Vereinsnetz
   left=192.168.1.1
   leftsubnet=192.168.1.0/255.255.255.0
   right=srv.dyndns.org
   rightsubnet=192.168.2.0/255.255.255.0
   leftid="@stick.dyndns.org"
   rightid="@srv.dyndns.org"
   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


Logs (Server)
Code:
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: responding to Main Mode
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: STATE_MAIN_R1: sent MR1, expecting MI2
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: STATE_MAIN_R2: sent MR2, expecting MI3
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: Main mode peer ID is ID_FQDN: '@stick.dyndns.org'
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: new NAT mapping for #52, was 87.172.164.149:63451, now 87.172.164.149:63453
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1536}
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: Dead Peer Detection (RFC 3706): enabled
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #52: the peer proposed: 192.168.2.0/24:0/0 -> 192.168.1.0/24:0/0
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #53: responding to Quick Mode proposal {msgid:7d091b03}
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #53:     us: 192.168.2.0/24===144.73.20.30<srv.dyndns.org>[@srv.dyndns.org]
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #53:   them: 87.172.164.149<stick.dyndns.org>[@stick.dyndns.org]===192.168.1.0/24
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #53: keeping refhim=4294901761 during rekey
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #53: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #53: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #53: Dead Peer Detection (RFC 3706): enabled
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #53: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan 28 23:54:35 router pluto[18393]: "Vereinsnetz" #53: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x0a8da183 <0x3be0b014 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=87.172.164.149:63453 DPD=enabled}


$ ipsec eroute
Code:
/usr/libexec/ipsec/eroute: NETKEY does not support eroute table.


$ ipsec verify
Code:
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.42/K3.4-3 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [OK]
        [OK]
        [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Two or more interfaces found, checking IP forwarding            [FAILED]
Checking NAT and MASQUERADEing                                  [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]


! Two or more interfaces found, checking IP forwarding !

$ ip xfrm state
Code:
src 87.172.164.149 dst 144.73.20.30
        proto esp spi 0x1056faee reqid 16405 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0x9310c236f4917891fe9a5b3215cd2b3a801d593c 96
        enc cbc(aes) 0xca1767ae12dd3cdf85cbbdbcedce2c6c
        encap type espinudp sport 63453 dport 4500 addr 0.0.0.0
src 144.73.20.30 dst 87.172.164.149
        proto esp spi 0x1a9609af reqid 16405 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xdb23eb1368f490b286a3e6920a6039d7c0b27ecc 96
        enc cbc(aes) 0x46fcbd56399a75236c23a277b4cf98bf
        encap type espinudp sport 4500 dport 63453 addr 0.0.0.0


$ ip xfrm policy
Code:
src 192.168.2.0/24 dst 192.168.1.0/24
        dir out priority 2344
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 0 mode transport
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0


$ ifconfig
Code:
lan-1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.1  netmask 255.255.255.0  broadcast 0.0.0.0
        ether 00:0c:29:a4:e9:1c  txqueuelen 1000  (Ethernet)
        RX packets 92253389  bytes 2934553072 (2.7 GiB)
        RX errors 0  dropped 240  overruns 0  frame 0
        TX packets 148750960  bytes 2578063661 (2.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 151823  bytes 6902140 (6.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 151823  bytes 6902140 (6.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
        inet 10.45.158.1  netmask 255.255.255.255  destination 10.45.158.2
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 9872  bytes 705578 (689.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10673  bytes 9579701 (9.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wan-1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 144.73.20.30  netmask 255.255.255.248  broadcast 0.0.0.0
        ether 00:50:56:00:34:59  txqueuelen 1000  (Ethernet)
        RX packets 154407025  bytes 3198210289 (2.9 GiB)
        RX errors 0  dropped 275  overruns 0  frame 0
        TX packets 93556844  bytes 3002430007 (2.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


$ route (Sieht ähnlich aus auf dem Client)
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         static.225.20.7 0.0.0.0         UG    0      0        0 wan-1
10.45.158.0     10.45.158.2     255.255.255.0   UG    0      0        0 tun0
10.45.158.2     *               255.255.255.255 UH    0      0        0 tun0
144.73.20.24   *               255.255.255.248 U     0      0        0 wan-1
192.168.2.0      *               255.255.255.0   U     0      0        0 lan-1


Firewall: (Identisch für Client und Server)
Bild


Wie ihr sehen könnt (rot markiert) gibt es einen sichtbaren Fehler...
Code:
Two or more interfaces found, checking IP forwarding


Jetzt ist die Frage, wie man den behebt :-)
Oder habt ihr eine Ahnung woran es liegen kann? Damit ich da endlich diese Verbindung zustande bekomme?

Hatte gestern schon bis 3 Uhr morgens daran gearbeitet gehabt :wuss:
Da lag es dann daran, dass der Port nicht extra im IPCop freigegeben war.
Beim OpenVPN musste ich auch kein Port extra freigeben... Beim IPSec scheinbar schon.
Zumindest baut er dann die Verbindung so auf wie oben.

Also er zeigt jetzt auch immer noch grün an. Die Verbindung aufgebaut hatte ich vor ner halben Stunde.


P.S.: Wenn ihr vom Client noch mehr Daten benötigt einfach sagen.
Ich denke mal wenn ihr oben alles vom Server habt sollte das reichen. Sonst wird der Thread noch länger :super:

Sitze jetzt hier auch schon ne halbe Stunde dran, so verzweifelt brauche ich eure Hilfe :winken: :help:

:super: Also Danke für jede noch so kleine hilfreiche Information :super:

_________________
Bild
Mein treuer IPCop mit internem Netzwerk, OpenVPN, theoretische IPSec Anlaufstelle für alle Surf-Sticks, etc.


Nach oben
   
BeitragVerfasst: 29.01.2017, 11:52 
Offline
Deputy Commissioner
Deputy Commissioner
Benutzeravatar

Registriert: 23.09.2007
Beiträge: 1000
Wohnort: an der Oder
Muss man bei IPsec in der Firewall zusätzliche Eintragungen vornehmen? Ich dachte, dass ist nicht nötig, denn der eingerichtete Tunnel wird wie ein erweitertes Green behandelt. Was passiert, wenn du die Einträge in der FW deaktivierst?

_________________
Immer mit der Ruhe, alles wird gut...

BildBildBild
Mein erster Post im Forum.


Nach oben
   
BeitragVerfasst: 29.01.2017, 18:50 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 06.06.2016
Beiträge: 12
Hallo RadioCarbon,

Dankeschön für deine Idee.
Leider bringt mich das auch nicht weiter.

Also habe es ausprobiert, komplett alles nach und nach gelöscht und immer getestet.
Erst auf beiden IPCops die Regel für IPSec als Portfreigabe auf dem IPCop.
Und dann das obere mit dem Allow * from IPSec to Green.

Habe sogar herausgefunden, dass er die Netzwerke anzeigt bei der Firewall.
Sprich habe das hier eben nochmal hinzugefügt.
Leider klappt es auch damit nicht.

Bild

Ich meine auch mal ganz dumm gesagt...
Wie bzw. woher weiß der Computer denn, wie er die IP Adresse auflösen soll?
Meine Antwort wäre ja über die Routingtabelle.
Nur leider steht da halt überhaupt nichts von den Netzwerken drinnen.
Deswegen wundert mich die Ausgabe auch nicht, wenn ich $ traceroute 192.168.2.1 (auf dem Client) eingebe...
Code:
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  surf.stick (10.45.45.1)  0.515 ms  0.566 ms  0.685 ms
 2  62.155.243.7 (62.155.243.7)  11.996 ms  12.652 ms  13.100 ms
 3  62.155.243.7 (62.155.243.7)  13.092 ms  13.658 ms  !H  14.008 ms  !H


In der Routingtabelle steht ja auch drinnen als Destination, Default für 0.0.0.0 Maske der Surf-Stick.
Da steht nicht dass die Anfragen für 192.168.2.0/24 an 192.168.2.1 gehen sollen...

:konfus: Das wundert mich :konfus:

Aber danke für den Hinweis. Ich habe so gehofft, dass das klappt :|

_________________
Bild
Mein treuer IPCop mit internem Netzwerk, OpenVPN, theoretische IPSec Anlaufstelle für alle Surf-Sticks, etc.


Nach oben
   
BeitragVerfasst: 29.01.2017, 21:19 
Offline
Deputy Commissioner
Deputy Commissioner
Benutzeravatar

Registriert: 23.09.2007
Beiträge: 1000
Wohnort: an der Oder
Was sagt "route"? Das kommt bei mir und ich benutze OpenVPN. Der Client mit dem Tunnel kann auf alle Geräte in Grün zugreifen, als ob er selbst in diesem Netzwerk wäre.
Code:
root@ipcop:~ # route 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         87.186.224.166  0.0.0.0         UG    0      0        0 ppp0
10.192.240.0    10.192.240.2    255.255.255.0   UG    0      0        0 tun0
10.192.240.2    *               255.255.255.255 UH    0      0        0 tun0
87.186.224.166  *               255.255.255.255 UH    0      0        0 ppp0
172.16.0.0      *               255.240.0.0     U     0      0        0 wan-1
172.16.1.0      *               255.255.255.0   U     0      0        0 wan-1
192.168.5.0     *               255.255.255.0   U     0      0        0 lan-1
192.168.23.0    *               255.255.255.0   U     0      0        0 wlan-1
192.168.42.0    *               255.255.255.0   U     0      0        0 dmz-1

_________________
Immer mit der Ruhe, alles wird gut...

BildBildBild
Mein erster Post im Forum.


Nach oben
   
BeitragVerfasst: 29.01.2017, 21:52 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 06.06.2016
Beiträge: 12
RadioCarbon hat geschrieben:
Der Client mit dem Tunnel kann auf alle Geräte in Grün zugreifen, als ob er selbst in diesem Netzwerk wäre.


Genau korrekt.
OpenVPN ist direkt als Route eingetragen, ebenfalls bei mir.
IPSec hingegen nicht!
Der IPSec Site2Site ist "Offen" aber es gibt keine Route dafür.

Das wundert mich.
Wenn ich OpenVPN "ganz einfach" verwende dann zeigt er nämlich die Routen entsprechend an und - weil der Computer die Routingtabelle kennt - weiß der Computer er soll die OpenVPN Anfragen an das Gateway (= Router) schicken.
Beim IPSec taucht das Netz aber überhaupt nicht im Routing auf, daher denkt der Computer er soll alles an das default für 0.0.0.0 schicken.
Deswegen sag ich ja... Da fehlt bestimmt nur die Route.



$ route

Server / IPCop Intern 192.168.2.1 mit OpenVPN Server für andere Clients (tun0)
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         static.225.20.7 0.0.0.0         UG    0      0        0 wan-1
10.45.158.0     10.45.158.2     255.255.255.0   UG    0      0        0 tun0
10.45.158.2     *               255.255.255.255 UH    0      0        0 tun0
144.73.20.24   *               255.255.255.248 U     0      0        0 wan-1
192.168.2.0      *               255.255.255.0   U     0      0        0 lan-1


Client / IPCop Intern 192.168.1.1 aber kommuniziert über Surf-Stick Gateway
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         surf.stick 0.0.0.0         UG    0      0        0 wan-1
192.168.1.0      *               255.255.255.0   U     0      0        0 lan-1
10.45.45.0   *               255.255.255.0 U     0      0        0 wan-1




//Edit:
Also wenn ich mir mal sowas hier durchlese dann steht da, dass man gar keine Routen für IPSec im normalen System hat.
"Der Tunnel existiert einfach", fertig.
https://forum.pfsense.org/index.php?topic=14676.0

Ich probiere noch mal ein Stündchen ein paar Dinge mit TCPDump und irgendwas, was ich auf Google noch finden werde.
Wenn ich nix mehr schreibe gab es nichts positives :|

_________________
Bild
Mein treuer IPCop mit internem Netzwerk, OpenVPN, theoretische IPSec Anlaufstelle für alle Surf-Sticks, etc.


Nach oben
   
BeitragVerfasst: 29.01.2017, 22:12 
Offline
Deputy Commissioner
Deputy Commissioner
Benutzeravatar

Registriert: 23.09.2007
Beiträge: 1000
Wohnort: an der Oder
Dann wirst du wohl nicht drum rum kommen und die Route per Hand einzutragen, in der Hoffnung, dass es dann geht. Wenn ja, brauchst auch keine Einträge in der Firewall dafür.

BTW. Maskiere bitte deine statische öffentliche IP. Private und wechselnde öffentliche IPs sind unkritisch.

_________________
Immer mit der Ruhe, alles wird gut...

BildBildBild
Mein erster Post im Forum.


Nach oben
   
BeitragVerfasst: 29.01.2017, 22:14 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 06.06.2016
Beiträge: 12
RadioCarbon hat geschrieben:
Dann wirst du wohl nicht drum rum kommen und die Route per Hand einzutragen, in der Hoffnung, dass es dann geht. Wenn ja, brauchst auch keine Einträge in der Firewall dafür.

BTW. Maskiere bitte deine statische öffentliche IP. Private und wechselnde öffentliche IPs sind unkritisch.


Hehe habe gerade ein //edit zu meinem Beitrag hinzugefügt.
Laut diversen Google Einträgen zu "IPSec tunnel without route" oder "IPSec not adding a route" habe ich herausgefunden, dass IPSec scheinbar einfach so existiert und die Zugriffe wohl irgendwie abfangen soll.
Sprich es gibt wohl einfach keine Route, wenn der Tunnel existiert/offen ist dann soll man die Server mit entsprechender Firewall Freigabe wohl ansprechen können.


Wie maskiere ich denn die statische öffentliche IP?
Also ich hab in IPSec spaßeshalber statt den DYNDNS mal die IP Adressen eingetragen - bringt halt das selbe Ergebnis. Leider. :sagnix:

_________________
Bild
Mein treuer IPCop mit internem Netzwerk, OpenVPN, theoretische IPSec Anlaufstelle für alle Surf-Sticks, etc.


Nach oben
   
BeitragVerfasst: 29.01.2017, 22:20 
Offline
Deputy Commissioner
Deputy Commissioner
Benutzeravatar

Registriert: 23.09.2007
Beiträge: 1000
Wohnort: an der Oder
Soory, habe ich missverständlich ausgedrückt. Ich meinte, du möchtest in deinem Beitrag bitte die öffentliche IP entfernen (Ziffern z.B. durch X ersetzen).

_________________
Immer mit der Ruhe, alles wird gut...

BildBildBild
Mein erster Post im Forum.


Nach oben
   
BeitragVerfasst: 29.01.2017, 22:22 
Offline
Deputy Commissioner
Deputy Commissioner
Benutzeravatar

Registriert: 23.09.2007
Beiträge: 1000
Wohnort: an der Oder
RadioCarbon hat geschrieben:
Soory, habe ich missverständlich ausgedrückt. Ich meinte, du möchtest in deinem Beitrag bitte die öffentliche IP entfernen (Ziffern z.B. durch X ersetzen).


Zu deinem IPsec-Problem kann ich nichts weiter beitragen, ich benutze es nicht. Müsste ich mich erst einlesen, aber das hast du selbst schon gemacht. Tut mir Leid, dass ich nicht helfen kann.

_________________
Immer mit der Ruhe, alles wird gut...

BildBildBild
Mein erster Post im Forum.


Nach oben
   
BeitragVerfasst: 29.01.2017, 22:28 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 06.06.2016
Beiträge: 12
RadioCarbon hat geschrieben:
Soory, habe ich missverständlich ausgedrückt. Ich meinte, du möchtest in deinem Beitrag bitte die öffentliche IP entfernen (Ziffern z.B. durch X ersetzen).


Ah ok. Ja ich achte auch Privatsphäre :floet:
Alle öffentlichen IP Adressen wurden so verändert, dass die Subnetze passen aber die Adressen dahinter nicht zu mir gehören.
Also was auch immer dahinter steckt: Meine sind es nicht.

RadioCarbon hat geschrieben:
Zu deinem IPsec-Problem kann ich nichts weiter beitragen, ich benutze es nicht. Müsste ich mich erst einlesen, aber das hast du selbst schon gemacht. Tut mir Leid, dass ich nicht helfen kann.


Kein Problem. Ich danke dir dennoch für deine Zeit und wünsche einen schönen Rest-Sonntag :super:




Dann benötige ich weiterhin :help: einen IPSec Experten :cry:

_________________
Bild
Mein treuer IPCop mit internem Netzwerk, OpenVPN, theoretische IPSec Anlaufstelle für alle Surf-Sticks, etc.


Nach oben
   
BeitragVerfasst: 29.01.2017, 23:37 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 06.06.2016
Beiträge: 12
Hmm also ich war ein wenig Erfolgreich.
- Sorry für den Doppelpost, das musste jetzt einfach sein :baetsch: -


Also die Aussage von mir, dass da wohl kein Routing fürs IPSec benötigt wird, ist falsch.
Zumindest habe ich jetzt ein Ping geschafft UND :winken: ich konnte mich von einem X-Beliebigen Server per SSH über den IPSec Tunnel auf den IPCop verbinden.
Das alles dank einem Befehl auf beiden IPCops.

Auf Server IPCop:
Code:
route add -net 192.168.1.0/24 gw 192.168.2.1 lan-1


Auf Client IPCop:
Code:
route add -net 192.168.2.0/24 gw 192.168.1.1 lan-1


Das bewirkt tatsächlich, dass ohne irgendwas noch zusätzlich gemacht zu haben, dass ich halt die Maschinen anpingen kann und alles.
Also die Routing Tabelle von einem X-Beliebigen Server vom Server IPCop sieht so aus.
$ route auf Virtueller Maschine auf dem Server IPCop 2.1.9
Code:
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         router.local    0.0.0.0         UG    0      0        0 eth0
192.168.2.0      *               255.255.255.0   U     0      0        0 eth0


$ traceroute 192.168.1.1 von der virtuellen Maschine
Code:
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1  router.local (192.168.2.1)  0.172 ms  0.227 ms  0.176 ms
 2  192.168.1.1 (192.168.1.1)  26.148 ms  26.398 ms  26.453 ms


:yeah: Ist das jetzt nicht toll? :yeah:


Jetzt lautet die Frage:
Wieso macht der IPSec das nicht von sich aus?
Ist ja doof, dass da echt nur scheinbar die Route fehlt und sonst nichts.


P.S.: (@RadioCarbon:) Die Firewall Regeln beim Server IPCop für den IPSec Eingang (-) und (500) musste ich allerdings auch wieder freigeben. Ich konnte keine Verbindung mehr aufbauen ohne die freizugeben.

_________________
Bild
Mein treuer IPCop mit internem Netzwerk, OpenVPN, theoretische IPSec Anlaufstelle für alle Surf-Sticks, etc.


Zuletzt geändert von Bubelbub am 31.01.2017, 01:56, insgesamt 1-mal geändert.

Nach oben
   
BeitragVerfasst: 30.01.2017, 18:57 
Offline
Site-Moderator
Site-Moderator
Benutzeravatar

Registriert: 18.12.2007
Beiträge: 3321
Wohnort: Im Norden bei mir zu Hause
Ich habe die Erfahrung gemacht, dass die Net2Net-Tunnel sehr stabil funktionieren, wenn unter "VPN" -> "IPSec" bei "Öffentliche IP oder FQN" %defaultroute drinsteht.

_________________
Gruß edelweis

Sledgehammer engineering, if it doesn't work, hammer it damn hard :super:

Bild
Bild
Meine Vorstellung


Nach oben
   
BeitragVerfasst: 30.01.2017, 19:11 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 06.06.2016
Beiträge: 12
edelweis hat geschrieben:
Ich habe die Erfahrung gemacht, dass die Net2Net-Tunnel sehr stabil funktionieren, wenn unter "VPN" -> "IPSec" bei "Öffentliche IP oder FQN" %defaultroute drinsteht.


Hmm eben getestet - aber leider wird auch damit keine Route angelegt :skeptisch:


Generell gesagt werde ich wohl ein Issue anlegen bei OpenSwan.
Laut http://serverfault.com/a/556923/311700 sind die Einstellungen wohl auch korrekt.
Also die Einstellungen von mir scheinen realistisch.

Kann echt nicht angehen, das die Routen fehlen... :wuss:

_________________
Bild
Mein treuer IPCop mit internem Netzwerk, OpenVPN, theoretische IPSec Anlaufstelle für alle Surf-Sticks, etc.


Nach oben
   
BeitragVerfasst: 30.01.2017, 19:30 
Offline
Site-Moderator
Site-Moderator
Benutzeravatar

Registriert: 18.12.2007
Beiträge: 3321
Wohnort: Im Norden bei mir zu Hause
Auch bei mir siehst du keine Routen, siehe Ausgabe:
Code:
root@testcop:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.1     0.0.0.0         UG    0      0        0 wan-1
10.243.58.0     10.243.58.2     255.255.255.0   UG    0      0        0 tun0
10.243.58.2     *               255.255.255.255 UH    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 wan-1
192.168.7.0     *               255.255.255.0   U     0      0        0 lan-1
192.168.10.0    *               255.255.255.0   U     0      0        0 wlan-1
root@testcop:~ #
Zugriff funktioniert trotzdem fehlerfrei. Auch via RoadWarrior unter IPSec. Die Routen via tun0 sind die eingerichteten OpenVPN-Verbindungen.

_________________
Gruß edelweis

Sledgehammer engineering, if it doesn't work, hammer it damn hard :super:

Bild
Bild
Meine Vorstellung


Nach oben
   
BeitragVerfasst: 30.01.2017, 21:34 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 06.06.2016
Beiträge: 12
edelweis hat geschrieben:
Zugriff funktioniert trotzdem fehlerfrei. Auch via RoadWarrior unter IPSec. Die Routen via tun0 sind die eingerichteten OpenVPN-Verbindungen.


Och man ey. :verrueckt:
Damit hilfst du mir zwar einerseits, dass ich jetzt sagen kann:
1.) Total unlogisch, dass es bei mir nicht auf diese Weise klappt (ohne Routen)
Es dafür aber funktioniert 2.) Wenn ich die Routen manuell eintrage. :ohmann:

Das gibt es doch gar nicht :roll: :skeptisch:


Welche Netzbereiche hast du denn für dein IPSec, wenn ich fragen darf?

Wobei du hast auch zwei Netze - so wie ich.
LAN-1 und WAN-1.

Was kommt denn bei dir wenn du "ipsec verify" eingibst?
Ist bei dir dann da auch ein [FAILED] drinnen?
Vielleicht ist das Failed ja normal? :wuss:


Und ipsec version interessiert mich.
Vielleicht liegt das einfach nur daran dass der eine IPCop nur 2.1.8 hat - und bei 2.1.9 ja noch ein Update von OpenSwan kam laut Changelog.
WOBEI auch hier... Der eine IPCop hat ja 2.1.9 und hat ebenfalls kein Routing-Eintrag UND auch keine Ping-Funktionalität ohne den Routing-Eintrag.


Das kann doch echt nicht so schwer sein mensch :shock:
OpenVPN so einfach, dass das in paar Minuten eingerichtet ist - und IPSec theoretisch ebenfalls mega einfach - nur irgendwie falsch umgesetzt? Software-Fehler? Menschliches Versagen? :denk:

Die Smileys machen es auch nicht besser :lol:

_________________
Bild
Mein treuer IPCop mit internem Netzwerk, OpenVPN, theoretische IPSec Anlaufstelle für alle Surf-Sticks, etc.


Nach oben
   
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen  Auf das Thema antworten  [ 17 Beiträge ]  Gehe zu Seite 1 2 Nächste

Alle Zeiten sind UTC+02:00


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast


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:  
cron
Powered by phpBB® Forum Software © phpBB Limited
Deutsche Übersetzung durch phpBB.de