kein Zugriff auf internes Netz nach Umstellung auf PPoE

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
wolfit
Beiträge: 7
Registriert: Di 03.08.2010, 22:59

kein Zugriff auf internes Netz nach Umstellung auf PPoE

Beitrag von wolfit »

Hallo,
wir haben seit 2009 eine Firewall hinter einem WLAN Router stehen. Externe User wählen sich über SSL-VPN ins Netzwerk ein und können auf das interne Netz zugreifen. Alles ohne Probleme.
Nun habe ich die Firewall auf PPoE umgestellt, da wir nun einen schnellen DSL-Anschluss haben.
Die IP-Adresse habe ich bei den Clients geändert. Diese können sich auch ohne Probleme auf die Firewall einwählen. Allerdings kommen diese nicht ins interne Netz.
Habe schon drei Stunden gespielt und gesucht, aber ohne Erfolg. Routen und Rules wurden nicht verändert.

Hier der Log vom VPN Client:
Tue May 14 20:22:47 2013 OpenVPN 2.3.1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Mar 28 2013
Enter Management Password:
Tue May 14 20:22:47 2013 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Tue May 14 20:22:47 2013 Need hold release from management interface, waiting...
Tue May 14 20:22:47 2013 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue May 14 20:22:47 2013 MANAGEMENT: CMD 'state on'
Tue May 14 20:22:47 2013 MANAGEMENT: CMD 'log all on'
Tue May 14 20:22:47 2013 MANAGEMENT: CMD 'hold off'
Tue May 14 20:22:47 2013 MANAGEMENT: CMD 'hold release'
Tue May 14 20:22:57 2013 MANAGEMENT: CMD 'username "Auth" "ralfwolf"'
Tue May 14 20:22:57 2013 MANAGEMENT: CMD 'password [...]'
Tue May 14 20:22:57 2013 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Tue May 14 20:22:57 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue May 14 20:22:57 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue May 14 20:22:57 2013 UDPv4 link local: [undef]
Tue May 14 20:22:57 2013 UDPv4 link remote: [AF_INET]217.91.47.51:1194
Tue May 14 20:22:57 2013 MANAGEMENT: >STATE:1368555777,WAIT,,,
Tue May 14 20:22:57 2013 MANAGEMENT: >STATE:1368555777,AUTH,,,
Tue May 14 20:22:57 2013 TLS: Initial packet from [AF_INET]217.91.47.51:1194, sid=2b15b0a7 e9d15d74
Tue May 14 20:22:57 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue May 14 20:22:58 2013 VERIFY OK: depth=1, C=DE, ST=Deutschland, L=Bayerbach, O=Luger, OU=VPN, CN=luger, emailAddress=info@wolf-pcsysteme.net
Tue May 14 20:22:58 2013 VERIFY OK: depth=0, C=DE, ST=Deutschland, L=Bayerbach, O=Luger, OU=VPN, CN=SSL_Server1, emailAddress=info@wolf-pcsysteme.net
Tue May 14 20:22:58 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue May 14 20:22:58 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 14 20:22:58 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue May 14 20:22:58 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 14 20:22:58 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue May 14 20:22:58 2013 [SSL_Server1] Peer Connection Initiated with [AF_INET]217.91.47.51:1194
Tue May 14 20:22:59 2013 MANAGEMENT: >STATE:1368555779,GET_CONFIG,,,
Tue May 14 20:23:00 2013 SENT CONTROL [SSL_Server1]: 'PUSH_REQUEST' (status=1)
Tue May 14 20:23:00 2013 PUSH: Received control message: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,dhcp-option DNS 192.168.10.1,dhcp-option DNS 192.168.10.90,route 192.168.250.1,topology net30,ping 10,ping-restart 120,ifconfig 192.168.250.6 192.168.250.5'
Tue May 14 20:23:00 2013 OPTIONS IMPORT: timers and/or timeouts modified
Tue May 14 20:23:00 2013 OPTIONS IMPORT: --ifconfig/up options modified
Tue May 14 20:23:00 2013 OPTIONS IMPORT: route options modified
Tue May 14 20:23:00 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue May 14 20:23:00 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue May 14 20:23:00 2013 MANAGEMENT: >STATE:1368555780,ASSIGN_IP,,192.168.250.6,
Tue May 14 20:23:00 2013 open_tun, tt->ipv6=0
Tue May 14 20:23:00 2013 TAP-WIN32 device [LAN-Verbindung 5] opened: \\\\.\\Global\\{A32A00B9-1223-43D5-9185-412828BF41D4}.tap
Tue May 14 20:23:00 2013 TAP-Windows Driver Version 9.9
Tue May 14 20:23:00 2013 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.250.6/255.255.255.252 on interface {A32A00B9-1223-43D5-9185-412828BF41D4} [DHCP-serv: 192.168.250.5, lease-time: 31536000]
Tue May 14 20:23:00 2013 Successful ARP Flush on interface [25] {A32A00B9-1223-43D5-9185-412828BF41D4}
Tue May 14 20:23:02 2013 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Tue May 14 20:23:02 2013 MANAGEMENT: >STATE:1368555782,ADD_ROUTES,,,
Tue May 14 20:23:02 2013 C:\\Windows\\system32\\route.exe ADD 192.168.10.0 MASK 255.255.255.0 192.168.250.5
Tue May 14 20:23:02 2013 env_block: add PATH=C:\\Windows\\System32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem
OK!
Tue May 14 20:23:02 2013 C:\\Windows\\system32\\route.exe ADD 192.168.250.1 MASK 255.255.255.255 192.168.250.5
Tue May 14 20:23:02 2013 env_block: add PATH=C:\\Windows\\System32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem
OK!
Tue May 14 20:23:03 2013 Initialization Sequence Completed
Tue May 14 20:23:03 2013 MANAGEMENT: >STATE:1368555783,CONNECTED,SUCCESS,192.168.250.6,217.91.47.51


Ich hoffe hier kann mir einer schnell Hilfestellung leisten.
Danke im Voraus.

Benutzeravatar
Erik
Securepoint
Beiträge: 1480
Registriert: Fr 07.11.2008, 11:50

Beitrag von Erik »

*an der Gebetsmühle dreh*
Haben Sie schonmal ins Log geschaut?
Sehen Sie dort, dass Pakete mit dem Eingangs-Interface "tun0" geDROPt werden, während Sie durch den Tunnel pingen*?
wenn ja: Liegt die Zone "vpn-openvpn" auf der Schnittstelle "tun0"?

Aktivieren Sie das Logging für die Regel: SSLVPN-Netz -> Internal Network. Sehen Sie im Log Pakete, die ACCEPTed werden, während Sie durch den Tunnel pingen*?
Wenn ja: Konfigurieren Sie die Default-Route und/oder die Firewall auf dem angepingten Host korrekt.


* "durch den Tunnel pingen" heißt: einen Host hinter der Firewall zu pingen. Die Firewall selber wird nie auf einen Ping antworten.

Antworten