Securepoint Support Forum

Ich habe den BD soweit konfiguriert das eine VPN-Verbindung hergestellt werden kann.

Im Client sieht das so aus:

Tue Jan 03 15:55:46 2012 Initialization Sequence Completed
Tue Jan 03 15:55:43 2012 SENT CONTROL [server_cert]: 'PUSH_REQUEST' (status=1)
Tue Jan 03 15:55:43 2012 PUSH: Received control message: 'PUSH_REPLY,route 10.100.71.0 255.255.255.0,dhcp-option DNS 10.100.71.1,route 192.168.250.1,topology net30,ping 10,ping-restart 120,ifconfig 192.168.250.6 192.168.250.5'

Auf der Seite des BD wird bei SSL-VPN-Benutzer wie folgt ausgegeben:

Benutzername IP 10.100.70.5 Tunnel IP 192.168.250.6

Die IP 10.100.70.5 gehört allerdings zum externen Interface.
Das interne Interface hört auf 10.100.71.1
Im 71er Netzwerk liegt ein Linux Samba-Server der für den Client so nicht sichtbar ist.

VPN User haben im Portfilter auf das Objekt Samba derzeit ein any und auf das Internal Network ein dns.

Samba hat als Objekt die ip 10.100.71.253 255.255.255.255/32 Zone internal
und NAT-IP ist aus.

Wie kann ich den Samba Server für die SSL User bekannt machen ?
Intern klappt es.

Gruß Micha

Die Firewall blockt Port 137 und 138 an eth0.
Das sollte aber eigentlich wegen des Tunnels doch gar nicht passieren ?

Da bin ich jetzt ein bischen ratlos.

Die Firewall blockt den Traffic vmtl nicht aufgrund der Ports, sondern weil es Broadcasts sind und diese nicht geroutet werden (können).

Versuchen Sie vom Client aus direkt auf das Samba-Share zuzugreifen (\\\\server.ip\\share) oder wollen Sie, dass der Client die verfügbaren Freigaben automagisch findet?
Letzteres wird aus oben genannten Grund nicht funktionieren, da die Suche über Broadcasts läuft.

Danke für den Hinweis, allerdings klappt das nicht.

Die Log sagt nach dem Verbindungsaufbau :

Jan 5 12:55:30 kernel: DROP(default) IN=tun0 OUT=eth1 MAC= SRC=192.168.250.6 DST=10.100.71.254 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=55738 PROTO=ICMP TYPE=8 CODE=0 ID=1536 SEQ=9216 MARK=0x1
Jan 5 12:55:10 kernel: DROP(default) IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:1c:6f:65:c2:e2:9c:08:00 SRC=10.100.70.5 DST=10.100.70.255 LEN=202 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=182
Jan 5 12:55:09 kernel: DROP(default) IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:1c:6f:65:c2:e2:9c:08:00 SRC=10.100.70.5 DST=10.100.70.255 LEN=196 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=176
Jan 5 12:54:26 kernel: DROP(default) IN=tun0 OUT=eth1 MAC= SRC=192.168.250.6 DST=10.100.71.253 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=55142 PROTO=ICMP TYPE=8 CODE=0 ID=1536 SEQ=7936 MARK=0x1
Jan 5 12:54:13 openvpn[2211]: user/88.xxx.xx.xx:50049 SENT CONTROL [user]: 'PUSH_REPLY,route 10.100.71.0 255.255.255.0,dhcp-option DNS 10.100.71.1,dhcp-option DNS 10.100.70.1,route 192.168.250.1,topology net30,ping 10,ping-restart 120,ifconfig 192.168.250.6 192.168.250.5' (status=1)
Jan 5 12:54:13 openvpn[2211]: user/88.xxx.xx.xx:50049 PUSH: Received control message: 'PUSH_REQUEST'
Jan 5 12:54:11 openvpn[2211]: user/88.xxx.xx.xx:50049 MULTI: primary virtual IP for user/88.xxx.xx.xx:50049: 192.168.250.6
Jan 5 12:54:11 openvpn[2211]: user/88.xxx.xx.xx:50049 MULTI: Learn: 192.168.250.6 -> user/88.xxx.xx.xx:50049
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 [user] Peer Connection Initiated with 88.xxx.xx.xx:50049
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 TLS: Username/Password authentication succeeded for username 'user' [CN SET]
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 PLUGIN_CALL: POST /lib/openvpn-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 VERIFY OK: depth=0, /C=DE/ST=nrw/L=bonn/O=jll/OU=zentrale/CN=user/emailAddress=info@2by4-computer.de
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 CRL CHECK OK: /C=DE/ST=nrw/L=bonn/O=jll/OU=zentrale/CN=user/emailAddress=info@2by4-computer.de
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 VERIFY OK: depth=1, /C=DE/ST=nrw/L=bonn/O=jll/OU=zentrale/CN=CA-JLL/emailAddress=info@2by4-computer.de
Jan 5 12:54:11 openvpn[2211]: 88.xxx.xx.xx:50049 CRL CHECK OK: /C=DE/ST=nrw/L=bonn/O=jll/OU=zentrale/CN=CA-JLL/emailAddress=info@2by4-computer.de
Jan 5 12:54:10 openvpn[2211]: 88.xxx.xx.xx:50049 TLS: Initial packet from 88.xxx.xx.xx:50049, sid=a9ee0a81 bf242c9d
Jan 5 12:54:10 openvpn[2211]: 88.xxx.xx.xx:50049 Expected Remote Options hash (VER=V4): '3514370b'
Jan 5 12:54:10 openvpn[2211]: 88.xxx.xx.xx:50049 Local Options hash (VER=V4): '239669a8'
Jan 5 12:54:10 openvpn[2211]: 88.xxx.xx.xx:50049 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Jan 5 12:54:10 openvpn[2211]: 88.xxx.xx.xx:50049 Control Channel MTU parms [ L:1541 D:138 EF:38 EB:0 ET:0 EL:0 ]
Jan 5 12:54:10 openvpn[2211]: 88.xxx.xx.xx:50049 Re-using SSL/TLS context
Jan 5 12:54:10 openvpn[2211]: MULTI: multi_create_instance called
Jan 5 12:54:07 kernel: DROP(default) IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:1c:6f:65:c2:e2:9c:08:00 SRC=10.100.70.5 DST=10.100.70.255 LEN=202 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=182

Die VPN Verbindung wird zwar aufgebaut, ein Ping allerdings gedroppt.

Jan 5 12:55:30 kernel: DROP(default) IN=tun0 OUT=eth1 MAC= SRC=192.168.250.6 DST=10.100.71.254 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=55738 PROTO=ICMP TYPE=8 CODE=0 ID=1536 SEQ=9216 MARK=0x1

In der Fritz-Box vor dem BD hab ich die Ports 443,22,1194,500 und 4500 für die Firewall freigegeben.

Das gedropte ICMP-Paket kommt ja bereits an der Firewall an, also kann es nicht ein fehlendes Portforwarding an der Fritzbox sein.
"Irgendwas" wird mit den Interfaces/Zonen/Netzwerkobjekten nicht stimmen. Hat tun0 die Zone "vpn-openvpn"?

Folgende Einstellungen sind vorhanden:

Netzwerkkonfiguration:
tun0 192.168.250.1 24 vpn-ipsec, vpn-openvpn

Zonen:
Standard also eth0, eth1, eth2

vpn-ipsec tun0
vpn-openvpn tun0

Portfilter:
InternalNetwork -> Internet -> any
InternalNetwork -> Internal Interface -> proxy
InternalNetwork -> Samba -> any
Internet -> External Interface -> ipsec
Internet -> External Interface -> https
Internet -> External Interface -> openvpn
sslvpn-default -> InternalNetwork -> any
sslvpn-admin -> InternalNetwork -> any

Hide-Nat
Internal Network eth0 Private-Class-A Exclude
Internal Network eth0 Private-Class-B Exclude
Internal Network eth0 Private-Class-C Exclude
Internal Network eth0 Internet Include
sslvpn-default eth1 Internal Interface Exclude
Internet eth0 External Interface Include

Netzwerkobjekte:

Internet 0.0.0.0 0 external
External Interface 10.100.70.2 32 firewall-external
Internal Interface 10.100.71.1 32 firewall-internal
Internal Network 10.100.71.0 24 internal
Private-Class-A 10.0.0.0 8 vpn-ipsec
Private-Class-B 172.16.0.0 12 vpn-ipsec
Private-Class-C 192.168.0.0 16 vpn-ipsec
Samba 10.100.71.253 32 internal
sslvpn-default 12.168.250.0 25 vpn-openvpn
ssslvpn-admin 192.168.250.130 32 vpn-openvpn
Fritz 10.100.70.1 32 external

Das wäre es eigentlich.

das: sslvpn-default 12.168.250.0 25 vpn-openvpn
ist ein Tippfehler und soll sslvpn-default 192.168.250.0 24(!) vpn-openvpn heißen, oder?

und Hide NAT:
sslvpn-default eth1 Internal Interface Exclude
Internet eth0 External Interface Include

werden nicht benötigt oder ich verstehe den sinn gerade nicht.

dann:
tun0 192.168.250.1 24 vpn-ipsec, vpn-openvpn bitte vpn-ipsec entfernen

und dann die Frage nach dem sinn der fritzbox vor der black dwarf?

sslvpn-default 12.168.250.0 25 vpn-openvpn

Das Problem ist weniger die (wenn ich Ihre Intention richtig verstehe) korrekte Netzmaske von 25, denn die fehlende 9 *cough*

BINGO ERIK

Ich danke Ihnen, das hätte ich im schlimsten Fall erst in Tagen bemerkt !
Baum-Wald Syndrom

Der Teil der Installation wäre erledigt, der Server ist erreichbar !!

@achim
sslvpn-default ist schon ok (netmask 255.255.255.128 /25)
Die IP Adressen werden in dieser Range vergeben.

Die Hide-Nat Einträge sind "historisch gewachsen".
Ich werd sie rausnehmen und sehen was passiert.

Warum Fritz Box vor der BD ?

Ist keine produktive Umgebung.
Die BD hängt in meinem lokalen Netz.

Vielen Dank erst einmal.
Als Newbie werd ich mich wohl noch öfter melden, wenn ich darf.

Kein Problem. Und ja: Sie dürfen.