Freetz: FB 5140 als OpenVPN Client (swissvpn)

[easy12]

Hier der Routing ohne vpn

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.178.0 * 255.255.255.0 U 0 0 0 lan
192.168.179.0 * 255.255.255.0 U 0 0 0 guest
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default p5B288A32.dip0. 0.0.0.0 UG 0 0 0 dsl

Hier mit vpn

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.11.29 * 255.255.255.255 UH 0 0 0 tun0
213.229.71.81 p5B288A32.dip0. 255.255.255.255 UGH 0 0 0 dsl
192.168.178.0 * 255.255.255.0 U 0 0 0 lan
192.168.179.0 * 255.255.255.0 U 0 0 0 guest
10.10.11.0 10.10.11.29 255.255.255.0 UG 0 0 0 tun0
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default 10.10.11.29 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 10.10.11.29 128.0.0.0 UG 0 0 0 tun0
default p5B288A32.dip0. 0.0.0.0 UG 0 0 0 dsl

Hier Log

Wed Nov 17 21:07:00 2010 [UNDEF] Inactivity timeout (--ping-restart), restarting
Wed Nov 17 21:07:00 2010 TCP/UDP: Closing socket
Wed Nov 17 21:07:00 2010 SIGUSR1[soft,ping-restart] received, process restarting
Wed Nov 17 21:07:00 2010 Restart pause, 2 second(s)
Wed Nov 17 21:07:02 2010 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Nov 17 21:07:02 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Nov 17 21:07:02 2010 Re-using SSL/TLS context
Wed Nov 17 21:07:02 2010 LZO compression initialized
Wed Nov 17 21:07:02 2010 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Wed Nov 17 21:07:02 2010 Socket Buffers: R=[108544->131072] S=[108544->131072]
Wed Nov 17 21:07:02 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Nov 17 21:07:02 2010 UDPv4 link local: [undef]
Wed Nov 17 21:07:02 2010 UDPv4 link remote: [AF_INET]213.229.71.81:1194
Wed Nov 17 21:07:02 2010 TLS: Initial packet from [AF_INET]213.229.71.81:1194, sid=5714cfe0 3f6ce888
Wed Nov 17 21:07:02 2010 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Nov 17 21:07:02 2010 VERIFY OK: depth=1, /C=GB/ST=GB/L=London/O=VPNUK/CN=VPNUK_CA/[email protected]
Wed Nov 17 21:07:02 2010 VERIFY OK: depth=0, /C=GB/ST=GB/L=London/O=VPNUK/CN=server/[email protected]
Wed Nov 17 21:07:03 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Nov 17 21:07:03 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Nov 17 21:07:03 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Nov 17 21:07:03 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Nov 17 21:07:03 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Nov 17 21:07:03 2010 [server] Peer Connection Initiated with [AF_INET]213.229.71.81:1194
Wed Nov 17 21:07:05 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Nov 17 21:07:05 2010 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option NTP 10.10.11.1,dhcp-option DNS 10.10.11.1,ping-timer-rem,route 10.10.11.0 255.255.255.0,topology net30,ping 10,ping-restart 60,ifconfig 10.10.11.30 10.10.11.29'
Wed Nov 17 21:07:05 2010 OPTIONS IMPORT: timers and/or timeouts modified
Wed Nov 17 21:07:05 2010 OPTIONS IMPORT: --ifconfig/up options modified
Wed Nov 17 21:07:05 2010 OPTIONS IMPORT: route options modified
Wed Nov 17 21:07:05 2010 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Nov 17 21:07:05 2010 TUN/TAP device tun0 opened
Wed Nov 17 21:07:05 2010 TUN/TAP TX queue length set to 100
Wed Nov 17 21:07:05 2010 /sbin/ifconfig tun0 10.10.11.30 pointopoint 10.10.11.29 mtu 1500
Wed Nov 17 21:07:07 2010 /sbin/route add -net 213.229.71.81 netmask 255.255.255.255 gw 91.40.138.50
Wed Nov 17 21:07:07 2010 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.10.11.29
Wed Nov 17 21:07:07 2010 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.10.11.29
Wed Nov 17 21:07:07 2010 /sbin/route add -net 10.10.11.0 netmask 255.255.255.0 gw 10.10.11.29
Wed Nov 17 21:07:07 2010 Initialization Sequence Completed
Wed Nov 17 21:10:56 2010 event_wait : Interrupted system call (code=4)
Wed Nov 17 21:10:56 2010 TCP/UDP: Closing socket
Wed Nov 17 21:10:56 2010 /sbin/route del -net 10.10.11.0 netmask 255.255.255.0
Wed Nov 17 21:10:56 2010 /sbin/route del -net 213.229.71.81 netmask 255.255.255.255
Wed Nov 17 21:10:56 2010 /sbin/route del -net 0.0.0.0 netmask 128.0.0.0
Wed Nov 17 21:10:56 2010 /sbin/route del -net 128.0.0.0 netmask 128.0.0.0
Wed Nov 17 21:10:56 2010 Closing TUN/TAP interface
Wed Nov 17 21:10:56 2010 /sbin/ifconfig tun0 0.0.0.0
Wed Nov 17 21:10:56 2010 SIGTERM[hard,] received, process exiting

 

[MaxMuster]

Das sieht doch gut aus, so sollte es sein:

Zunächst:

213.x.x.x p5B288A32.dip0. 255.255.255.255 UGH 0 0 0 dsl

Sorgt für die Route zum VPN-Server über das "normale" Gateway, denn der VPN-Server kann ja nicht durch den Tunnel erreicht werden.

Das "redirect-gateway" ist als "redirect-gateway def1" ausgeführt, so werden zwei "passendere" Routen für die beiden Netzbereiche "unter" und "ab" "128.0.0.0" (also für 0.0.0.0/1 und 128.0.0.0/1) gesetzt:

default 10.10.11.29 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 10.10.11.29 128.0.0.0 UG 0 0 0 tun0

Die "alte" Default Route bleibt erhalten, sie greift nur nicht, solange die anderen beiden in der Routingtabelle sind.

Was geht denn nicht? Du solltest jetzt von der Box aus durch das VPN ins Internet gelangen.
Da ohne iptables nur die Box vom Server erreicht werden kann, teste erst das.
Wenn es mit der Box klappt, liegt es wohl an der iptables Konfiguration.

Jörg

 

[easy12]

Was geht denn nicht? Du solltest jetzt von der Box aus durch das VPN ins Internet gelangen.

Genau das gelingt nicht , ping auf Inet-Seiten von der Box geht nicht.
Fehler ping:bad address (z.Bwww.heise.de )Das inet ist schon von der Box aus nicht erreichbar.

 

[MaxMuster]

Welchen DNS nutzt du (cat /etc/resolv.conf)?
Geht ein Ping auf die IP direkt (193.99.144.80)?

Jörg

EDIT: Kannst du übrigens die "Gegenseite" (10.10.11.29 bzw. 10.10.11.1) anpingen?

 

[easy12]

Welchen DNS nutzt du (cat /etc/resolv.conf)?

nameserver 127.0.0.1 domain fonwlan.box

Geht ein Ping auf die IP direkt (193.99.144.80)?

Ja ping funktioniert auf 192.99.144.80

Kannst du übrigens die "Gegenseite" (10.10.11.29 bzw. 10.10.11.1) anpingen?

10.10.11.29 ping geht nicht
10.10.11.1 ping geht

 

[MaxMuster]

Du musst den DNS-Eintrag ändern, vermute ich mal (der gilt allerdings nur für die Box selbst): Versuche doch mal ein

echo "nameserver 10.10.11.1" > /etc/resolv.conf

Jörg

 

[easy12]

Ich habe die o.g änderung umgesetz , danach ping vom telnet(Box) auf Inet okay , vom Rechner aus, ping auf Inet geht nicht.

 

[MaxMuster]

Mach mal auf dem PC im Browser die Seite von Heise "per IP" auf (also statt heise.de die o.g. IP).
Wenn das geht, musst du auch an den Clients den DNS umstellen, oder den "AVM-DNS" umsetzen.

Eine Möglichkeit: Wenn du in "/tmp/avm-resolv.conf" die Einträge auf "10.10.11.1" änderst, hilft das?

Weitere Möglichkeit: Hast du in deiner ar7.cfg "overwrite_dns1" und "overwrite_dns2"? Dann trage da versuchsweise auch "10.10.11.1" ein (wie immer: Vorsicht bei Änderungen an der ar7.cfg)

Jörg

 

[easy12]

Wenn ich die Seiten per "IP" aufrufe dann geht es.
Die o.g änderungen 1 und 2 bleiben jedoch wirkungslos.
Was mir noch aufgefallen ist , sobald openvpn läuft , bin ich telefonisch nicht erreichbar(voip) , ausgehende Gespräche gehen aber.

 

[MaxMuster]

Naja, wenn du das DG umstellst geht eben auch alles durch den Tunnel, und speziell die AVM-Iplementierung hat mit nicht-Standardsituationen manchmal so ihre Probleme. Du musst sehen, dass die Box ja aus "VoIP-Sicht" direkt keine öffentliche IP mehr hat, sondern durch den Tunnel geht (obwohl diese IP ja vorhanden ist).

Und wenn du deinen Ansatz mal überdenkst und anpasst? Was vielleicht einfacher wäre:

- Keine Änderung des DG auf der Box (damit sollten DNS und VoIP wie normal laufen)
- Nur per iptables/NAT den LAN-Verkehr, der ansonsten ins Netz ginge (alles lokale wie DNS soll lokal bleiben), über den Tunnel schieben? So aus der Hüfte geschossen die iptables-Regel erweitern um "-d ! 192.168.178.0/24".


Jörg

 

[easy12]

Erstmal herzlichen Dank , für deine ausdauer mich mit Rat und Tat bei der Problemlösung zur unterstützen.Daaaaannnnke!!!!!
Die Box scheint einige "Kinderkrankheiten" zu haben .Tja nichts ist perfekt.
Dein Vorschlag Lan-Verkeher zu tunneln werde ich warscheinlich umsetzen , obwohl es mir lieber währe alles über den Tunnel zu schicken wie ich das vor gehabt habe , aber leider nicht realisierbar ist.Trotzdem nochmal Danke, ich habe dank deine (eure) Hilfe einiges dazugelernt.Man sieht ,was für Kompetente Mitglieder das Forum hat.Ich bin sehr positiv überrascht.