Internet tunneln mit OpenVPN

Binfort

Well-Known Member
Hallo,

wir haben bei uns in der Firma einen OpenVPN Server eingerichtet und wollen nun so aus dem Internet sicher in unser Firmennetz gelangen.

Dazu hatten wir eine OpenVPN Server-Client Testumgebung aufgebaut um die Konfiguration, nicht zuletzt mit Hilfe von BSD-Foren.de :belehren: , zu erarbeiten.

Der Tunnel funktionierte im LAN ganz vorzüglich und wir haben den OpenVPN Server auf einem OpenBSD Server eingerichtet, welcher später über eine feste IP im www zu erreichen ist. (natürlich mit "packetfilter" Firewall)

Und jetzt das Problem:

Solange wir uns mit dem VPNServer aus dem Netzwerk (über einen Hub an welchem auch das Kabel zum Router, und dann ins www, hängt) den Tunnel aufbauen funktioniert alles bestens, www Anfragen werden gleich vom Server aus ins Internet geleitet, nicht über den Firmenproxy, und Anfragen ins Firmennetz funktionieren auch allerbestens (Surfen auf den Intranetseiten, Zugriff auf Ressourcen und Mailverkehr über den Mailserver).

Wenn wir aber den Tunnel aus dem I-Net heraus aufbauen, wird die Verbindung zwar hergestellt, aber es läßt sich kein Server erreichen, keine www Anfrage wird weitergeleitet, nichteinmal die virtuelle IP des OpenVPN Servers läßt sich anpingen (verwunderlich weil der Tunnel aufgebaut wurde).

Wir vermuten das es mit dem MTU Wert, und evtl. mit der Fragmentgröße zusammenhängt. Im Moment ist am Server ein MTU von 1500 eingestellt (vorher 1492) und eine Fragmentgröße von 1300. Im LAN gab es mit beiden Einstellungen keine Probleme.

Gleichzeitig haben wir mit TCPDump auf tun_0 den ankommenden Netzwerkverkehr belauscht, beim Tunnel aus dem LAN wurde alles geloggt, aber beim Tunnel aus dem www kam gar nichts!!!

Kurz noch die Anbindung der Firma ans www: der VPNServer hat ne öffentliche IP und ist erst über einen Cisco-Router mit einem .x25 Connector verbunden, von dort gelangen wir über eine auf 2MBit gebündelte ISDN Leitung und der Gegenstelle beim Provider ins Internet.

Weiß manchmal jemand mit welcher MTU-Größe wir in dieser aussergewöhnlichen Konfiguartion arbeiten können, oder gibt es Erfahrungsberichte anderer User, welche mit OpenVPN das www tunneln?


Nochmal zum mitmeißeln :ugly: der Tunnel funktionierte bestens, daher sehe ich keinen Grund hier ne Konfigurationsdatei zu posten, sollte doch jemand darauf bestehen, läßt sich das natürlich arrangieren :rolleyes: aber wie gesagt: der Tunnel funzt (in der Theorie)
 
Binfort schrieb:
Wenn wir aber den Tunnel aus dem I-Net heraus aufbauen, wird die Verbindung zwar hergestellt, aber es läßt sich kein Server erreichen, keine www Anfrage wird weitergeleitet, nichteinmal die virtuelle IP des OpenVPN Servers läßt sich anpingen (verwunderlich weil der Tunnel aufgebaut wurde).

Ich vermute Dir fehlt eine Route um die Rechner hinter dem Tunnelendpunkt zu erreichen. Stattdessen wird die Defaultroute verwendet, wobei das Gateway mit den privaten IP-Adressen natürlich nichts anfangen kann.

Ciao,
Frank
 
Wenn es ein Routenproblem ist, ist die Aussage, dass der Tunnel im LAN funktioniert, auch sehr schwach. Dann ist der Datenverkehr unter Umständen gar nicht oder nicht komplett durch den Tunnel gegangen.
 
das Routenproblem kann ich ausschliessen da der Tunnel über LAN wunderbar funktioniert. Nur eben wenn wir aus dem I-Net kommen ist am VPN-Server Schluss und nicht mal er selber lässt sich anpingen.

Hier mal die Routing Optionen aus der server.conf:

Code:
push "route 192.168.17.0 255.255.255.192"
push "route 192.168.17.64 255.255.255.192"
push "route 192.168.17.128 255.255.255.192"
push "route 192.168.17.224 255.255.255.224"

push "redirect-gateway local def1"

Den Beweis für das Funktionieren des Tunnels bekamen wir durch das Abhören des Tun Interfaces mit TCPDump und das Netzwerk Interface des Clientrechners bekam im LAN eine "öffentliche" IP aus dem Bereich in welchem auch die Öffentliche IP des VPN-Servers liegt. In der Konfiguration hätten wir unsere Rechner in den Firmennetzen nie ohne Tunnel erreicht.
 
Poste doch mal das OpenVPN Log des Internet-Clients und ein netstat, trace usw.
Sonst wird das so nix...
 
okay, zuerst das OpenVPN Log vom I-Net Client:

Code:
Tue Oct 17 13:45:32 2006 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
Tue Oct 17 13:45:32 2006 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Oct 17 13:45:32 2006 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Tue Oct 17 13:45:32 2006 LZO compression initialized
Tue Oct 17 13:45:32 2006 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Oct 17 13:45:32 2006 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Oct 17 13:45:32 2006 Local Options hash (VER=V4): '22188c5b'
Tue Oct 17 13:45:32 2006 Expected Remote Options hash (VER=V4): 'a8f55717'
Tue Oct 17 13:45:32 2006 UDPv4 link local: [undef]
Tue Oct 17 13:45:32 2006 UDPv4 link remote: 1.2.3.4:1194
Tue Oct 17 13:45:32 2006 TLS: Initial packet from 1.2.3.4:1194, sid=d6a400ec 8e936abe
Tue Oct 17 13:45:33 2006 VERIFY OK: depth=1, /C=DE/ST=Hamburg/L=Hamburg/O=domain_GmbH/OU=Certificate_Authority/CN=domain_Certificate_Authority/emailAddress=webmaster@domain.de
Tue Oct 17 13:45:33 2006 VERIFY OK: depth=0, /CN=VPN-Server/C=DE/L=Hamburg/ST=HH/O=domain_GmbH/OU=IT/emailAddress=webmaster@domain.de
Tue Oct 17 13:45:34 2006 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1590'
Tue Oct 17 13:45:34 2006 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
Tue Oct 17 13:45:34 2006 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Oct 17 13:45:34 2006 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Oct 17 13:45:34 2006 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Oct 17 13:45:34 2006 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Oct 17 13:45:34 2006 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Oct 17 13:45:34 2006 [VPN-Server] Peer Connection Initiated with 1.2.3.4:1194
Tue Oct 17 13:45:36 2006 SENT CONTROL [VPN-Server]: 'PUSH_REQUEST' (status=1)
Tue Oct 17 13:45:36 2006 PUSH: Received control message: 'PUSH_REPLY,route 192.168.17.0 255.255.255.192,route 192.168.17.64 255.255.255.192,route 192.168.17.128 255.255.255.192,route 192.168.17.224 255.255.255.224,redirect-gateway local def1,dhcp-option DNS 192.168.17.125,dhcp-option WINS 192.168.17.126,route 192.168.16.1,ping 30,ping-restart 300,ifconfig 192.168.16.6 192.168.16.5'
Tue Oct 17 13:45:36 2006 OPTIONS IMPORT: timers and/or timeouts modified
Tue Oct 17 13:45:36 2006 OPTIONS IMPORT: --ifconfig/up options modified
Tue Oct 17 13:45:36 2006 OPTIONS IMPORT: route options modified
Tue Oct 17 13:45:36 2006 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Oct 17 13:45:36 2006 TAP-WIN32 device [VPN-Interface] opened: \\.\Global\{8D6D40E4-A736-453B-ABA1-200477E7AB6A}.tap
Tue Oct 17 13:45:36 2006 TAP-Win32 Driver Version 8.4 
Tue Oct 17 13:45:36 2006 TAP-Win32 MTU=1500
Tue Oct 17 13:45:36 2006 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.16.6/255.255.255.252 on interface {8D6D40E4-A736-453B-ABA1-200477E7AB6A} [DHCP-serv: 192.168.16.5, lease-time: 31536000]
Tue Oct 17 13:45:36 2006 Successful ARP Flush on interface [262150] {8D6D40E4-A736-453B-ABA1-200477E7AB6A}
Tue Oct 17 13:45:36 2006 TEST ROUTES: 0/0 succeeded len=5 ret=0 a=0 u/d=down
Tue Oct 17 13:45:36 2006 Route: Waiting for TUN/TAP interface to come up...
Tue Oct 17 13:45:36 2006 TEST ROUTES: 0/0 succeeded len=5 ret=0 a=0 u/d=down
Tue Oct 17 13:45:36 2006 Route: Waiting for TUN/TAP interface to come up...
Tue Oct 17 13:45:37 2006 TEST ROUTES: 6/6 succeeded len=5 ret=1 a=0 u/d=up
Tue Oct 17 13:45:37 2006 route ADD 0.0.0.0 MASK 128.0.0.0 192.168.16.5
Tue Oct 17 13:45:37 2006 Route addition via IPAPI succeeded
Tue Oct 17 13:45:37 2006 route ADD 128.0.0.0 MASK 128.0.0.0 192.168.16.5
Tue Oct 17 13:45:37 2006 Route addition via IPAPI succeeded
Tue Oct 17 13:45:37 2006 route ADD 192.168.17.0 MASK 255.255.255.192 192.168.16.5
Tue Oct 17 13:45:37 2006 Route addition via IPAPI succeeded
Tue Oct 17 13:45:37 2006 route ADD 192.168.17.64 MASK 255.255.255.192 192.168.16.5
Tue Oct 17 13:45:37 2006 Route addition via IPAPI succeeded
Tue Oct 17 13:45:37 2006 route ADD 192.168.17.128 MASK 255.255.255.192 192.168.16.5
Tue Oct 17 13:45:37 2006 Route addition via IPAPI succeeded
Tue Oct 17 13:45:37 2006 route ADD 192.168.17.224 MASK 255.255.255.224 192.168.16.5
Tue Oct 17 13:45:37 2006 Route addition via IPAPI succeeded
Tue Oct 17 13:45:37 2006 route ADD 192.168.16.1 MASK 255.255.255.255 192.168.16.5
Tue Oct 17 13:45:37 2006 Route addition via IPAPI succeeded
Tue Oct 17 13:45:37 2006 Initialization Sequence Completed

jetzt ein "netstat -an"

Code:
Aktive Verbindungen

  Proto  Lokale Adresse         Remoteadresse          Status
  TCP    0.0.0.0:135            0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:445            0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:902            0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:912            0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:1075           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:3700           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:3820           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:3920           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:4848           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:7676           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:8080           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:8181           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:8686           0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:1036         0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:1037         127.0.0.1:1038         HERGESTELLT
  TCP    127.0.0.1:1038         127.0.0.1:1037         HERGESTELLT
  TCP    127.0.0.1:1039         127.0.0.1:1040         HERGESTELLT
  TCP    127.0.0.1:1040         127.0.0.1:1039         HERGESTELLT
  TCP    127.0.0.1:1041         127.0.0.1:1042         HERGESTELLT
  TCP    127.0.0.1:1042         127.0.0.1:1041         HERGESTELLT
  TCP    127.0.0.1:1043         127.0.0.1:1044         HERGESTELLT
  TCP    127.0.0.1:1044         127.0.0.1:1043         HERGESTELLT
  TCP    127.0.0.1:1045         127.0.0.1:1046         HERGESTELLT
  TCP    127.0.0.1:1046         127.0.0.1:1045         HERGESTELLT
  TCP    127.0.0.1:1047         127.0.0.1:1048         HERGESTELLT
  TCP    127.0.0.1:1048         127.0.0.1:1047         HERGESTELLT
  TCP    127.0.0.1:1051         127.0.0.1:1052         HERGESTELLT
  TCP    127.0.0.1:1052         127.0.0.1:1051         HERGESTELLT
  TCP    127.0.0.1:1111         0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:1113         0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:1114         0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:1123         0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:1753         127.0.0.1:1754         HERGESTELLT
  TCP    127.0.0.1:1754         127.0.0.1:1753         HERGESTELLT
  TCP    127.0.0.1:1756         127.0.0.1:1757         HERGESTELLT
  TCP    127.0.0.1:1757         127.0.0.1:1756         HERGESTELLT
  TCP    127.0.0.1:1758         127.0.0.1:1759         HERGESTELLT
  TCP    127.0.0.1:1759         127.0.0.1:1758         HERGESTELLT
  TCP    127.0.0.1:1760         127.0.0.1:1761         HERGESTELLT
  TCP    127.0.0.1:1761         127.0.0.1:1760         HERGESTELLT
  TCP    127.0.0.1:1829         127.0.0.1:1036         WARTEND
  TCP    127.0.0.1:1830         127.0.0.1:1832         HERGESTELLT
  TCP    127.0.0.1:1831         127.0.0.1:1833         WARTEND
  TCP    127.0.0.1:1832         127.0.0.1:1830         HERGESTELLT
  TCP    127.0.0.1:1834         127.0.0.1:1835         HERGESTELLT
  TCP    127.0.0.1:1835         127.0.0.1:1834         HERGESTELLT
  TCP    127.0.0.1:1836         127.0.0.1:1837         HERGESTELLT
  TCP    127.0.0.1:1837         127.0.0.1:1836         HERGESTELLT
  TCP    127.0.0.1:1838         127.0.0.1:1839         HERGESTELLT
  TCP    127.0.0.1:1839         127.0.0.1:1838         HERGESTELLT
  TCP    127.0.0.1:1840         127.0.0.1:1111         WARTEND
  TCP    127.0.0.1:1850         127.0.0.1:1111         WARTEND
  TCP    127.0.0.1:12025        0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:12080        0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:12110        0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:12119        0.0.0.0:0              ABHÖREN
  TCP    127.0.0.1:12143        0.0.0.0:0              ABHÖREN
  TCP    192.168.16.6:139       0.0.0.0:0              ABHÖREN
  TCP    192.168.102.1:139      0.0.0.0:0              ABHÖREN
  TCP    192.168.199.1:139      0.0.0.0:0              ABHÖREN
  UDP    0.0.0.0:445            *:*
  UDP    0.0.0.0:500            *:*
  UDP    0.0.0.0:1031           *:*
  UDP    0.0.0.0:1035           *:*
  UDP    0.0.0.0:1200           *:*
  UDP    0.0.0.0:1866           *:*
  UDP    0.0.0.0:4500           *:*
  UDP    127.0.0.1:1881         *:*
  UDP    127.0.0.1:1889         *:*
  UDP    127.0.0.1:1900         *:*
  UDP    192.168.16.6:137       *:*
  UDP    192.168.16.6:138       *:*
  UDP    192.168.16.6:1880      *:*
  UDP    192.168.16.6:1888      *:*
  UDP    192.168.16.6:1900      *:*
  UDP    192.168.102.1:137      *:*
  UDP    192.168.102.1:138      *:*
  UDP    192.168.102.1:1877     *:*
  UDP    192.168.102.1:1885     *:*
  UDP    192.168.102.1:1900     *:*
  UDP    192.168.199.1:137      *:*
  UDP    192.168.199.1:138      *:*
  UDP    192.168.199.1:1878     *:*
  UDP    192.168.199.1:1886     *:*
  UDP    192.168.199.1:1900     *:*
  UDP    212.108.161.240:1879   *:*
  UDP    212.108.161.240:1887   *:*
  UDP    212.108.161.240:1900   *:*

und ein Route print:

Code:
===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 50 56 c0 00 08 ...... VMware Virtual Ethernet Adapter for VMnet8
0x3 ...00 50 56 c0 00 01 ...... VMware Virtual Ethernet Adapter for VMnet1
0x40006 ...00 ff 8d 6d 40 e4 ...... TAP-Win32 Adapter V8 - Paketplaner-Miniport
0xc0004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0        128.0.0.0     192.168.16.5    192.168.16.6       1
          0.0.0.0          0.0.0.0  212.108.161.240  212.108.161.240      1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
        128.0.0.0        128.0.0.0     192.168.16.5    192.168.16.6       1
     192.168.16.1  255.255.255.255     192.168.16.5    192.168.16.6       1
     192.168.16.4  255.255.255.252     192.168.16.6    192.168.16.6       30
     192.168.16.6  255.255.255.255        127.0.0.1       127.0.0.1       30
   192.168.16.255  255.255.255.255     192.168.16.6    192.168.16.6       30
     192.168.17.0  255.255.255.192     192.168.16.5    192.168.16.6       1
    192.168.17.64  255.255.255.192     192.168.16.5    192.168.16.6       1
   192.168.17.128  255.255.255.192     192.168.16.5    192.168.16.6       1
   192.168.17.224  255.255.255.224     192.168.16.5    192.168.16.6       1
    192.168.102.0    255.255.255.0    192.168.102.1   192.168.102.1       20
    192.168.102.1  255.255.255.255        127.0.0.1       127.0.0.1       20
  192.168.102.255  255.255.255.255    192.168.102.1   192.168.102.1       20
    192.168.199.0    255.255.255.0    192.168.199.1   192.168.199.1       20
    192.168.199.1  255.255.255.255        127.0.0.1       127.0.0.1       20
  192.168.199.255  255.255.255.255    192.168.199.1   192.168.199.1       20
    212.108.161.8  255.255.255.255  212.108.161.240  212.108.161.240      1
  212.108.161.240  255.255.255.255        127.0.0.1       127.0.0.1       50
  212.108.161.255  255.255.255.255  212.108.161.240  212.108.161.240      50
        224.0.0.0        240.0.0.0     192.168.16.6    192.168.16.6       30
        224.0.0.0        240.0.0.0    192.168.102.1   192.168.102.1       20
        224.0.0.0        240.0.0.0    192.168.199.1   192.168.199.1       20
        224.0.0.0        240.0.0.0  212.108.161.240  212.108.161.240      1
  255.255.255.255  255.255.255.255     192.168.16.6    192.168.16.6       1
  255.255.255.255  255.255.255.255    192.168.102.1   192.168.102.1       1
  255.255.255.255  255.255.255.255    192.168.199.1   192.168.199.1       1
  255.255.255.255  255.255.255.255  212.108.161.240  212.108.161.240      1
Standardgateway:      192.168.16.5
===========================================================================
Ständige Routen:
  Keine

der Client ist jetzt ein WinXP Home Rechner aber die Logs sehen auf WinXP Pro und W2K nicht anders aus...

... nebenbei haben wir noch beobachtet das die OpenVPN.exe beim I-Net Tunnel auf 100% CPU-Auslastung springt, nicht jedoch beim VPN Tunnel im LAN ...
 
Zuletzt bearbeitet:
Hmm. Die Ausgabe unter Win ist echt würgs und auch noch ohne weitere Infos über das Netz. Nun denn.
Ich sehe:

* Der Client geht wohl über 212.108.161.240 ins I-Net
* Der Tunnel bekommt vom DHCP Server 192.168.16.5 die IP 192.168.16.6/255.255.255.252

Soweit so schlecht.

Was ich nicht verstehe:
Der Client bekommt 192.168.16.6/255.255.255.252.
Aber warum setzt Du das Standard-Gateway auf 192.168.16.5?

Mittels route werden doch die Routen alle bekannt gemacht, Du bräuchtest also kein Standard-Gateway. So wird ja der gesamte I-Net Verkehr darüber geleitet, was so wohl nicht gewollt ist, oder?
 
doch genau so ist es gewollt, um bei der Verbindung mit dem Firmennetz evtl Angriffe aus dem I-Net auszuschliessen, gehen alle Anfragen, auch www, durch den Tunnel ins Firmennetz...

der VPN Server hat nen Proxy an den die www Anfragen direkt weitergeleitet werden, der VPN-Client soll somit keine andere Möglichkeit für den Netzwerkverkehr als durch den Tunnel bekommen

in der Theorie funzt das prima, der Rechner am Hub hat auch ne "öffentliche" IP und ist über einen Hub direkt mit der öffentlichen IP des VPN-Servers verbunden, vorher kein I-Net surfen, weil intern ja 192.168.xxx er Netze, aber dann, Dank VPN-Tunnel, Surfen und Mailversand usw... (hatte ich eingangs ja geschrieben...)

nochmal: der Tunnel scheint nicht das Problem zu sein, da er ja in der Testumgebung wunderbar funktioniert, wir haben jetzt permanent einen Rechner über LAN am VPN und einen über ISDN Einwahl am VPN, LAN-Tunnel funzt super und ISDN-Tunnel wird nur aufgebaut, aber es antwortet nicht mal der Server... :grumble: schon komisch
 
doch genau so ist es gewollt, um bei der Verbindung mit dem Firmennetz evtl Angriffe aus dem I-Net auszuschliessen, gehen alle Anfragen, auch www, durch den Tunnel ins Firmennetz...

Wie sollte so was gehen? :confused:
Du benötigst die I-Net Adresse für den OpenVPN Datenstrom (UDP Port 1194?). Gleichzeitig biegst Du alle TCP/IP Pakete durch den Tunnel.
Das so was im LAN geht ist doch klar, aber bei ISDN hast Du eine Punkt-zu-Punkt Verbindung ins Internet. Das ist ein unterschiedliches Szenario.

Mach doch mal ein traceroute (z.B. eine Intranet Adresse und eine Webseite wie Google) und sieh Dir an, wie die Pakete laufen.

Alternativ kannst Du ja mal das Standard-GW bei dem ISDN Rechner weglassen, und dann den OpenVPN Server anpingen.

Mach doch mal eine Zeichnung von dem LAN Szenario. Welche Netze, welche Adressen usw. Vielleicht wird dann was klar.
 
HURRA es funzt.....

wir hatten nur einen kleinen Fehler in der server.conf, ich hatte es oben gepostet:
Code:
push "redirect-gateway local def1"
mit dieser Option soll der VPN-Client das selbe Gateway wie beim VPN-Server übergeben bekommen (so hatten wir das damals für die Testumgebung im I-Net recherchiert...)
Code:
push "redirect-gateway"
so haben wir die Gateway Übergabe an den VPN-Client jetzt gelöst, Ergebnis:
Folgende Route:
Code:
        128.0.0.0        128.0.0.0     192.168.16.5    192.168.16.6       1
wird nicht gesetzt und der Tunnel funzt auch aus dem I-Net und alle Anfragen (auch www) gehen durch den Tunnel.

Danke für die Hilfe, gerade weil von Anfang an gesagt wurde das wir ein Routenproblem, und Alexco meinte das es am Gateway liegen könne, und wir so dort weiter gesucht haben.

Gruß Binfort

UND THEMA ERLEDIGT!!! :D
 
Eine weitere Frage noch...

Hallo

Nachdem mir das Forum bei der heutigen Aufgabe, openvpn mit routing zu installieren bisher sehr große dienste geleistet hat ich aber immer noch ein problem hab, versuch ich hier doch mal aktiv mein glück.

ich habe mit der Anleitung in dem Post alles eigentlich zum laufen gebracht will allerdings eines noch machen.

Vorerst mein Setup.

1 Server der auf WinXP läuft und openvpn mit server config aktiv hat
1 client der auch winXP hat und auf den Server via VPN zugreifen will.

Meine Server Config
port 1194
proto udp

dev tap


ca ca.crt
cert server1.crt
key server1.key

dh dh1024.pem
mode server

ifconfig 192.168.80.1 255.255.255.0
ifconfig-pool 192.168.80.11 192.168.80.20 255.255.255.0
push "route 192.168.80.0 255.255.255.0 192.168.80.1"
push "route xxx.xxx.249.246 255.255.255.248 192.168.80.1"
push "redirect-gateway"


tls-server
cipher AES-256-CBC
keepalive 10 120
comp-lzo

verb 3

meine Client Config

client
dev tap

remote xxx.xxx.xxx.xxx 1194 udp

ca ca.crt
cert client1.crt
key client1.key

redirect-gateway

cipher AES-256-CBC

comp-lzo
pull
verb 4

Die Verbindung klappt an und für sich und auch internet funktioniert weiterhin am client.. Der Server hängt direkt am ISP Modem mit fixen IP Einstellungen. Server selbst hat zum Internet die IP

xxx.xxx.249.243
Gateway vom ISP ist:
xxx.xxx.249.246


Mein Vorhaben ist allerdings, dass ich mit dem Client ins Internet muss mit der Server IP Adresse und das bekomme ich nicht hin.

Kann mir hier evtl. jemand einen Tipp geben was ich hier falsch mache!?

lg
Roland
 
Hallo,

hmm kann mir einer erklären was das mit BSD zu tun hat und warum das in einem BSDFORUM in der Rubrik FreeBSD Anwendungen gefragt wird ?!?

Danke.

Gruß Bummibaer
 
@Bummibaer
ich habe das Thema vor zweieinhalb Jahren eröffnet, warum nun gerade in dieser Rubrik kann ich beim besten Willen nicht mehr erklären... vllt weil ich DAMALS noch sehr sehr wenige Erfahrungen mit BSD hatte und mein Problemchen auf das Betriebssystem zurückführte... oder weil gerade Montag war und Montags wird nun mal bei bsdforen.de gespammt, ganz klare Regel...

Mir stellt sich die Frage warum Du zweieinhalb Jahre später erst nachfragst... schade ist nur das ich dem rfauster die Frage nicht beantworten kann, und ihm Deine Fragen auch nicht helfen...

ach verdammt heut ist Dienstag, falsches Forum.
 
Ich glaube das bezog sich dann doch eher auf die Frage zwei Etagen weiter oben: (WinXP Server, WinXP Client).... :huth:


Grüße!
 
Zurück
Oben