OpenVPN-Server auf Linux; Fritzbox->Client TAP?

[blubbersuelze]

Rechner(.5.x) - (.5.1)fritzbox(.98.220) -(VPN-Tunnel)--- server(.98.20) - (.98.x)rechner2, printserver

"Am besten wäre, wenn der APR-Cache erst leer ist und nach dem Ping "korrekt" gefüllt (richtige MAC, IP und Interface). Wenn ja, funktioniert der ARP schonmal"

das ist der Fall

Nein die Box ist mit dem Rechner2 nur über das Internet mittels VPN-Tunnel über den VPN-Server verbunden.

 

[MaxMuster]

Tja...

Mir fällt dann eigentlich nur noch der Rechner selbst ein (obwohl das ja beim Drucker auch so ist):

Zwischen Rechner und Box geht der ARP und es gehen "ganz normal" Pakete hin und her, was der Ping zeigt: "Request" geht Rechner -> Box, "Reply" Box -> Rechner. Wenn dann der Ping Box -> Rechner nicht geht, gibt es drei Möglichkeiten:
1. Die Pakete kommen nicht von Box zum Rechner oder umgekehrt (eigentlich ausgeschlossen, wenn ICMP an sich klappt, s.o.)
2. Die Box schickt garkeine Pakete für den Rechner über das TAP (warum? Auch eher unwahrscheinlich)
3. Der Rechner antwortet erst garnicht und das wäre von den Möglichkeiten die Wahrscheinlichste.

Das Problem: Der Fall 3. wäre eigentlcih nur denkbar, wenn die Box sich beim Rechner mit einer "falschen" IP meldete und auf dem Rechner z.B. eine Firewall läuft. Also eigentlich auch nicht so richtig wahrscheinlich...

Es sind zwei Dinge, die mir "Magenschmerzen" machen: ARP geht, ICMP (ping) auch, aber nur, wenn es die eine Richtung initiiert. Über die VPN-Verbindung ist auch die Verbindung zum Server immer möglich und die beiden Dinge zusammen schließen eigentlich ein generelles Problem mit der VPN-Strecke aus.

Fazit: Ausser der Möglichkeit, dass irgendwo noch ein "Security-Device" zuschlägt (FW auf dem Rechner, der VPN-Server mag über eth keine IPs, die er nicht selbst per DHCP vergeben hat oder doch noch eine obskure Einstellung in der Fritzbox) bin ich "am Ende".

Es bliebe nur noch, auf dem Rechner per Sniffer (WireShark) mal zu sehen, ob Pakete von der Box ankommen, und ob der Rechner antwortet.

Mehr fällt mir nicht ein.

Jörg

 

[finreg]

@maxmuster

Erstmal solltest du noch sagen, was nicht geht, wie sich also der Fehler darstellt.
Dann wird wohl ein Log fällig sein, indem du das vpn mit der Konfiguration ohne "daemon" startest und postest, was dann ausgegeben wird.

Was schon jetzt auffällt: Der Server nutzt TLS ("tls-server") der client nicht (kein "tls-client").

Jörg

Hallo Jörg,

hoffentlich weisst Du weiter:

Fehlerbeschreibung:
Verbindung zwischen Server und Client wird verhandelt, bricht aber ab mit Meldung "no dynamic or static remote --ifconfig address is available".
Die IPs habe ich doch für Sever und Client fest vergeben (server .1, client .3) - warum will der client die nochmal abfragen???

zu TLS:
habe mal in der man page nachgesehen, was das "tls-client" überhaupt macht -> enables tls. Dabei habe ich dann auch gleich gefunden, dass "client" gleichbedeutend mit "pull" und "tls-client" ist (beides). D.h. da ich "client" angegeben habe, habe ich auch "pull" und "tls-client".

Das Protokoll (#daemon und verb3):

# ./openvpn --config server.ovpn
Tue Nov  6 19:55:11 2007 OpenVPN 2.1_rc1 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jan  5 2007
Tue Nov  6 19:55:13 2007 Diffie-Hellman initialized with 2048 bit key
Tue Nov  6 19:55:13 2007 TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Nov  6 19:55:14 2007 TUN/TAP device tap0 opened
Tue Nov  6 19:55:14 2007 TUN/TAP TX queue length set to 100
Tue Nov  6 19:55:14 2007 /sbin/ifconfig tap0 192.168.1.1 netmask 255.255.255.0 mtu 1500 broadcast 192.168.1.255
Tue Nov  6 19:55:14 2007 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Nov  6 19:55:14 2007 Socket Buffers: R=[110592->131072] S=[110592->131072]
Tue Nov  6 19:55:14 2007 UDPv4 link local (bound): [undef]:1194
Tue Nov  6 19:55:14 2007 UDPv4 link remote: [undef]
Tue Nov  6 19:55:14 2007 MULTI: multi_init called, r=256 v=256
Tue Nov  6 19:55:14 2007 Initialization Sequence Completed
Tue Nov  6 19:55:19 2007 MULTI: multi_create_instance called
Tue Nov  6 19:55:19 2007 213.188.235.170:2062 Re-using SSL/TLS context
Tue Nov  6 19:55:19 2007 213.188.235.170:2062 LZO compression initialized
Tue Nov  6 19:55:19 2007 213.188.235.170:2062 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Nov  6 19:55:19 2007 213.188.235.170:2062 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Nov  6 19:55:19 2007 213.188.235.170:2062 Local Options hash (VER=V4): '#######'
Tue Nov  6 19:55:19 2007 213.188.235.170:2062 Expected Remote Options hash (VER=V4): '########'
Tue Nov  6 19:55:19 2007 213.188.235.170:2062 TLS: Initial packet from 213.188.235.170:2062, sid=19375e51 3e8c8fe4
Tue Nov  6 19:55:31 2007 213.188.235.170:2062 VERIFY OK: depth=1, /C=DE/ST=BW/L=#######
/O=S/emailAddress=#######@gmx.de
Tue Nov  6 19:55:31 2007 213.188.235.170:2062 VERIFY OK: depth=0, /C=DE/ST=BW/O=S/OU=S/CN=C/emailAddress=#######@gmx.de
Tue Nov  6 19:55:33 2007 213.188.235.170:2062 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Nov  6 19:55:33 2007 213.188.235.170:2062 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Nov  6 19:55:33 2007 213.188.235.170:2062 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Nov  6 19:55:33 2007 213.188.235.170:2062 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Nov  6 19:55:33 2007 213.188.235.170:2062 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Nov  6 19:55:33 2007 213.188.235.170:2062 [C] Peer Connection Initiated with 213.188.235.170:2062
Tue Nov  6 19:55:33 2007 C/213.188.235.170:2062 MULTI: no dynamic or static remote --ifconfig address is available for C/213.188.235.170:2062
Tue Nov  6 19:55:34 2007 C/213.188.235.170:2062 PUSH: Received control message: 'PUSH_REQUEST'
Tue Nov  6 19:55:34 2007 C/213.188.235.170:2062 SENT CONTROL [C]: 'PUSH_REPLY,ping 10,ping-restart 60' (status=1)

Mit dem push request kann ich nichts anfangen.
Irgendeine Idee?

Danke

uwe

 

[MaxMuster]

Hi finreg

bricht aber ab mit Meldung "no dynamic or static remote --ifconfig address is available".
Die IPs habe ich doch für Sever und Client fest vergeben (server .1, client .3) - warum will der client die nochmal abfragen???

So wie ich das sehe, wird die Verbindung nicht abgebrochen. Der Server stellt nur fest, dass er weder eine "feste IP" noch eine "Pool IP" für diesen Client hat. Danach schickt er halt nur ping und ping-restart

D.h. da ich "client" angegeben habe, habe ich auch "pull" und "tls-client".

Jepp, hatte ich nicht gesehen / bemerkt.

Mit dem push request kann ich nichts anfangen.

Das ist das "pull" (aus dem von dir schon erwähnten "client"), also die Aufforderung, was zu schicken...

Wie sieht denn das Log beim Client aus?
(Übrigens: Pack solche Logs bitte zwischen [noparse]

 und

[/noparse] damit der Post nicht zu lang und unübersichtlich wird.)

Jörg

 

[finreg]

So wie ich das sehe, wird die Verbindung nicht abgebrochen. Der Server stellt nur fest, dass er weder eine "feste IP" noch eine "Pool IP" für diesen Client hat. Danach schickt er halt nur ping und ping-restart

[\QUOTE ]

@maxmuster

Jau. Das sehe ich auch so. Und wat nu?

Protokoll vom Client kann ich erst in einer Woche liefern, wenn ich mal wieder dort bin (Ausland). Da erwarte ich mir nichts von. Offenkundig hängt's doch daran, dass der Server meint er müsse / solle eine IP vergeben und das nicht kann. Dabei ist das doppelt seltsam: a) ist die IP für den Client längst vergeben und b) hat die Serverbox als DHCP server jede Menge IPs zu vergeben.

Hat jemand eine Idee?

Uwe

 

[finreg]

Ich habe jetzt der virtuellen Netzwerkkarte von Hand eine IP gegeben und es funktioniert alles super von der Fritzbox aus.

Hallo Blubbersuelze!

Wie geht das "von Hand eine IP geben"?

Danke

Uwe

 

[MaxMuster]

Auch wenn ich nicht blubbersuelze bin:
Das hast du schon gemacht, mit "ifconfig 192.168.1.3 255.255.255.0" in der Client-Config.

Protokoll [...] erwarte ich mir nichts von. Offenkundig hängt's doch daran, dass der Server meint er müsse / solle eine IP vergeben und das nicht kann. Dabei ist das doppelt seltsam: a) ist die IP für den Client längst vergeben und b) hat die Serverbox als DHCP server jede Menge IPs zu vergeben.

Das denke ich nicht. Genau das Protokoll wird vermutlich "die Lösung enthalten". Die Tatsache, dass der Server auch DHCP-Server ist, hat mit der VPN-Internen IP-Vergabe nichts zu tun.
Ich würde dir noch folgendes Vorschlagen:
Ändere die TAP-IPs auf andere, als die des LAN (als z.B. die "1-er" auf .5 die "3-er" auf .6)
Vieilleicht stört sich die Client-Box an den "geänderten ping-Zeiten" im push. Du könntest also auf dem Server auch "keepalive 30 60" nehmen

Bliebe noch die Möglichkeit, genau diese Client-Config von einem anderen Client zu testen (evtl auch mit einem "internen" Client aus dem LAN mit dann geädertem "remote xxx" ) um zu sehen, was der so im Log sagt.

Jörg