OpenVPN Box-zu-Box

[molfi]

Hallo Leute.

Nachdem ich mir in den letzten Wochen soviel Wissen hier anlesen konnte (Friboli, ds mod, dnsmasq, inadyn, wol, virtualip etc) scheitere ich nun doch daran, zwei Fritzboxen per VPN miteinander zu verbinden.

Ich möchte folgende Verbindung herstellen:
Fritzbox 7050 - OpenVPN Server (192.168.178.x Netzwerk)
Fritzbox 7170 - OpenVPN Client (192.168.123.x Netzwerk)
zusätzlich soll die Möglichkeit bestehen, sich mit einem weiteren Client zu verbinden.


Zertifikate etc habe ich erstellen können und sind in beiden Boxen gespeichert. OpenVPN lässt sich auf beiden Boxen auch starten (tauchen in der Prozessliste auf). Eine Portfreigabe 1194 auf die Serverbox habe ich mit virtualip geschaltet.

Mit folgender Konfiguration (eingestellt über die ds mod GUI) fahre ich den Server:

# OpenVPN 2.1 Config
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
mode server
tls-server
dh /tmp/flash/dh.pem
tls-auth /tmp/flash/static.key 0
ifconfig-pool 192.168.200.4 192.168.200.251
ifconfig 192.168.200.1 192.168.200.2
route 192.168.200.0 255.255.255.0
push "route 192.168.200.0 255.255.255.0"
push "route 192.168.178.0 255.255.255.0"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher AES-256-CBC
route 192.168.123.0 255.255.255.0
comp-lzo
keepalive 10 120
status /var/log/openvpn.log

Mit dieser Konfiguration fährt der Client:

# OpenVPN 2.1 Config
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
tls-client
ns-cert-type server
tls-auth /tmp/flash/static.key 1
pull
remote [I]dydnseintrag.dyn.net[/I]
nobind
ifconfig 192.168.200.2 192.168.200.1
tun-mtu 1500
mssfix

daemon
verb 3

cipher AES-256-CBC
route 192.168.178.0 255.255.255.0
comp-lzo
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log

Der Befehl route ergibt für den Server:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
192.168.200.2   *               255.255.255.255 UH    0      0        0 tun0
192.168.178.0   *               255.255.255.0   U     0      0        0 lan
192.168.178.0   *               255.255.255.0   U     0      0        0 eth0
192.168.200.0   192.168.200.2   255.255.255.0   UG    0      0        0 tun0
192.168.123.0   192.168.200.2   255.255.255.0   UG    0      0        0 tun0
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl

und für den Client:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
169.254.1.0     *               255.255.255.0   U     0      0        0 lan
192.168.123.0   *               255.255.255.0   U     0      0        0 lan
192.168.123.0   *               255.255.255.0   U     0      0        0 eth0
default         *               0.0.0.0         U     2      0        0 dsl

Ich bekomme jedoch keine Verbindung zustande.


Was mir auffällt ist, dass auf dem Client kein tun interface in der route Tabelle angezeigt wird. Auch der Befehl ifconfig zeigt kein tun Interface.


Ich habe schon gelesen wie ein wilder, finde aber keine Lösung. Weder hier im Forum, noch im Wiki oder auf externen Seiten.

Weiß jemand Rat? Und kann mir einen konkreten Hinweis geben, was evtl. falsch an der Konfiguration ist bzw. was ich evtl in der gesamten Prozedur vergessen haben könnte?


Gruß und Dank
molfi

 

[MaxMuster]

Ich würde zunächst mal das Log auf dem Client ansehen. Dafür Config von /mod/etc nach /var/tmp kopieren, openvpn stoppen, in der "tmp-config" das deamon rausnehmen und evtl den verb-Wert auf 6 erhöhen, dann openvpn --config /var/tmp/<openvpn-config> starten. Vermutlich siehst du dann schon mehr..
(Ich vermute ja, dass der Server nicht richtig erreicht wird, also die Port-Weiterleitung nicht richtig klappt. Ist die in der ar7.cfg eingetragen? Wie?)

Jörg

 

[hermann72pb]

Ich stimme MaxMuster mit ar7.cfg zu. Mach lieber die Portfreigabe darüber. Über VirtualIP wurde hier schon oft genug berichtet, dass es nicht immer 100% funktioniert, vor allem mit OpenVPN.

MfG

 

[molfi]

Hallo. Sorry für die späte Antwort. Also, ich habe das mit der "tmp-config" mal ausprobiert. Folgende Zeilen hat openvpn auf der Konsole ausgegeben:

/var/tmp $ openvpn --config /var/tmp/openvpn-lzo.conf
Wed Jul 11 19:37:06 2007 us=524670 OpenVPN 2.1_rc2 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jun 14 2007
Wed Jul 11 19:37:06 2007 us=867741 Diffie-Hellman initialized with 1024 bit key
Wed Jul 11 19:37:06 2007 us=879114 WARNING: file '/tmp/flash/box.key' is group or others accessible
Wed Jul 11 19:37:06 2007 us=900238 Control Channel Authentication: using '/tmp/flash/static.key' as a OpenVPN static key file
Wed Jul 11 19:37:06 2007 us=904891 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jul 11 19:37:06 2007 us=907418 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jul 11 19:37:06 2007 us=911775 TLS-Auth MTU parms [ L:1558 D:166 EF:66 EB:0ET:0 EL:0 ]
Wed Jul 11 19:37:06 2007 us=931131 TUN/TAP device tun0 opened
Wed Jul 11 19:37:06 2007 us=934192 TUN/TAP TX queue length set to 100
Wed Jul 11 19:37:06 2007 us=937092 /sbin/ifconfig tun0 192.168.200.1 pointopoint 192.168.200.2 mtu 1500
Wed Jul 11 19:37:07 2007 us=15053 /sbin/route add -net 192.168.200.0 netmask 255.255.255.0 gw 192.168.200.2
Wed Jul 11 19:37:07 2007 us=80752 /sbin/route add -net 192.168.123.0 netmask 255.255.255.0 gw 192.168.200.2
Wed Jul 11 19:37:07 2007 us=146287 Data Channel MTU parms [ L:1558 D:1450 EF:58:EB:135 ET:0 EL:0 AF:3/1 ]
Wed Jul 11 19:37:07 2007 us=149217 Socket Buffers: R=[110592->131072] S=[110592->131072]
Wed Jul 11 19:37:07 2007 us=152136 UDPv4 link local (bound): [undef]:1194
Wed Jul 11 19:37:07 2007 us=154972 UDPv4 link remote: [undef]
Wed Jul 11 19:37:07 2007 us=158203 MULTI: multi_init called, r=256 v=256
Wed Jul 11 19:37:07 2007 us=161511 IFCONFIG POOL: base=192.168.200.4 size=62
Wed Jul 11 19:37:07 2007 us=166166 Initialization Sequence Completed
Wed Jul 11 19:37:07 2007 us=173804 Authenticate/Decrypt packet error: packet HMAC authentication failed
Wed Jul 11 19:37:07 2007 us=176299 TLS Error: incoming packet authentication failed from [I]"CLIENT"[/I]:4516
Wed Jul 11 19:37:08 2007 us=45993 TLS Error: cannot locate HMAC in incoming packet from [I]"SERVER"[/I]:2941

Ich habe schon ein wenig nach dieser Fehlermeldung gesucht, habe aber keine brauchbaren Ergebnisse gefunden.

Kennt ihr diese Meldung?

Gruß
molfi

 

[s.panzer]

Hallo,

der static.key muß auf beiden Boxen identisch sein, wenn Du mit TLS-auth arbeitest.

Bei dir gibt es hier eine Fehlermeldung!

Kopier´ mal den Static.kex vom Server und füg ihn beim client ein.

Damit müßte dieser fehler weg sein.

Dann schaun mir mal!

Gruß

s.panzer

 

[pixelpeter]

Hi,

Lasse bitte diese Zeilen beim Server weg:
"ifconfig 192.168.200.1 192.168.200.2"
"route 192.168.200.0 255.255.255.0"
"push "route 192.168.200.0 255.255.255.0"
"push "route 192.168.178.0 255.255.255.0"
"mode server"
"dev tun"

Dafür:
"server 192.168.200.0 255.255.255.0"
"dev tap"

Lasse bitte diese Zeilen beim Client weg:
"remote dydnseintrag.dyn.net"
"nobind"
"ifconfig 192.168.200.2 192.168.200.1"
"dev tun"

Dafür:
"client"
"dev tap"
"remote dydnseintrag.dyn.net 1194"


Viel Spaß
Peter

 

[MaxMuster]

Ich weiß, ich handel mir damit immer "unangenehme Diskussionen" ein, aber:
Warum sollte man ein Site-to-Site VPN mit Bridging aufbauen? Der gewählte Ansatz mit Tunnel ist schon ganz o.k. und der Hinweis oben von s.panzer ist der richtige: TLS Error: cannot locate HMAC in incoming packet from ... weist lediglich auf Probleme mit der TLS Authentifizierung hin (falscher Key oder die eine Seite nutzt tls-auth und die andere nicht...

Also mein Rat: Bleib beim Tunnel und schau dir die Keys an (oder lass tls-auth ggf. einfach mal weg).

Jörg