[gelöst] Suse 11.2 VPN einrichten

$cruffy · 7 Juni 2010

Ich habe jetzt einen Teilerfolg, ich konnte den TCP Port öffnen. Schon komisch, denn gleichzeitig öffnete ich auch den UDP Port für die interne und externe Zonen, doch dieser bleibt zu. Kann es sein das die FW manchmal die Ports nicht öffnet?

Ich bin nun verbunden und meine Freigabe auf dem Samba Server lautet "scruffy_daten". Im LAN kann ich sie erreichen.

Wie mache ich das jetzt mittels VPN von einem XP Pro Rechner aus?

$cruffy · 7 Juni 2010

Ich habe jetzt mit den Windows XP "Assistent zum Hinzufügen von Netzwerkressourcen" versucht die Freigabe "scruffy_daten" einzuhängen.

Code:

\\10.8.0.1\filesdump

auch als Netzlaufwerk - auf die gleiche Art - zu verbinden.
Leider ohne Erfolg.

drboe · 7 Juni 2010

$cruffy schrieb:
Ich habe jetzt einen Teilerfolg, ich konnte den TCP Port öffnen. Schon komisch, denn gleichzeitig öffnete ich auch den UDP Port für die interne und externe Zonen, doch dieser bleibt zu. Kann es sein das die FW manchmal die Ports nicht öffnet?

Ich bin nun verbunden und meine Freigabe auf dem Samba Server lautet "scruffy_daten". Im LAN kann ich sie erreichen.

Hast Du Server und Client auf UDP bzw. TCP umgestellt? Die von Dir genannten Konfigurationen von Server und Client waren nämlich inkompatibel ('proto udp' vs. 'proto tcp'). Siehe mein Post http://www.linux-club.de/viewtopic.php?f=15&t=109683#p681882 Ohne die Anpasssung auf einheitlich UDP oder einheitlich TCP wird das VPN nicht etabliert; das habe ich hier schon geprüft.

$cruffy schrieb:
Wie mache ich das jetzt mittels VPN von einem XP Pro Rechner aus?

Wie ich schon schrieb: wenn die VPN-Verbindung steht, ist der Server durch den Tunnel wie im LAN erreichbar, ggf. unter Nutzung der IP des Servers. Wenn der Server im VPN die IP-Adresse 10.8.0.1 hat und Du scruffy_daten dem Laufwerk X: zuordnen willst, so lautet der Befehl in der Shell:

net use X: \\10.8.0.1\scruffy_daten /USER:scruffy passwort_von_scruffy

Dies lässt sich auch im Windows Explorer unter Extras > Netzlaufwerk verbinden einrichten. Dabei wird unter "Ordner" eingegeben: \\10.8.0.1\scruffy_daten Unter "anderem Benutzernamen" kann man den zu verwendenden User konfigurieren.

Ohne "net use" kann man auch im Windows im Explorer unter Adresse eingeben: \\10.8.0.1\scruffy_daten

M. Boettcher

$cruffy · 7 Juni 2010

Ja, ich habe das mit "proto tcp" jetzt auf beiden - im Server und beim client. Der Tunnel wird ja auch aufgebaut, der openVPN Icon ist jetzt grün.

Allerdings wenn ich

Code:

\\10.8.0.1\scruffy_daten

oder

Code:

net use v: \\10.8.0.1\scruffy_daten /USER:scruffy passwort_von_scruffy

eingebe, dann kommt beim ersten "Datei nicht gefunden, überprüfen Sie die Schreibweise etc. bla bla" und beim 2-ten "Systemfehler 67 der Netzwerkname wurde nicht gefunden".

Kurz gesagt: Tunnel steht, Verbindung zu der Freigabe aber nicht.

Edit
Beim herstellen der VPN Verbindung auf dem client, fiel mir auf, daß ich nicht nach Loginnamen oder pw gefragt wurde. Die Verbindung wurde einfach so hergestellt. Ich weiß nicht ob und in wie fern das hier relevant ist.

drboe · 7 Juni 2010

$cruffy schrieb:
Beim herstellen der VPN Verbindung auf dem client, fiel mir auf, daß ich nicht nach Loginnamen oder pw gefragt wurde. Die Verbindung wurde einfach so hergestellt. Ich weiß nicht ob und in wie fern das hier relevant ist.

Wenn Du mit den selbst erstellten Zertifikaten (ca.crt, client.crt, client.key) arbeitest, ist das OK.

Kannst Du durch den Tunnel den Server pingen? Oder eine SSH-Verbindung (putty) mit der VPN-Adresse (vermutl. 10.8.0.1) herstellen? Wenn ja, wäre zunächst geklärt, ob du durch den Tunnel an den Server kommst.

M. Boettcher

$cruffy · 7 Juni 2010

Ja, ich kann vom XP Rechner die 10.8.0.1 pingen.

Dateien Server:

Code:

:~ # ls -li /etc/openvpn/easy-rsa/2.0/keys/
total 68
142289 -rw-r--r-- 1 root root 4016 May 30 22:48 01.pem
142296 -rw-r--r-- 1 root root 3906 May 30 22:50 02.pem
133439 -rw-r--r-- 1 root root 1318 May 30 22:35 ca.crt
142281 -rw------- 1 root root  887 May 30 22:35 ca.key
142280 -rw-r--r-- 1 root root  245 May 30 23:17 dh1024.pem
142294 -rw-r--r-- 1 root root  248 May 30 22:50 index.txt
142295 -rw-r--r-- 1 root root   21 May 30 22:50 index.txt.attr
142288 -rw-r--r-- 1 root root   21 May 30 22:48 index.txt.attr.old
142287 -rw-r--r-- 1 root root  122 May 30 22:48 index.txt.old
142285 -rw-r--r-- 1 root root 4016 May 30 22:48 scruffyserver.crt
142284 -rw-r--r-- 1 root root  781 May 30 22:48 scruffyserver.csr
142283 -rw------- 1 root root  887 May 30 22:48 scruffyserver.key
142293 -rw-r--r-- 1 root root    3 May 30 22:50 serial
142286 -rw-r--r-- 1 root root    3 May 30 22:48 serial.old
142292 -rw-r--r-- 1 root root 3906 May 30 22:50 vpnhost1.crt
142291 -rw-r--r-- 1 root root  790 May 30 22:50 vpnhost1.csr
142290 -rw------- 1 root root  887 May 30 22:50 vpnhost1.key

WinXP Client Dateien:

Code:

dir c:\Programme\OpenVPN\keys\
ca.crt
ca.key
vpnhost1.crt
vpnhost1.csr
vpnhost1.key

Da war ich mir auch nicht ganz grün - sollte ich etwa alles rüberkopieren?

spoensche · 8 Juni 2010

$cruffy schrieb:
Da war ich mir auch nicht ganz grün - sollte ich etwa alles rüberkopieren?

Nö, du hast doch Zugriff auf den VPN Server. Die Dateifreigabe kannst du per Samba realisieren. Denn hast du installiert und er wartet auf der IP des VPN auf Anfragen oder? Sind die Rechner in der selben Arbeitsgruppe?

$cruffy · 8 Juni 2010

Hmm... Installiert und funktionsfähig über das LAN ist samba schon. Aber auf das Netzwerk 10.8.0.0 horcht er nicht. Doch ist das nicht der Job des VPN Servers; die Verbindung weiterzuleiten an die IP des Samba Servers 192.168.40.100 ?

Meine smb.conf:

Code:

[global]
        workgroup = scruffyland
        netbios name = scruffys
        wins support = no
        passdb backend = tdbsam
        security = domain
        map to guest = Bad User
        logon path = \\%L\profiles\.msprofile
        logon home = \\%L\%U\.9xprofile
        logon drive = S:
        usershare allow guests = No
        hosts allow = 192.168.40.0/24 10.8.0.0/24
        interfaces = 192.168.40.100 10.8.0.1
[scruffy_data]
        comment = scruffys dateien
        username = scruffy
        invalid users = root
        path = /home/scruffy/daten
        available = Yes
        browseable = Yes
        read only = No
        inherit acls = Yes
        create mask = 0777
        directory mask = 0777

Wie gesagt - im LAN geht alles wunderbar. Sollte ich vielleicht in iptables die samba Ports für die externe Zone zulassen?

drboe · 8 Juni 2010

$cruffy schrieb:
Wie gesagt - im LAN geht alles wunderbar. Sollte ich vielleicht in iptables die samba Ports für die externe Zone zulassen?

Da ist es m. E. bequemer die FW während des Tests abzuschalten.

M. Boettcher

$cruffy · 8 Juni 2010

Wenn ich die FW doch ganz abschalte, dann geht garnichts.

Was kann das denn sein? Meine Einstellungen scheinen doch vollkommen i.O. zu sein. Zuerst das mit den UDP Port, der sich nicht öffnen ließ, jetzt das hier. Ich verstehe das nicht. Die Sache ist jetzt doch schon - dank Eurer Hilfe - zu 95% erledigt.

$cruffy · 8 Juni 2010

Ok, danke drboe - es ist 100% die Firewall. Ich dachte immer, das wenn man die bei Linux ausschaltet, dann geht garnix mehr. Das war offenbar ein irrtum. Ich habe sie also angehalten und die Freigabe ging sofort.

spoensche · 8 Juni 2010

$cruffy schrieb:
Wenn ich die FW doch ganz abschalte, dann geht garnichts.

Das ist auch gut so.

$cruffy schrieb:
Was kann das denn sein? Meine Einstellungen scheinen doch vollkommen i.O. zu sein. Zuerst das mit den UDP Port, der sich nicht öffnen ließ, jetzt das hier.

Das mit dem UDP- Port warst du selbst, schließlich hast du dem VPN- Server gesagt er soll TCP verwenden.

$cruffy schrieb:
Ich verstehe das nicht. Die Sache ist jetzt doch schon - dank Eurer Hilfe - zu 95% erledigt.

Dann poste doch mal die Logfiles, damit man den Fehler finden und es dir erklären kann.

$cruffy schrieb:
Ok, danke drboe - es ist 100% die Firewall. Ich dachte immer, das wenn man die bei Linux ausschaltet, dann geht garnix mehr. Das war offenbar ein irrtum. Ich habe sie also angehalten und die Freigabe ging sofort.

Und da du ja einen sicheren Server an das Internet hängen möchtest, machst du die Firewall ganz schnell wieder an und öffnest die Ports 137-139 sowohl für TCP und UDP.

$cruffy · 9 Juni 2010

Ich habe die smb Ports 137-139 TCP/UDP nun auch für die ext. Zone geöffnet - keine Veränderung. Ich kann immer noch die Freigabe nicht erreichen.

Ich weiß nicht welche Logs du noch meinst, ich habe bereits einige gepostet

Hier die Logs aus /var/log/messages:

Code:

linux:~ # cat /var/log/messages | tail -80
Jun  9 05:55:11 localhost xinetd[2078]: Unknown group: svn [file=/etc/xinetd.d/svnserve] [line=9]
Jun  9 05:55:11 localhost xinetd[2078]: Error parsing attribute group - DISABLING SERVICE [file=/etc/xinetd.d/svnserve] [line=9]
Jun  9 05:55:11 localhost xinetd[2078]: Reading included configuration file: /etc/xinetd.d/swat [file=/etc/xinetd.d/swat] [line=12]
Jun  9 05:55:11 localhost xinetd[2078]: Reading included configuration file: /etc/xinetd.d/systat [file=/etc/xinetd.d/systat] [line=11]
Jun  9 05:55:11 localhost xinetd[2078]: Reading included configuration file: /etc/xinetd.d/tftp [file=/etc/xinetd.d/tftp] [line=15]
Jun  9 05:55:11 localhost xinetd[2078]: Reading included configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=14]
Jun  9 05:55:11 localhost xinetd[2078]: Reading included configuration file: /etc/xinetd.d/time-udp [file=/etc/xinetd.d/time-udp] [line=13]
Jun  9 05:55:11 localhost xinetd[2078]: removing svn
Jun  9 05:55:11 localhost xinetd[2078]: Service chargen will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Service chargen will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Service daytime will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Service daytime will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Service discard will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Service discard will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Service echo will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Service echo will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Port not specified and can't find service: netstat with getservbyname
Jun  9 05:55:11 localhost xinetd[2078]: No such internal service: servers/stream - DISABLING
Jun  9 05:55:11 localhost xinetd[2078]: No such internal service: services/stream - DISABLING
Jun  9 05:55:11 localhost xinetd[2078]: Service tftp will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Service time will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: Service time will use IPv6 or fallback to IPv4
Jun  9 05:55:11 localhost xinetd[2078]: xinetd Version 2.3.14 started with libwrap loadavg options compiled in.
Jun  9 05:55:11 localhost xinetd[2078]: Started working: 16 available services
Jun  9 05:55:11 localhost smbd[2331]: [2010/06/09 05:55:11,  0] smbd/server.c:457(smbd_open_one_socket)
Jun  9 05:55:11 localhost smbd[2331]:   smbd_open_once_socket: open_socket_in: Die Adresse wird bereits verwendet
Jun  9 05:55:11 localhost smbd[2331]: [2010/06/09 05:55:11,  0] smbd/server.c:457(smbd_open_one_socket)
Jun  9 05:55:11 localhost smbd[2331]:   smbd_open_once_socket: open_socket_in: Die Adresse wird bereits verwendet
Jun  9 05:55:12 localhost SuSEfirewall2: /var/lock/SuSEfirewall2.booting exists which means system boot in progress, exit.
Jun  9 05:55:12 localhost ifplugd(eth0)[1501]: Program executed successfully.
Jun  9 05:55:12 localhost ntpd[2515]: ntpd 4.2.4p8@1.1612-o Tue Dec 15 13:58:20 UTC 2009 (1)
Jun  9 05:55:12 localhost ntpd[2516]: precision = 1.000 usec
Jun  9 05:55:12 localhost ntpd[2516]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Jun  9 05:55:12 localhost ntpd[2516]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Jun  9 05:55:12 localhost ntpd[2516]: Listening on interface #1 wildcard, ::#123 Disabled
Jun  9 05:55:12 localhost ntpd[2516]: Listening on interface #2 lo, ::1#123 Enabled
Jun  9 05:55:12 localhost ntpd[2516]: Listening on interface #3 eth0, fe80::21f:d0ff:fe36:4f43#123 Enabled
Jun  9 05:55:12 localhost ntpd[2516]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
Jun  9 05:55:12 localhost ntpd[2516]: Listening on interface #5 lo, 127.0.0.2#123 Enabled
Jun  9 05:55:12 localhost ntpd[2516]: Listening on interface #6 eth0, 192.168.40.22#123 Enabled
Jun  9 05:55:12 localhost ntpd[2516]: kernel time sync status 2040
Jun  9 05:55:12 localhost ntpd[2516]: frequency initialized 3.044 PPM from /var/lib/ntp/drift/ntp.drift
Jun  9 05:55:13 localhost /usr/sbin/cron[2531]: (CRON) STARTUP (V5.0)
Jun  9 05:55:13 localhost SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
Jun  9 05:55:13 localhost SuSEfirewall2: Warning: no default firewall zone defined, assuming 'ext'
Jun  9 05:55:13 localhost SuSEfirewall2: batch committing...
Jun  9 05:55:13 localhost SuSEfirewall2: Firewall rules successfully set
Jun  9 05:59:11 localhost worker_nscd: gethostby*.getanswer: asked for "", got "."
Jun  9 05:59:11 localhost worker_nscd: gethostby*.getanswer: asked for "", got "."
Jun  9 05:59:11 localhost worker_nscd: gethostby*.getanswer: asked for "", got "."
Jun  9 05:59:11 localhost worker_nscd: gethostby*.getanswer: asked for "", got "."
Jun  9 05:59:11 localhost sshd[2721]: reverse mapping checking getaddrinfo for . [192.168.40.15] failed - POSSIBLE BREAK-IN ATTEMPT!
Jun  9 05:59:16 localhost sshd[2721]: Accepted keyboard-interactive/pam for root from 192.168.40.15 port 1935 ssh2
Jun  9 06:02:49 localhost SuSEfirewall2: batch committing...
Jun  9 06:02:49 localhost SuSEfirewall2: Firewall rules unloaded.
Jun  9 06:02:49 localhost SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
Jun  9 06:02:49 localhost SuSEfirewall2: Warning: no default firewall zone defined, assuming 'ext'
Jun  9 06:02:50 localhost SuSEfirewall2: batch committing...
Jun  9 06:02:50 localhost SuSEfirewall2: Firewall rules successfully set
Jun  9 06:02:58 localhost SuSEfirewall2: batch committing...
Jun  9 06:02:58 localhost SuSEfirewall2: Firewall rules unloaded.
Jun  9 06:02:58 localhost SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
Jun  9 06:02:58 localhost SuSEfirewall2: Warning: no default firewall zone defined, assuming 'ext'
Jun  9 06:02:59 localhost SuSEfirewall2: batch committing...
Jun  9 06:02:59 localhost SuSEfirewall2: Firewall rules successfully set
Jun  9 06:03:02 localhost SuSEfirewall2: batch committing...
Jun  9 06:03:02 localhost SuSEfirewall2: Firewall rules unloaded.
Jun  9 06:03:02 localhost SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
Jun  9 06:03:02 localhost SuSEfirewall2: Warning: no default firewall zone defined, assuming 'ext'
Jun  9 06:03:03 localhost SuSEfirewall2: batch committing...
Jun  9 06:03:03 localhost SuSEfirewall2: Firewall rules successfully set
Jun  9 06:03:13 localhost kernel: [  502.319956] tun: Universal TUN/TAP device driver, 1.6
Jun  9 06:03:13 localhost kernel: [  502.319984] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Jun  9 06:03:13 localhost kernel: [  502.324724] tun0: Disabled Privacy Extensions
Jun  9 06:04:09 localhost worker_nscd: gethostby*.getanswer: asked for "", got "."
Jun  9 06:04:09 localhost worker_nscd: gethostby*.getanswer: asked for "", got "."
Jun  9 06:04:09 localhost worker_nscd: gethostby*.getanswer: asked for "", got "."
Jun  9 06:04:09 localhost worker_nscd: gethostby*.getanswer: asked for "", got "."
Jun  9 06:04:09 localhost sshd[3738]: reverse mapping checking getaddrinfo for . [192.168.40.15] failed - POSSIBLE BREAK-IN ATTEMPT!
Jun  9 06:04:17 localhost sshd[3738]: Accepted keyboard-interactive/pam for root from 192.168.40.15 port 2122 ssh2

Wenn durch die falsche Eingabe in der server/client config das mit UDP verursacht wurde, dann müsste doch zumindest auf dem Server die Ausgabe:

Code:

linux:~ # nmap -sU -p 1194 192.168.40.100

Starting Nmap 5.00 ( http://nmap.org ) at 2010-06-06 21:41 CEST
Interesting ports on  (192.168.40.100):
PORT     STATE  SERVICE
1194/udp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 0.29 seconds

anders laufen - denke ich. Denn - wenn ich das richtig verstehe - sperrt/öffnet die openvpn config doch diese Ports nur für openvpn und würde daher nicht erfasst von nmap.

drboe · 9 Juni 2010

$cruffy schrieb:
Code:

Starting Nmap 5.00 ( http://nmap.org ) at 2010-06-06 21:41 CEST Interesting ports on (192.168.40.100): PORT STATE SERVICE 1194/udp closed unknown Nmap done: 1 IP address (1 host up) scanned in 0.29 seconds

anders laufen - denke ich. Denn - wenn ich das richtig verstehe - sperrt/öffnet die openvpn config doch diese Ports nur für openvpn und würde daher nicht erfasst von nmap.

Wenn der Port dicht ist, kann auch der Service, der diesen Port bedient, von außen nicht erreicht werden. Bei mir ergibt der Scan:

Code:

PORT     STATE         SERVICE
1194/udp open|filtered unknown

M. Boettcher

$cruffy · 9 Juni 2010

Und nu ? Was soll ich tun ? Ich kann auch beide protokolle bei openvpn öffnen - proto tcp und proto udp - aber dann wird kein VPN Tunnel eingerichtet. Also nur eines von beiden geht.

Ich habe die Freigabe unter "Security & User", "Firewall" und "Custom Rules" (siehe screen) und dort unter "external" eingerichtet - hab die Einstellung für UDP auch mehrfach gelöscht, neu eingerichtet und die FW neugestartet. Ich habe sogar nach dem Löschen und vor den neu einrichten den Server neugestartet - alles ohne Erfolg.

screen: http://openideas.info/wiki/images/f/fc/Yast_firewall2.png

Ein anderer Dienst der diesen Port bedient ist mir nicht bekannt und ausser NTP, Samba und VPN habe ich keine Dienste eingerichtet.

Ich bin echt am Ende Leute.

josef-wien · 9 Juni 2010

Du schreibst, daß es bei deaktivierter Firewall funktioniert. Also stelle die Firewall so ein, daß alle nicht akzeptierten Pakete protokolliert werden, dann solltest Du in /var/log/firewall erkennen können, woran es liegt.

framp · 9 Juni 2010

josef-wien schrieb:
... stelle die Firewall so ein, daß alle nicht akzeptierten Pakete protokolliert werden, ...

Code:

FW_LOG_DROP_ALL="yes"

in /etc/sysconfig/SuSEfirewall2 :roll:

$cruffy · 10 Juni 2010

Ok, ich habe die Einstellung vorgenommen und das hier ist /var/log/firewall

Code:

linux:~ # cat /var/log/firewall | tail -20
Jun 10 06:21:34 localhost kernel: [  430.057944] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=8288 DF PROTO=TCP SPT=1741 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 06:21:37 localhost kernel: [  432.930003] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=8303 DF PROTO=TCP SPT=1741 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 06:21:43 localhost kernel: [  438.944677] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=8373 DF PROTO=TCP SPT=1741 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 06:21:55 localhost kernel: [  450.984109] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=8450 DF PROTO=TCP SPT=1751 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 06:21:58 localhost kernel: [  453.927132] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=8478 DF PROTO=TCP SPT=1751 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 06:22:04 localhost kernel: [  459.941223] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=8508 DF PROTO=TCP SPT=1751 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 06:22:16 localhost kernel: [  472.011719] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=8580 DF PROTO=TCP SPT=1761 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:10:27 localhost kernel: [ 3363.455300] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38730 DF PROTO=TCP SPT=3345 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:10:27 localhost kernel: [ 3363.455868] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38732 DF PROTO=TCP SPT=3346 DPT=139 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:10:30 localhost kernel: [ 3366.413156] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38784 DF PROTO=TCP SPT=3345 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:10:30 localhost kernel: [ 3366.413804] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38785 DF PROTO=TCP SPT=3346 DPT=139 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:10:36 localhost kernel: [ 3372.428954] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38823 DF PROTO=TCP SPT=3345 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:10:48 localhost kernel: [ 3384.353636] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38929 DF PROTO=TCP SPT=3362 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:11:09 localhost kernel: [ 3405.475739] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=39159 DF PROTO=TCP SPT=3378 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)

Wie du allerdings siehst es steht nirgendwo auch nur einmal "PORTO=UDP" sondern überall "PROTO=TCP".

spoensche · 10 Juni 2010

$cruffy schrieb:

Code:

Jun 10 07:10:27 localhost kernel: [ 3363.455868] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38732 DF PROTO=TCP SPT=3346 DPT=139 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:10:30 localhost kernel: [ 3366.413156] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38784 DF PROTO=TCP SPT=3345 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:10:30 localhost kernel: [ 3366.413804] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38785 DF PROTO=TCP SPT=3346 DPT=139 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)
Jun 10 07:10:36 localhost kernel: [ 3372.428954] SFW2-INext-DROP-DEFLT IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38823 DF PROTO=TCP SPT=3345 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (0204055601010402)

Also Port 139 (netbios-ssn) hast du für tun0 schon mal nicht freigegeben, der aber für Dateifreigaben benötigt wird, der sowohl mit TCP als auch mit UDP arbeitet. Port 445 ist microsoft-ds (datasharing) was für CIFS benötigt wird und du auch freigeben musst.

$cruffy · 12 Juni 2010

Jau, danke. Jetzt geht es. Allerdings habe ich nur den Port 139 TCP geöffnet - alle anderen Ports - 137,138,139 UDP und 445 sind weiterhin zu. Ich habe auch im LAN den 445 Port TCP/UDP zu. Wenn der auf sein soll, dann muss er eine Sonderaufgabe haben. Vor allem war aber der Dienst samba-server selbst nicht für die ext. Zone erlaubt.

Aber der 1194 UDP ist weiterhin geschlossen obwohl die Regel das Öffnen befehlt - damit scheint das nichts zu tun zu haben.

[gelöst] Suse 11.2 VPN einrichten

Moderator