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: 19.08.2017, 13:10

Alle Zeiten sind UTC+02:00




Ein neues Thema erstellen  Auf das Thema antworten  [ 16 Beiträge ]  Gehe zu Seite 1 2 Nächste
Autor Nachricht
BeitragVerfasst: 27.04.2017, 21:58 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 05.05.2011
Beiträge: 26
Wohnort: Im Norden
Hallo Gemeinde,

nach langer Zeit habe ich wieder einmal ein Problem, für das ich Hilfe benötige. :denk: :(

Wir haben zwischen der Zentrale und Nebenstellen Net-2-Net Verbindungen über IPsec eingerichtet, die laufen auch völlig problemlos seit vielen Monaten. :yeah:
Jetzt soll eine weitere kleine Nebenstelle angebunden werden. Hier haben wir keine Standleitungen, sonder nutzen einen ADSL-Anschluß (16.000). Als Modem kommt ein Speedport Entry zum Einsatz, der auf die neueste Firmware 2.15 upgedated wurde. An dem Speedport hängt der IPCOP. Einwahl übernimmt der Speedport, dessen LAN-Port das rote Netz bildet. Am Speedport sind die Ports 51, 53, 87, 500 und 4500 (jeweils TCP/UDP) weitergeleitet an den IPCOP. dynDNS ist auch eingerichtet.

Internetzugang funktioniert, jedoch kriege ich die IPsec-Verbindung zwischen den beiden COPs nicht aufgebaut. Von der Nebenstelle kann ich die Zentrale anpingen, aber nicht umgekehrt.

Irgendwie habe ich den Verdacht, daß es am Speedport liegen könnte, dessen Einstellungsmöglichkeiten irgendwie äußerst begrenzt sind. U.a. läßt sich die interne Firewall nicht abschalten und nach welchen Regeln die arbeitet, ist auch nicht transparent.

Was mache ich falsch?

Viele Grüße

dfk


Nach oben
   
BeitragVerfasst: 27.04.2017, 22:40 
Offline
Site-Moderator
Site-Moderator
Benutzeravatar

Registriert: 18.12.2007
Beiträge: 3325
Wohnort: Im Norden bei mir zu Hause
doppelfischkopp hat geschrieben:
Als Modem kommt ein Speedport Entry zum Einsatz, .....
doppelfischkopp hat geschrieben:
Einwahl übernimmt der Speedport, dessen LAN-Port das rote Netz bildet.
Sicher, dass das ein Modem ist? Diese beiden Aussagen widersprechen sich. ;)
doppelfischkopp hat geschrieben:
Internetzugang funktioniert, jedoch kriege ich die IPsec-Verbindung zwischen den beiden COPs nicht aufgebaut. Von der Nebenstelle kann ich die Zentrale anpingen, aber nicht umgekehrt.
Was genau meinst du mit der Aussage? Kannst du die öffentliche IP der Zentrale anpingen? Kannst du irgendwas vom internen Netz anpingen? Was bringt ein tracert auf die gleiche Adresse?
doppelfischkopp hat geschrieben:
Irgendwie habe ich den Verdacht, daß es am Speedport liegen könnte, ...
Woran machst du das fest? Hast du einen Gegentest mit einem reinen Modem gemacht? Oder mit einem anderen Billigrouter?
doppelfischkopp hat geschrieben:
dessen Einstellungsmöglichkeiten irgendwie äußerst begrenzt sind. U.a. läßt sich die interne Firewall nicht abschalten und nach welchen Regeln die arbeitet, ist auch nicht transparent.
Dann wirf den Kram auf den Müll und nimm was vernünftiges.
doppelfischkopp hat geschrieben:
Was mache ich falsch?
Du nimmst im professionellen Umfeld Consumer-Hardware.
Und zuwenig vernünftige Informationen sind es auch. Keine relevanten Auszüge aus den Logs, keine Konfigurationsinformationen, wie soll man da vernünftig helfen?

_________________
Gruß edelweis

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

Bild
Bild
Meine Vorstellung


Nach oben
   
BeitragVerfasst: 28.04.2017, 16:15 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 05.05.2011
Beiträge: 26
Wohnort: Im Norden
Moin Edelweis,
edelweis hat geschrieben:
Dann wirf den Kram auf den Müll und nimm was vernünftiges.

Guter Tip, aber leider ist das Geld im Bildungsbereich nicht gerade immer üppig vorhanden. :wink:
Das war damals die günstigste Lösung und ich habe bewußt ein Modell ohne Schnickschnack genommen, weil Telefon haben wir zusätzlich über eine ISDN-Anlage.
Wenn ich die Dokumentation (Einwahlunterlagen) finde, dann wäre ich auch für andere Hardware offen. Lieber wäre es mir persönlich natürlich, wenn ich am Speedport nicht fummeln müßte.

edelweis hat geschrieben:
Sicher, dass das ein Modem ist? Diese beiden Aussagen widersprechen sich. ;)

Ja, ich habe das synonym benutzt. Es handelt sich um einen "Router", sogar mit eingebauter Firewall, die sich leider nicht abstellen läßt. Die Einwahl übernimmt auch der Speedport. Aufbau ist wie folgt:

Nebenstelle - IPCOP - Speedport - Internet - IPCOP - Zentrale
Ziel ist VPN über IPsec von COP zu COP

edelweis hat geschrieben:
Was genau meinst du mit der Aussage? Kannst du die öffentliche IP der Zentrale anpingen?

Von einem PC der Nebenstelle kann ich die öffentliche IP des COPs in der Zentrale anpingen, aber umgekehrt kann ich selbst von der Shell des COPs nicht auf die öffentliche IP des Speedports pingen (wäre natürlich möglich, daß der das grundsätzlich nicht unterstützt)

edelweis hat geschrieben:
Keine relevanten Auszüge aus den Logs

Welche Logs denn?

Viele Grüße und vielen Dank schon einmal

dfk


Nach oben
   
BeitragVerfasst: 28.04.2017, 17:26 
Offline
VPN-Experte
VPN-Experte
Benutzeravatar

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

Zitat:
aber umgekehrt kann ich selbst von der Shell des COPs nicht auf die öffentliche IP des Speedports pingen

IMHO antwortet der Speedport serienmäßig nicht auf pings von rot bzw. vom Internet.

Zitat:
Welche Logs denn?

Auf der Startseite der IPCop-Oberfläche gehst du auf Protokolle - Systemprotokolle. Danach wählst du bei Konfiguration den Punkt IPSec aus. Jetzt siehst du die IPSec-Log. Diese könntest du über Export herunterladen und relevante Auszüge mit der Code-Funktion des Boards posten.

Grüße
TwoFace

_________________
Über mich
Guggst du IPSec VPN hinter Routern
Bild


Nach oben
   
BeitragVerfasst: 28.04.2017, 19:55 
Offline
Site-Moderator
Site-Moderator
Benutzeravatar

Registriert: 18.12.2007
Beiträge: 3325
Wohnort: Im Norden bei mir zu Hause
doppelfischkopp hat geschrieben:
Guter Tip, aber leider ist das Geld im Bildungsbereich nicht gerade immer üppig vorhanden. :wink:
Dann sucht man sich hat was günstiges:
Günstige Varianten:
http://www.ebay.de/itm/D-Link-ADSL-2-2- ... SwHPlWft3o

http://www.ebay.de/itm/Lucent-Technolog ... Sw3v5Yqrjc

http://www.ebay.de/itm/Draytek-Vigor270 ... SwAvJW--1G

http://www.ebay.de/itm/ALLNET-Allnet-AD ... SwzqFY~PUR

Teurere Varianten:
http://www.ebay.de/itm/Draytek-Vigor-13 ... SwWiBY~yjo

doppelfischkopp hat geschrieben:
...sogar mit eingebauter Firewall, die sich leider nicht abstellen läßt.
Da wäre ich mir nicht so sicher. Schon mal im Handbuch nachgeschaut?

_________________
Gruß edelweis

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

Bild
Bild
Meine Vorstellung


Nach oben
   
BeitragVerfasst: 02.05.2017, 17:46 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 05.05.2011
Beiträge: 26
Wohnort: Im Norden
Aber edelweis,

wenn ich bei ebay kaufe, dann komme ich bestimmt in die Hölle. :twisted: :twisted: :twisted:
Spätestens, wenn der "zentrale Einkauf" davon erfährt. :lol:

Ich werde gleich noch einmal etwas spielen gehen, vielleicht kann ich dann ja auch noch die Logs posten.

Glücklicherweise haben sich die Zugangsdaten wieder angefunden, so daß ich es mit einer Fritzbox 7272 testen könnte. Die "dürfte" ich vermutlich auch regulär erwerben.

Vielen Dank schon einmal.

dfk


Nach oben
   
BeitragVerfasst: 02.05.2017, 20:39 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 05.05.2011
Beiträge: 26
Wohnort: Im Norden
So, hier die versprochenen Logs:

Positiv ist, daß sich die COPs offenbar doch gegenseitig sehen können.

Hier die Nebenstelle. xx.87.198 ist die rote IP der Zentrale.
Code:
IPCop diagnostics
Abschnitt: IPsec
Datum: 2017-05-02

19:49:54 ipsec Restart connection #1
19:49:56 pluto[13798] forgetting secrets
19:49:56 pluto[13798] loading secrets from "/etc/ipsec.secrets"
19:49:56 pluto[13798] "zuNETZ87": deleting connection
19:49:56 pluto[13798] added connection description "zuNETZ87"
19:49:56 pluto[13798] "zuNETZ87": We cannot identify ourselves with either end of this connection.
19:50:09 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [Openswan (this version) 2.6.41 ]
19:50:09 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [Dead Peer Detection]
19:50:09 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [RFC 3947] method set to=115
19:50:09 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 115
19:50:09 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115
19:50:09 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 115
19:50:09 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
19:50:09 pluto[13798] packet from xx.xx.87.198:500: initial Main Mode message received on 192.168.2.2:500 but no connection has been authorized with policy=PSK
19:50:49 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [Openswan (this version) 2.6.41 ]
19:50:49 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [Dead Peer Detection]
19:50:49 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [RFC 3947] method set to=115
19:50:49 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 115
19:50:49 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115
19:50:49 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 115
19:50:49 pluto[13798] packet from xx.xx.87.198:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
19:50:49 pluto[13798] packet from xx.xx.87.198:500: initial Main Mode message received on 192.168.2.2:500 but no connection has been authorized with policy=PSK

Hier die Zentrale
Code:
IPCop diagnostics
Abschnitt: IPsec
Datum: 2017-05-02

20:09:39 pluto[32345] pending Quick Mode with xx.xx.13.181 "zuNETZ210" took too long -- replacing phase 1
20:09:39 pluto[32345] "zuNETZ210": terminating SAs using this connection
20:09:39 pluto[32345] "zuNETZ210" #1446: deleting state (STATE_MAIN_I1)
20:09:39 pluto[32345] "zuNETZ" #1448: initiating Main Mode
20:12:17 ipsec Restart connection #9
20:12:19 pluto[32345] forgetting secrets
20:12:19 pluto[32345] loading secrets from "/etc/ipsec.secrets"
20:12:19 pluto[32345]   loaded private key file '/var/ipcop/certs/hostkey.pem' (887 bytes)
20:12:19 pluto[32345] loaded private key for keyid: PPK_RSA:AwEAAeSdo
20:12:19 pluto[32345] "zuNETZ210": deleting connection
20:12:19 pluto[32345] "zuNETZ210" #1448: deleting state (STATE_MAIN_I1)
20:12:19 pluto[32345] added connection description "zuNETZ210"
20:12:19 pluto[32345] "zuNETZ210" #1449: initiating Main Mode
20:12:19 vpn-watch 'zuNETZ210': start watching net210.my-gateway.de IP:xx.xx.13.181


Nach oben
   
BeitragVerfasst: 02.05.2017, 22:45 
Offline
Site-Moderator
Site-Moderator
Benutzeravatar

Registriert: 18.12.2007
Beiträge: 3325
Wohnort: Im Norden bei mir zu Hause
1.) Kontrolliere ob Datum und Uhrzeit auf beiden Seiten stimmen.
2.) Kontrolliere die Einstellungen direkt in den Konfigurationsdateien beider IPCops:
Code:
/var/ipcop/ipsec/settings
/var/ipcop/ipsec/config
/var/ipcop/ipsec/ipsec.conf

Wenn kein offensichtlicher Fehler von dir gefunden wurde:

3.) Poste die Inhalte der o.g. Konfigurations-Dateien, verschleiere ausschließlich externe IPs (und ggf. PSKs).
4.) Poste einhergehend mit Punkt 3 auch folgende Ausgaben beider IPCops:

Code:
ifconfig

_________________
Gruß edelweis

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

Bild
Bild
Meine Vorstellung


Nach oben
   
BeitragVerfasst: 03.05.2017, 22:13 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 05.05.2011
Beiträge: 26
Wohnort: Im Norden
Moin,

also Datum und Uhrzeit stimmen (ich nutze auch den ntp der PTB) auf beiden Seiten.
config von Nebenstelle und Zentrale
Code:
1,on,netz87,,net,psk,123456,start,,192.168.210.0/255.255.255.0,,xx.xx.87.198,xx.xx.87.0/25,off,off,on,off,1,8,aes128|3des,sha|md5,1536|1024,aes128|3des,sha1|md5,,off,,RED,restart,on

Code:
9,on,netz210,,net,psk,123456,start,,xx.xx.87.0/25,,netz210.my-gateway.de,192.168.210.0/24,off,off,off,off,1,8,aes128|3des,sha|md5,1536|1024,aes128|3des,sha1|md5,,off,,RED,restart,on


ipsec.conf
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.210.0/255.255.255.0,%v4:!xx.xx.87.0/25

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

#
# net-2-net to RED
conn netz87
        left=netz210.my-gateway.de
        leftsubnet=192.168.210.0/255.255.255.0
        right=xx.xx.87.198
        rightsubnet=xx.xx.87.0/25
        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

Code:
version 2.0

config setup
        protostack=netkey
        klipsdebug="none"
        plutodebug="none"
        uniqueids=yes
        nat_traversal=yes
        overridemtu=1492
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!xx.xx.87.0/255.255.255.128,%v4:!192.168.188.0/255.255.255.0,%v4:!192.168.86.0/255.255.255.0,%v4:!192.168.87.3/255.255.255.255,%v4:!192.168.134.0/25,%v4:!192.168.210.0/24,%v4:!192.168.100.0/24,%v4:!192.168.87.0/25,%v4:!192.168.87.3/255.255.255.255,%v4:!192.168.187.0/255.255.255.0

conn %default
        keyingtries=0
        disablearrivalcheck=no
        leftupdown=/usr/local/bin/ipsecupdown.sh
"ipsec.conf" 148L, 4293C


settings
Code:
ENABLED=off
DBG_CONTROL=off
DBG_CRYPT=off
VPN_DELAYED_START=60
DBG_DPD=off
DBG_KLIPS=off
DBG_PARSING=off
DBG_EMITTING=off
VPN_OVERRIDE_MTU=
DBG_DNS=off
DBG_NATT=off
VPN_WATCH=off
VPN_IP=netz210.my-gateway.de
ROOTCERT_COUNTRY=DE
ENABLED_BLUE_1=off
ENABLED_RED_1=on

Code:
ENABLED=off
DBG_CONTROL=off
DBG_CRYPT=off
VPN_DELAYED_START=0
DBG_DPD=off
DBG_KLIPS=off
DBG_PARSING=off
DBG_EMITTING=off
VPN_OVERRIDE_MTU=1492
DBG_DNS=off
DBG_NATT=off
VPN_WATCH=on
VPN_IP=xx.xx.87.198
ROOTCERT_COUNTRY=DE
ENABLED_BLUE_1=off
ENABLED_RED_1=on


In der Nebenstelle hat der COP
red 192.168.2.2/24, gateway 192.168.2.1
green 192.168.210.254/24

In der Zentrale
red xx.xx.87.198/25
green xx.xx.87.126/25
sowie noch vier weitere Subnetze mit eigenen Karten.

Also für mich sieht das irgendwie ganz gut aus, aber leider geht es trotzdem nicht.

Viele Grüße

dfk


Nach oben
   
BeitragVerfasst: 04.05.2017, 17:32 
Offline
Site-Moderator
Site-Moderator
Benutzeravatar

Registriert: 18.12.2007
Beiträge: 3325
Wohnort: Im Norden bei mir zu Hause
doppelfischkopp hat geschrieben:
ipsec.conf
Code:
#
# net-2-net to RED
conn netz87
        left=netz210.my-gateway.de
        leftsubnet=192.168.210.0/255.255.255.0
        right=xx.xx.87.198
        rightsubnet=xx.xx.87.0/25
     
Hier fehlen einige Einträge, andere sind falsch: Müsste in etwa so aussehen:
Code:
# net-2-net to RED
conn ZumTestCop
        left=%defaultroute
        leftsubnet=192.168.73.192/255.255.255.240
        right=192.168.2.76
        rightsubnet=192.168.7.0/255.255.255.0
        leftcert=/var/ipcop/certs/hostcert.pem
        rightcert=/var/ipcop/certs/ZumTestCopcert.pem
        leftid="@DYNDNSNAMEODERFESTEIP"
        rightid="@DYNDNSNAMEODERFESTEIP"
Dein Subnetz in der Zentrale ist mit Sicherheit auch eins mit IP-Adressen aus dem privaten Bereich. Ausserdem hab ich die Erfahrung gemacht, dass es fehlerfrei funktioniert, wenn bei "Öffentliche IP oder FQDN für das ROTE Interface" %defaultroute verwendet wird.
Bei DYNDNSNAMEODERFESTEIP sind jeweils die Daten der Gegenseite einzutragen.

_________________
Gruß edelweis

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

Bild
Bild
Meine Vorstellung


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

Registriert: 05.05.2011
Beiträge: 26
Wohnort: Im Norden
Moin edelweis,

danke, daß Du Dir so viel Zeit nimmst.

edelweis hat geschrieben:
Dein Subnetz in der Zentrale ist mit Sicherheit auch eins mit IP-Adressen aus dem privaten Bereich.

Nee, wie ich an anderer Stelle schon einmal geschrieben habe, habe ich das so "geerbt" von meinem Vorgänger, daß unsere C-Domain geteilt wurde: x.x.87.0/25 ist grün und x.x.87.128/25 ist rot. Ein grünes Netz mit 192.168.87.0/24 haben wir auch noch an anderer Stelle. :roll:

Zitat:
Ausserdem hab ich die Erfahrung gemacht, dass es fehlerfrei funktioniert, wenn bei "Öffentliche IP oder FQDN für das ROTE Interface" %defaultroute verwendet wird.
Kann ich den Eintrag auch bei DynDNS machen?
Code:
        
        leftcert=/var/ipcop/certs/hostcert.pem
        rightcert=/var/ipcop/certs/ZumTestCopcert.pem
        leftid="@DYNDNSNAMEODERFESTEIP"
        rightid="@DYNDNSNAMEODERFESTEIP"

Ich habe die Doku so verstanden, daß die Einträge leftid und rightid optional sind und auch weggelassen werden können. Und für diese Verbindung verwende ich - im Gegensatz zu den anderen VPN-Verbindungen - keine Zertifikate, sondern einen PSK, weil es sich noch um einen Testbetrieb handelt.

Viele Grüße

dfk


Nach oben
   
BeitragVerfasst: 04.05.2017, 21:44 
Offline
Site-Moderator
Site-Moderator
Benutzeravatar

Registriert: 18.12.2007
Beiträge: 3325
Wohnort: Im Norden bei mir zu Hause
doppelfischkopp hat geschrieben:
Nee, wie ich an anderer Stelle schon einmal geschrieben habe, habe ich das so "geerbt" von meinem Vorgänger, daß unsere C-Domain geteilt wurde: x.x.87.0/25 ist grün und x.x.87.128/25 ist rot.
Und schon damals schrieben einige, dass das Müll ist.
doppelfischkopp hat geschrieben:
Kann ich den Eintrag auch bei DynDNS machen?
Nein, bei den generellen Einstellungen, siehe hier.
doppelfischkopp hat geschrieben:
Ich habe die Doku so verstanden, daß die Einträge leftid und rightid optional sind und auch weggelassen werden können.
Richtig. "KÖNNEN" weggelassen werden. Meine Erfahrung sagt mir aber, dass es besser ist, diese einzutragen.
doppelfischkopp hat geschrieben:
Und für diese Verbindung verwende ich - im Gegensatz zu den anderen VPN-Verbindungen - keine Zertifikate, sondern einen PSK, weil es sich noch um einen Testbetrieb handelt.
Dann entfallen die Einträge mit den Pfaden für die Zertifikate, das ist alles. :winken:

_________________
Gruß edelweis

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

Bild
Bild
Meine Vorstellung


Nach oben
   
BeitragVerfasst: 04.05.2017, 22:10 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 05.05.2011
Beiträge: 26
Wohnort: Im Norden
edelweis hat geschrieben:
Und schon damals schrieben einige, dass das Müll ist.

Nun, das ist sicherlich ungewöhnlich, funktioniert aber seit Jahren tadellos. Man muß halt nur sehr aufpassen mit den Netmasken.

Zitat:
doppelfischkopp hat geschrieben:
Kann ich den Eintrag auch bei DynDNS machen?
Nein, bei den generellen Einstellungen, siehe hier.

Da verstehen wir uns falsch. Ich meinte, daß bei der Verwendung von DynDNS dort der FQDN stehen müßte, weil %defaultroute die grüne IP des Speedports liefern würde? Ich brauche doch aber die dynamische rote IP des Speedports, oder?

Werde es einmal testen mit den IDs.


Nach oben
   
BeitragVerfasst: 05.05.2017, 19:48 
Offline
Apprentice
Themenstarter
Apprentice

Registriert: 05.05.2011
Beiträge: 26
Wohnort: Im Norden
Habe es mit den IDs probiert, aber das hat leider nichts gebracht.


Nach oben
   
BeitragVerfasst: 05.05.2017, 21:28 
Offline
Site-Moderator
Site-Moderator
Benutzeravatar

Registriert: 18.12.2007
Beiträge: 3325
Wohnort: Im Norden bei mir zu Hause
doppelfischkopp hat geschrieben:
Da verstehen wir uns falsch. Ich meinte, daß bei der Verwendung von DynDNS dort der FQDN stehen müßte, weil %defaultroute die grüne IP des Speedports liefern würde?
Wer sagt das? Bei den zuletzt von mir eingerichteten Verbindungen steht immer %defaultroute drin, unabhängig, ob der Cop hinter einem Modem hängt und die Einwahl selber übernimmt oder ob er hinter einem Router hängt ud auf der roten Schnittstelle eine private IP hat.
doppelfischkopp hat geschrieben:
Ich brauche doch aber die dynamische rote IP des Speedports, oder?
Bekommst du auch mit %defaultroute.
doppelfischkopp hat geschrieben:
Habe es mit den IDs probiert, aber das hat leider nichts gebracht.
Was genau hast du eingetragen? Hast du auch das @-Zeichen am Anfang mit eingetragen? Hast du es mit der Kombination %defaultroute und den ID's versucht?
Was steht zu den Testzeiten in den entsprechenden LOGs drin?
In deinem Post vom 04.05.2017, 17:32 fehlt mir bei der 2. Ausgabe der ipsec.conf alles zur Net2Net-Verbindung. Werden diese Daten noch nachgeliefert?

_________________
Gruß edelweis

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

Bild
Bild
Meine Vorstellung


Nach oben
   
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen  Auf das Thema antworten  [ 16 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:  
Powered by phpBB® Forum Software © phpBB Limited
Deutsche Übersetzung durch phpBB.de