The pfSense Store

Author Topic: OpenVPN + "tap Bridging Fix" - Internes Netz nicht erreichbar  (Read 2001 times)

0 Members and 1 Guest are viewing this topic.

Offline ftv_admin

  • Newbie
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Hallo liebes Forum,

wir haben in unserer Firma 2 WAN Leitungen (2x100 MBits von KabelDeutschland) und ein internes Class-A Netz (10.0.0.1). Da unser alter Router den wachsenden Anforderungen nicht mehr gewachsen war, hab ich vor ein paar Wochen einen Server mit pfSense 2.0.1 installiert.

  • Supermicro 1HE Server
  • Core i3 2600k
  • 8GB ECC Speicher
  • 128GB SSD
  • 4 x Onboard GBit-Lan => em0 bis em3 => WAN1 bis WAN4 => Group "WAN"
  • 1x 4 Port GBit Netzwerkkarte => igb0 bis igb 3 => LAN1 bis LAN4 => Group "LAN"
  • 128GB SSD

Aktuell wird nur LAN1 benutz:
  • Netz: 10.0.0.0/8
  • Gateway, DHCP, DNS alles pfSense auf 10.0.0.1
  • DHCP: dynamische Verteilung 10.20.0.1 bis 10.20.254.254, Server, VM's und Netzwerkgeräte haben feste IP's außerhalb dieses Bereiches

Mein Aktuelles Projekt besteht nun darin, ein OpenVPN-Server einzurichten, damit die Mitarbeiter von zu Hause arbeiten können und Zugriff auf die gesamten Systeme haben, die im Firmennetz zur Verfügung stehen. Ziel ist ein Zertifikat basiertes, transparentes bridged Network.

Mit Hilfe dieser Anleitung(http://hardforum.com/showthread.php?t=1663797) habe ich es geschafft, die entsprechenden Zertifikate und Keys zu erstellen, diese auf dem Server zu integrieren, den Server einzurichten und zu konfigurieren und erfolgreiche eine VPN Verbindung von außen herzustellen.

Leider ist es mir nicht möglich, von außen irgend ein System innerhalb des Firmennetzwerks zu erreichen. Weder DHCP, DNS, noch sonst irgendein System. Somit bekommt mein Client keine IP vom internen DHCP. Das führt dazu, dass auf meiner Linux Maschine auch kein tap Adapter angelegt wird.
Nachdem ich in den Einstellungen des angelegten OpenVPN-Server auf dem pfSense Router einen separaten DHCP-Bereich für die VPN Clients angelegt habe (Feld "Server Bridge DHCP Start" und "Server Bridge DHCP End" (Zweiteres heißt übrigens auch Start, bug?)), wird auf meinem Client nach dem Verbinden wenigstens ein tap-Device mit entsprechenden Parametern angelegt. Ich habe dann eine gültige IP, Netmask, Gateway, etc. Aber dennoch kann ich keinerlei Geräte im internen Netz erreichen (Ping: "unknown host"). Aus dieser Sachlage heraus vermute ich, dass die Kommunikation zwischen dem Tunnel und LAN1 nicht richtig funktioniert. Ich bin seit Stunden am Suchen und Ausprobieren, doch es klappt partout nicht. Langsam macht sich Verzweiflung bei mir breit und ich bin hier gelandet. Da mir Deutsch als Muttersprache leichter fällt als englisch, habe ich es hier probiert, würde meine Anfrage ggf. auch ins Englische portieren.

Hier noch Informationen über meine Konfiguration:

OpenVPN Server:
  • Remote Access (SSL/TLS)
  • UDP
  • tap
  • WAN1
  • 9999
  • Enable authentication of TLS packets. CHECK (Key generiert und auf den Client exportiert)
  • DH: 1024Bits
  • AES-128-CBC
  • Depth: 1 (Client + Server)
  • Tunnel Network: LEER
  • Bridge DHCP: CHECK
  • LAN1
  • Redirect Gateway: CHECK
  • Compress: CHECK
  • Communication between Clients: CHECK
  • Duplicate Connections: CHECK
  • DynIP: CHECK
  • Adress Pool: CHECK
  • DNS Server: 10.0.0.1

Firewall Rule:
  • Pass
  • WAN1
  • UDP
  • Source: any
  • Dest: WAN1 address; Port: 9999

im Bereich "Interfaces" habe ich ein neues Device hinzugefügt:
  • Interface (Name): OpenVPN_Tunnel
  • Network port: ovpns1 (mein OpenVPN-Server)

anschließend habe ich eine neue Bridge hinzugefügt:
  • BRIDGE0
  • Members: LAN1, OPENVPN_TUNNEL

Abschließend natürlich noch meinen Client konfiguriert:
Code: [Select]
client
dev tap
proto udp
remote unsere.ip.dyndns.org 9999
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/user.crt
key /etc/openvpn/user.key
tls-auth /etc/openvpn/ta.key 1
cipher AES-128-CBC
comp-lzo
verb 3
pull # war zum Testen, hat aber nichts geändert

Wenn ich mich mit dieser Konfiguration auf den Server verbinde, wird kein tap-device angelegt. Ich bekomme einen Fehler, dass die gateway-Konfiguration nicht bezogen werden kann und das Device aber einen benötigt. (siehe Logs weiter unten) Weiterhin ist in pfSense unter Status => OpenVPN zwar mein Client als "verbunden" aufgeführt, hat aber keine virtuelle IP. Logisch...
Füge ich in den Server-Einstellungen noch eine separate DHCP-Range hinzu, kommt diese Fehlermeldung nicht mehr, Kommunikation ins interne Netz ist jedoch nicht möglich. Hier wird im OpenVPN-Status der Client aber mit einer virtuellen IP angezeigt.

Ich bin mir sicher, ich habe irgendetwas übersehen. Aber ich bin Moment wirklich ratlos und hoffe, irgendwer von euch kann mir helfen.

Wenn wir eine Lösung finden, schreibe ich auch gerne nochmal eine kurze Zusammenfassung.

Logauszug des Clients:
Code: [Select]
user@client /etc/openvpn # openvpn --config client.conf --script-security 2
Wed Apr 18 18:36:49 2012 OpenVPN 2.2.0 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Jul  4 2011
Wed Apr 18 18:36:49 2012 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Apr 18 18:36:49 2012 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Enter Private Key Password:
Wed Apr 18 18:36:53 2012 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Apr 18 18:36:53 2012 WARNING: file '/etc/openvpn/ta.key' is group or others accessible
Wed Apr 18 18:36:53 2012 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Wed Apr 18 18:36:53 2012 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 18 18:36:53 2012 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 18 18:36:53 2012 LZO compression initialized
Wed Apr 18 18:36:53 2012 Control Channel MTU parms [ L:1590 D:166 EF:66 EB:0 ET:0 EL:0 ]
Wed Apr 18 18:36:53 2012 Socket Buffers: R=[126976->131072] S=[126976->131072]
Wed Apr 18 18:36:53 2012 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Wed Apr 18 18:36:53 2012 Local Options hash (VER=V4): 'a7133b47'
Wed Apr 18 18:36:53 2012 Expected Remote Options hash (VER=V4): 'c5677ab3'
Wed Apr 18 18:36:53 2012 UDPv4 link local: [undef]
Wed Apr 18 18:36:53 2012 UDPv4 link remote: [AF_INET]9.9.9.9:9999
Wed Apr 18 18:36:53 2012 TLS: Initial packet from [AF_INET]9.9.9.9:9999, sid=e19da0d4 b45b5daf
Wed Apr 18 18:36:54 2012 VERIFY OK: depth=1, /C=DE/ST=state/L=City/O=Company/CN=pfsense/emailAddress=admin@domain
Wed Apr 18 18:36:54 2012 VERIFY OK: depth=0, /C=DE/ST=state/L=City/O=Company/CN=pfsense/emailAddress=admin@domain
Wed Apr 18 18:36:55 2012 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Apr 18 18:36:55 2012 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 18 18:36:55 2012 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Apr 18 18:36:55 2012 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 18 18:36:55 2012 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Wed Apr 18 18:36:55 2012 [pfsense] Peer Connection Initiated with [AF_INET]9.9.9.9:9999
Wed Apr 18 18:36:57 2012 SENT CONTROL [pfsense]: 'PUSH_REQUEST' (status=1)
Wed Apr 18 18:36:57 2012 PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.0 255.0.0.0,dhcp-option DOMAIN local.domain,dhcp-option DNS 10.0.0.1,redirect-gateway def1,redirect-gateway local def1,ping 10,ping-restart 60'
Wed Apr 18 18:36:57 2012 OPTIONS IMPORT: timers and/or timeouts modified
Wed Apr 18 18:36:57 2012 OPTIONS IMPORT: route options modified
Wed Apr 18 18:36:57 2012 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Apr 18 18:36:57 2012 ROUTE default_gateway=192.168.9.2
Wed Apr 18 18:36:57 2012 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Wed Apr 18 18:36:57 2012 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.0.0.0
Wed Apr 18 18:36:57 2012 TUN/TAP device tap0 opened
Wed Apr 18 18:36:57 2012 TUN/TAP TX queue length set to 100
Wed Apr 18 18:36:57 2012 NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing
Wed Apr 18 18:36:57 2012 Initialization Sequence Completed

Vielen Dank schon mal an alle die sich die Mühe gemacht haben, bis hier zu lesen! (sorry)

Liebe Grüße
Christoph
« Last Edit: April 20, 2012, 07:30:29 am by ftv_admin »

Offline orcape

  • Jr. Member
  • **
  • Posts: 49
  • Karma: +0/-0
    • View Profile
Re: OpenVPN + "tap Bridging Fix" - Internes Netz nicht erreichbar
« Reply #1 on: April 20, 2012, 07:53:17 pm »
Hi ftv_admin,

ich habe zwar nur ein kleines Homenetz mit einem anderen Homenetz über Internet verbunden, das hat aber bis auf ein paar Ungereimtheiten ganz gut funktioniert. Es erreicht jeder jeden,  ;D wenn ich das will.
Das war aber auf Probleme mit dem remoten Client (DD-WRT-Router) zurückzuführen.
Was mir bei Dir auffällt ist zum ersten der fehlende Tunnelnetzeintrag.
Um auf Dein internes Netz vom Tunnel aus zu kommen, mußt Du nicht zwingend die Bridge nutzen. Da ist nur eine Firewallregel in der pfSense erforderlich, die vom LAN in den Tunnel (wenn erforderlich), bzw. vom Tunnel ins LAN führt.
Weiter ist es nicht zwingend notwendig, im Bereich Interfaces einen Eintrag für den OpenVPN-Tunnel zu machen. Im Bereich Firewallrules wird das OpenVPN-Interface automatisch nach der Konfiguration des Servers angelegt. Ich habe meinen Tunnel übrigens mit TUN am laufen, soll schneller sein.
Zieh Dir mal folgendes Tutorial rein, von aqui verständlich geschrieben, hat mir zumindest weitergeholfen.....
http://www.administrator.de/index.php?content=123285
.....außerdem kommt das Deiner Muttersprache näher.  ;)

Gruss orcape


Offline ftv_admin

  • Newbie
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: OpenVPN + "tap Bridging Fix" - Internes Netz nicht erreichbar
« Reply #2 on: April 24, 2012, 01:58:15 am »
Hallo orcape,

vielen Dank für deine Antwort.

Das war aber auf Probleme mit dem remoten Client (DD-WRT-Router) zurückzuführen.
DD-WRT-Router habe ich hier mehrere im Netzwerk als Accesspoints im Einsatz. Sind einfach D-Link Kisten. Für ihren Zweck ausreichend, aber als eigentlicher Router zu inperformant. Daher ist die Wahl auf pfSense gefallen.

Was mir bei Dir auffällt ist zum ersten der fehlende Tunnelnetzeintrag.
Kannst du mir das genauer erklären? Wozu ist der gut, wo trage ich den ein?

Um auf Dein internes Netz vom Tunnel aus zu kommen, mußt Du nicht zwingend die Bridge nutzen. Da ist nur eine Firewallregel in der pfSense erforderlich, die vom LAN in den Tunnel (wenn erforderlich), bzw. vom Tunnel ins LAN führt.
Weiter ist es nicht zwingend notwendig, im Bereich Interfaces einen Eintrag für den OpenVPN-Tunnel zu machen. Im Bereich Firewallrules wird das OpenVPN-Interface automatisch nach der Konfiguration des Servers angelegt. Ich habe meinen Tunnel übrigens mit TUN am laufen, soll schneller sein.
Die Wahl ist absichtlich auf "tap" gefallen, da es einige Services gibt, die mit einem geruoutetem Netzwerk nicht funktionieren. Auch der administrative Aufwand ist in einem gebridgetem Netzwerk für mich einfacher. Zeit ist Geld und so. ;)
Zwar soll die Einrichtung eines Bridged-Netzwerks schwieriger sein, kann ich bisher aber nicht nachvollziehen. Den OpenVPN-Server muss ich so oder so einrichten und die Brücke hinzufügen ist jetzt auch nicht die Welt.

Zieh Dir mal folgendes Tutorial rein, von aqui verständlich geschrieben, hat mir zumindest weitergeholfen.....
http://www.administrator.de/index.php?content=123285
.....außerdem kommt das Deiner Muttersprache näher.  ;)

Gruss orcape



Dein Tutorial werde ich mir mal gleich zu Gemüte ziehen. Vielen Dank dafür!
Liebe Grüße
Christoph
« Last Edit: April 24, 2012, 03:45:57 am by ftv_admin »