gelöst [54.04.67-3023] Openvpn Probleme

detlef · 5 Feb 2009

Hi,

versuche nun schon seit einigen Tagen OpenVPN auf der FBF7270
mit freetz zum Laufen zu bekommen.
Der Tunnel wird aufgebaut, Ping geht weder vom Server noch vom
Client, nicht einmal die Tunnelenden kann ich anpingen.
Vielleicht schaut mal jemand drüber, ich weiss nicht mehr weiter.

Server:

Code:

#  OpenVPN 2.1 Config, Thu Feb  5 15:50:56 CET 2009
proto udp
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
tls-auth /tmp/flash/static.key 0
port 1194
mode server
ifconfig-pool 192.168.200.100 192.168.200.105
push "route 192.168.200.1 "
ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
push "route 192.168.178.0 255.255.255.0"
max-clients 5
tun-mtu 1500
mssfix
verb 3
daemon
cipher BF-CBC
comp-lzo
float
keepalive 10 120
status /var/log/openvpn.log

ifconfig

Code:

adsl      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:2000  Metric:1
          RX packets:47671 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47508 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:19999730 (19.0 MiB)  TX bytes:8250333 (7.8 MiB)

ath0      Link encap:Ethernet  HWaddr 00:1F:3F:D2:94:38
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:2290  Metric:1
          RX packets:41905 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44403 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4832122 (4.6 MiB)  TX bytes:19181971 (18.2 MiB)

cpmac0    Link encap:Ethernet  HWaddr 00:1F:3F:E4:30:14
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:609 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3027 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:43782 (42.7 KiB)  TX bytes:640572 (625.5 KiB)

dsl       Link encap:Point-to-Point Protocol
          inet addr:169.254.2.1  P-t-P:169.254.2.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:11707 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10869 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:4705312 (4.4 MiB)  TX bytes:1704911 (1.6 MiB)

eth0      Link encap:Ethernet  HWaddr 00:1F:3F:E4:30:14
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:609 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3028 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:128
          RX bytes:43782 (42.7 KiB)  TX bytes:640638 (625.6 KiB)

lan       Link encap:Ethernet  HWaddr 00:1F:3F:E4:30:14
          inet addr:192.168.178.1  Bcast:192.168.178.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:42504 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30757 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4277038 (4.0 MiB)  TX bytes:12643098 (12.0 MiB)

lan:0     Link encap:Ethernet  HWaddr 00:1F:3F:E4:30:14
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2055 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2055 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:179886 (175.6 KiB)  TX bytes:179886 (175.6 KiB)

tap0      Link encap:Ethernet  HWaddr AA:FC:55:F5:2C:94
          inet addr:192.168.200.1  Bcast:192.168.200.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1739 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:477524 (466.3 KiB)

wifi0     Link encap:Ethernet  HWaddr 00:1F:3F:D2:94:38
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:48935 errors:0 dropped:0 overruns:0 frame:435
          TX packets:46957 errors:27 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:7045710 (6.7 MiB)  TX bytes:22106131 (21.0 MiB)
          Interrupt:80 Memory:c0220000-c0230000

netstat -rn

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.180.1   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH        0 0          0 dsl
84.138.6.136    0.0.0.0         255.255.255.255 UH        0 0          0 dsl
192.168.178.0   0.0.0.0         255.255.255.0   U         0 0          0 lan
192.168.200.0   0.0.0.0         255.255.255.0   U         0 0          0 tap0
192.168.10.0    192.168.178.20  255.255.255.0   UG        0 0          0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 dsl

Logdateien vom Server u. Client liefere ich nach, komme momentan nicht dran.

Evtl. ist es ja nen Bug...

Gruss
Detlef

cando · 5 Feb 2009

Kannst Du mal posten, wie genau Du Dir das vorgestellt hast und was Du von wo aus nicht pingen kanst?

Zunächst mal musst Du zwischen Internet IP Adressen und LAN IP Adressen unterscheiden.

Beide Boxen brauchen ein DynDNS oder so, damit die sich finden (der Tunnel muss ja über das reale Internet). Es müssen die Ports entsprechend aufgemacht werden, sonst verhindert die AVM Firewall / NAT dass der Tunnel zustande kommt.

Zwischen den Ports wird nun der Tunnel aufgebaut.

Dann brauchst Du auf jeder Seite ein LAN-Segment in unterschiedlichen IP Bereichen. (was Du schon hast)

Weiter hin benötigt jede Box eine virtuelles Interface für die Tunnelenden.

Dann muss in der Box eine statische Route eingetragen werden für das gegenüberliegende Segment auf das jeweilige lokale virtuelle Tunnelinterface.

Dann sollte es gehen.

b69 · 6 Feb 2009

Hallo Detlef,

kannst du mal die client conf posten?

Bitte denk an das Portforwarding z.B. via AVM-Firewall. Also sowas wie udp 0.0.0.0:1194 0.0.0.0:1194.
Und sei bitte auch sicher,dass OpenVPN auch läuft, ist gerne mal 'nen Fehler ;-)

Und als letztes kannst du auf den tls-static vorest verzichten? Den kann man ja später wieder hinzufügen.

Ich denke, du hast auch daran gedacht ein Server und ein client Zertifikat zu erstellen.

Viele Grüße
Leif

detlef · 6 Feb 2009

Guten morgen,

danke für Eure Antworten.

Also ich möchte vorerst ein ganz klassisches Roadwarrior-Zenario
einrichten, d.h. die FBF ist der Server, Clients sind Windows/ Linux
Arbeitsplätze.
Portforwarding 1194 auf 0.0.0.0 ist eingerichtet, openvpn läuft,
Client macht den Handshake und verbindet sich lt. Log auch auf die
Box.

Box-IP: 192.168.178.1
VPN-Interface: 192.168.200.1
DHCP-Pool VPN: 192.168.200.100 bis 192.168.200.105

client.ovpn:

Code:

#VPN Brücke
 
remote xyz.dyn-fli4l.de 
proto udp
dev tap
tls-client
ns-cert-type server
ca "c:\\programme\\OpenVPN\\ca.crt"
cert "c:\\programme\\OpenVPN\\client01.crt"
key "c:\\programme\\OpenVPN\\client01.key"
tls-auth "c:\\programme\\OpenVPN\\static.key" 1
tun-mtu 1500
mssfix
nobind
pull
verb 3

Log Verbindungsaufbau client:

Code:

Fri Feb 06 08:12:45 2009 OpenVPN 2.1_rc15 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Nov 19 2008
Fri Feb 06 08:12:45 2009 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Feb 06 08:12:45 2009 Control Channel Authentication: using 'c:\programme\OpenVPN\static.key' as a OpenVPN static key file
Fri Feb 06 08:12:45 2009 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 06 08:12:45 2009 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 06 08:12:45 2009 Control Channel MTU parms [ L:1573 D:166 EF:66 EB:0 ET:0 EL:0 ]
Fri Feb 06 08:12:45 2009 Data Channel MTU parms [ L:1573 D:1450 EF:41 EB:4 ET:32 EL:0 ]
Fri Feb 06 08:12:45 2009 Local Options hash (VER=V4): '1a647362'
Fri Feb 06 08:12:45 2009 Expected Remote Options hash (VER=V4): '47de3ccc'
Fri Feb 06 08:12:45 2009 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Feb 06 08:12:45 2009 UDPv4 link local: [undef]
Fri Feb 06 08:12:45 2009 UDPv4 link remote: 84.138.49.207:1194
Fri Feb 06 08:12:45 2009 TLS: Initial packet from 84.138.49.207:1194, sid=1e946cb4 09f3ae8e
Fri Feb 06 08:12:45 2009 VERIFY OK: depth=1, /C=DE/ST=Hessen/L=xxx/O=Detlef/CN=ca/[email protected]
Fri Feb 06 08:12:45 2009 VERIFY OK: nsCertType=SERVER
Fri Feb 06 08:12:45 2009 VERIFY OK: depth=0, /C=DE/ST=Hessen/O=Detlef/CN=fritzbox/[email protected]
Fri Feb 06 08:12:46 2009 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Feb 06 08:12:46 2009 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 06 08:12:46 2009 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Feb 06 08:12:46 2009 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 06 08:12:46 2009 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Feb 06 08:12:46 2009 [fritzbox] Peer Connection Initiated with 84.138.49.xxx:1194
Fri Feb 06 08:12:47 2009 SENT CONTROL [fritzbox]: 'PUSH_REQUEST' (status=1)
Fri Feb 06 08:12:47 2009 PUSH: Received control message: 'PUSH_REPLY,route 192.168.200.1 ,route-gateway 192.168.200.1,route 192.168.178.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 192.168.200.100 255.255.255.0'
Fri Feb 06 08:12:47 2009 OPTIONS IMPORT: timers and/or timeouts modified
Fri Feb 06 08:12:47 2009 OPTIONS IMPORT: --ifconfig/up options modified
Fri Feb 06 08:12:47 2009 OPTIONS IMPORT: route options modified
Fri Feb 06 08:12:47 2009 OPTIONS IMPORT: route-related options modified
Fri Feb 06 08:12:47 2009 ROUTE default_gateway=192.168.51.40
Fri Feb 06 08:12:47 2009 TAP-WIN32 device [LAN-Verbindung 3] opened: \\.\Global\{86A51736-D760-4DF9-91B6-5A14462AE64A}.tap
Fri Feb 06 08:12:47 2009 TAP-Win32 Driver Version 9.4 
Fri Feb 06 08:12:47 2009 TAP-Win32 MTU=1500
Fri Feb 06 08:12:47 2009 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.200.100/255.255.255.0 on interface {86A51736-D760-4DF9-91B6-5A14462AE64A} [DHCP-serv: 192.168.200.0, lease-time: 31536000]
Fri Feb 06 08:12:47 2009 Successful ARP Flush on interface [65540] {86A51736-D760-4DF9-91B6-5A14462AE64A}
Fri Feb 06 08:12:52 2009 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Fri Feb 06 08:12:52 2009 OpenVPN ROUTE: omitted no-op route: 192.168.200.1/255.255.255.255 -> 192.168.200.1
Fri Feb 06 08:12:52 2009 C:\WINDOWS\system32\route.exe ADD 192.168.178.0 MASK 255.255.255.0 192.168.200.1
Fri Feb 06 08:12:52 2009 Route addition via IPAPI succeeded [adaptive]
Fri Feb 06 08:12:52 2009 Initialization Sequence Completed

ipconfig client:

Code:

        Verbindungsspezifisches DNS-Suffix:
        Beschreibung. . . . . . . . . . . : Realtek RTL8169/8110 Family Gigab
Ethernet NIC
        Physikalische Adresse . . . . . . : 00-30-05-BE-90-3F
        DHCP aktiviert. . . . . . . . . . : Nein
        IP-Adresse. . . . . . . . . . . . : 192.168.51.147
        Subnetzmaske. . . . . . . . . . . : 255.255.255.0
        Standardgateway . . . . . . . . . : 192.168.51.40
        DNS-Server. . . . . . . . . . . . : 192.168.51.40

Ethernetadapter LAN-Verbindung 3:

        Verbindungsspezifisches DNS-Suffix:
        Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V9 #2
        Physikalische Adresse . . . . . . : 00-FF-86-A5-17-36
        DHCP aktiviert. . . . . . . . . . : Ja
        Autokonfiguration aktiviert . . . : Ja
        IP-Adresse. . . . . . . . . . . . : 192.168.200.100
        Subnetzmaske. . . . . . . . . . . : 255.255.255.0
        Standardgateway . . . . . . . . . :
        DHCP-Server . . . . . . . . . . . : 192.168.200.0
        Lease erhalten. . . . . . . . . . : Freitag, 6. Februar 2009 08:12:51
        Lease läuft ab. . . . . . . . . . : Samstag, 6. Februar 2010 08:12:51

route print client:

Code:

===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 30 05 be 90 3f ...... Realtek RTL8169/8110 Family Gigabit Ethernet NIC
 - Paketplaner-Miniport
0x10004 ...00 ff 86 a5 17 36 ...... TAP-Win32 Adapter V9 #2 - Paketplaner-Minipo
rt
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0    192.168.51.40  192.168.51.147       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     192.168.51.0    255.255.255.0   192.168.51.147  192.168.51.147       20
   192.168.51.147  255.255.255.255        127.0.0.1       127.0.0.1       20
   192.168.51.255  255.255.255.255   192.168.51.147  192.168.51.147       20
    192.168.178.0    255.255.255.0    192.168.200.1  192.168.200.100      1
    192.168.200.0    255.255.255.0  192.168.200.100  192.168.200.100      30
  192.168.200.100  255.255.255.255        127.0.0.1       127.0.0.1       30
  192.168.200.255  255.255.255.255  192.168.200.100  192.168.200.100      30
        224.0.0.0        240.0.0.0   192.168.51.147  192.168.51.147       20
        224.0.0.0        240.0.0.0  192.168.200.100  192.168.200.100      30
  255.255.255.255  255.255.255.255   192.168.51.147  192.168.51.147       1
  255.255.255.255  255.255.255.255  192.168.200.100  192.168.200.100      1
Standardgateway:     192.168.51.40
===========================================================================
Ständige Routen:
  Keine

Gruss
Detlef

MaxMuster · 6 Feb 2009

cando schrieb:
Das sieht doch schon mal fast gut aus.

Ja ;-)

cando schrieb:
es fehlt an der Route im Windows:

Nein ;-)

Die Route ist schon da:

Code:

    192.168.178.0    255.255.255.0    192.168.200.1  192.168.200.100      1
    192.168.200.0    255.255.255.0  192.168.200.100  192.168.200.100      30

Dein Problem dürfte eher das fehlende "comp-lzo" bei Client sein, vermute ich...

Jörg

detlef · 6 Feb 2009

cando schrieb:
Das sieht doch schon mal fast gut aus.

es fehlt an der Route im Windows:

Code:

route ADD 192.168.178.0 MASK 255.255.255.0 192.168.200.100 METRIC 0 IF 0x10004

Damit Dein Windows weiss, wie das entfernte Segment zu erreichen ist.

So wie es im Moment ist, schickt dein Routing die Pakete für 192.168.178.0/24 an die default Route 192.168.51.40 ins Internet .

Nee, eigentlich schickt er es an 192.168.200.1, der VPN-IP der Box.
Manuell die obige Route setzen bringt keine Besserung.

Code:

Hast Du auf der Box eine Route für 192.178.100.0/24 auf das Tunnel-Interface eingerichtet (kann sein dass die Box das auch alleine macht, schau dir mal die Routen an, die auf der Box eingetragen sind)

Nen manueller Eintrag wäre irgendwie sinnfrei, die Adressen werden ja per DHCP zugewiesen.

route auf box bei bestehender Verbindung:

Code:

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
84.138.49.207   *               255.255.255.255 UH    2      0        0 dsl
192.168.178.0   *               255.255.255.0   U     0      0        0 lan
192.168.200.0   *               255.255.255.0   U     0      0        0 tap0
192.168.10.0    192.168.178.20  255.255.255.0   UG    0      0        0 lan
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl

openvpn.log:

Code:

/var/mod/root # cat /var/log/openvpn.log
OpenVPN CLIENT LIST
Updated,Fri Feb  6 09:56:07 2009
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client01,84.138.170.143:2106,15471,14110,Fri Feb  6 09:54:25 2009
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
GLOBAL STATS
Max bcast/mcast queue length,1
END

Ich bin der Meinung, das beim Erstellen der Konfig auf der Box
durch das GUI irgendetwas schief läuft und die Routen nicht
richtig gesetzt werden.

Gruss
Detlef

detlef · 6 Feb 2009

@MaxMuster
Danke, hab ich schon gesehen. Problem besteht aber weiterhin.

Code:

remote xxx.dyn-fli4l.de 
proto udp
dev tap
tls-client
ns-cert-type server
ca "c:\\programme\\OpenVPN\\ca.crt"
cert "c:\\programme\\OpenVPN\\client01.crt"
key "c:\\programme\\OpenVPN\\client01.key"
tls-auth "c:\\programme\\OpenVPN\\static.key" 1
tun-mtu 1500
comp-lzo
mssfix
nobind
pull
verb 3

Ich muss aber händisch keine Routen an der Box setzen, oder?

Kann ich noch weitere Logs o. Einstellungen posten, die nützlich
wären?

Gruss
Detlef

MaxMuster · 6 Feb 2009

Nein, Routen per Hand sollten unnötig sein. Schade: das unterschiedliche "comp-lzo" hätte das genau erklärt: Verbindung wird aufgebaut, aber kein Traffic ist möglich.

Ist denn der Ping auf 192.168.200.1 jetzt möglich? Zählen jetzt RX und TX hoch?

Jörg

detlef · 6 Feb 2009

@Jörg
Bin momentan im AD, TX/RX schaue ich nach, wenn ich wieder
im Büro bin. Ping auf 200.1 geht nicht.

Frage:
Muss das tap/tun Interface wie im Wiki beschrieben in
die Bridgedinterfaces eingetragen werde? Hatte ich auch
schon gemacht, momentan aber den Eintrag draussen.

Müssen die Bridge-utils installiert sein?

Gruss
Detlef

detlef · 6 Feb 2009

Mit den bridge-utils war ne doofe Frage, sind installiert.

MaxMuster · 6 Feb 2009

So, wie du "tap" jetzt nutzt, wird das als "eigenständiges" Interface angesehen, so dass es ähnlich wie "tun" funktioniert.
Aber funktinieren sollte es eigentlich...

Jörg

colonia27 · 6 Feb 2009

Fehlt in der client.ovpn nicht eigentlich auch die Verschlüsselungsmethode? In deinem Fall cipher BF-CBC
Oder muß die da nicht rein?

MaxMuster · 6 Feb 2009

... ist nach meiner Erinnerung als "default" für cipher nicht unbedingt erforderlich.

Jörg

colonia27 · 6 Feb 2009

achso, dann hatte es damals bei mir wohl nur angemeckert, weil ich AES eingestellt hab.

detlef · 6 Feb 2009

Hi,

also das Tap-Device vom Client und auch der Server
schieben Daten hin und her:

Code:

tap0      Link encap:Ethernet  HWaddr 8E:B4:C1:74:91:8F
          inet addr:192.168.200.1  Bcast:192.168.200.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:15359 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16590 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:663334 (647.7 KiB)  TX bytes:1042628 (1018.1 KiB)

Ich schalte mal lzo aus.

Gruss
Detlef

MaxMuster · 6 Feb 2009

... Gibt es auf der Windowsbüchse eine Firewall, die da reinspucken könnte?
Ansonsten vielleicht auch erstmal ohne "tls-auth" probieren?
Siehst du bei "arp -a" eine "MAC-Adresse" für die jeweilige Gegenseite?

Jörg

detlef · 6 Feb 2009

Ohne LZO die gleichen Probleme. Mich stört das Verhalten des Clients.

Code:

C:\Dokumente und Einstellungen\User>tracert 192.168.178.1

Routenverfolgung zu 192.168.178.1 über maximal 30 Abschnitte

  1     *        *        *     Zeitüberschreitung der Anforderung.
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9     *        *        *     Zeitüberschreitung der Anforderung.
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12     *        *        *     Zeitüberschreitung der Anforderung.
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14     *        *        *     Zeitüberschreitung der Anforderung.
 15     *        *     ^C

Ich werd weich....

detlef · 6 Feb 2009

[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren. Lies noch mal die Forumregeln.]

MaxMuster schrieb:
... Gibt es auf der Windowsbüchse eine Firewall, die da reinspucken könnte?
Ansonsten vielleicht auch erstmal ohne "tls-auth" probieren?
Siehst du bei "arp -a" eine "MAC-Adresse" für die jeweilige Gegenseite?

Jörg

Nur Windows-Firewall u. die ist aus. Auch die zentrale Firewall in
meinem Lan ist aus.

Code:

Schnittstelle: 192.168.51.147 --- 0x2
  Internetadresse       Physikal. Adresse     Typ
  192.168.51.40         00-04-a7-04-7d-e9     dynamisch
  192.168.51.80         00-30-05-80-1f-06     dynamisch
  192.168.51.142        00-0c-29-95-78-82     dynamisch
  192.168.51.164        00-80-c8-48-19-4c     dynamisch

Schnittstelle: 192.168.200.100 --- 0x20004
  Internetadresse       Physikal. Adresse     Typ
  192.168.200.1         12-a6-c7-40-59-cb     dynamisch

C:\Dokumente und Einstellungen\User>

Code:

/var/mod/root # arp -a
? (192.168.200.100) at <incomplete>  on tap0
3002WTMi (192.168.178.23) at 00:12:F0:C1:9E:DF [ether]  on lan
? (192.168.178.20) at 00:40:F4:B8:C4:38 [ether]  on lan

incomplete??
Schalte jetzt TLS aus.

[Beitrag 2:]
Ohne TLS auch nicht

MaxMuster · 6 Feb 2009

Stimmt denn wenigstens die MAC, die der PC sieht, mit der vom tap0 auf der Box überein?

detlef · 6 Feb 2009

ja

Code:

tap0      Link encap:Ethernet  HWaddr CA:3E:C4:94:37:36
          inet addr:192.168.200.1  Bcast:192.168.200.255  Mask:255.255.255.0

Code:

Schnittstelle: 192.168.200.100 --- 0x30004
  Internetadresse       Physikal. Adresse     Typ
  192.168.200.1         ca-3e-c4-94-37-36     dynamisch

*gelöst* [54.04.67-3023] Openvpn Probleme

Neuer User

Aktives Mitglied

Neuer User

Neuer User

IPPF-Promi

Neuer User

Neuer User

IPPF-Promi

Neuer User

Neuer User

IPPF-Promi

colonia27

Guest

IPPF-Promi

colonia27

Guest

Neuer User

IPPF-Promi

Neuer User

Neuer User

IPPF-Promi

Neuer User

Statistik des Forums

gelöst [54.04.67-3023] Openvpn Probleme