8
DD-WRT IPv6 DHCP klappt nicht?
Hallo Leute,
ich habe mein Netzwerk umgebaut und Nutze eine Routerkaskade ( Speedport Hybrid für das LTE und TP-Link mit DD-WRT als WLAN AP, DHCP,DNS ).
Mein Aufbau sieht so aus:
WAN (SP Hyb) <-> LAN (SP Hyb) <-> WAN(DD-WRT) <LAN (DD-WRT)>
Speedport Hybrid
WAN erhält seine öffentliche IP von der DTAG
LAN hat eine interne IP, i.d.R. 192.168.2.1 /24
DHCP Aus
DD-WRT:
WAN erhält die 192.168.2.254/ 24, als GW 192.168.2.1 DNS 192.168.2.1
Router erhält die IP 172.17.0.1/ 24 als GW 172.17.0.1 DNS 172.17.0.1
DHCP-aktivieren (Range: 172.16.17.0.101 - 172.17.0.199 | Gateway: 172.17.0.1 | DNS: 172.17.0.1 , 192.168.2.1)
Firewall zum Test Deaktiviert
Netz für VPN: . 172.18.0.0/ 24,
Firmware: DD-WRT v3.0-r33772 std (11/16/17)
Zeit: 23:13:33 up 17:13, load average: 0.00, 0.04, 0.04
WAN IPv4: 192.168.2.254 IPv6: 2003:6:23e8:264:6670:2ff:fe5c:2733
Soweit klappt das auch . Alle Clienten bekommen vom DD-WRT eine IPv4 Adresse. Aber keine IPv6 obwohl unter Setup-> IPv6 Aktiv ist mit dem Type Native IPv6 from ISP. Aber keiner der Clients bekommt eine IPv6.
Weiteres Problem besteht wenn ich mich per OpenVPN einwähle von Außerhalb komme ich nicht auf den Speedport weder über 192.168.2.1 noch über speedport.ip. Auf 172.17.0.1 komme ich nach langen laden drauf .
Kann mir jemand helfen?
ich habe mein Netzwerk umgebaut und Nutze eine Routerkaskade ( Speedport Hybrid für das LTE und TP-Link mit DD-WRT als WLAN AP, DHCP,DNS ).
Mein Aufbau sieht so aus:
WAN (SP Hyb) <-> LAN (SP Hyb) <-> WAN(DD-WRT) <LAN (DD-WRT)>
Speedport Hybrid
WAN erhält seine öffentliche IP von der DTAG
LAN hat eine interne IP, i.d.R. 192.168.2.1 /24
DHCP Aus
DD-WRT:
WAN erhält die 192.168.2.254/ 24, als GW 192.168.2.1 DNS 192.168.2.1
Router erhält die IP 172.17.0.1/ 24 als GW 172.17.0.1 DNS 172.17.0.1
DHCP-aktivieren (Range: 172.16.17.0.101 - 172.17.0.199 | Gateway: 172.17.0.1 | DNS: 172.17.0.1 , 192.168.2.1)
Firewall zum Test Deaktiviert
Netz für VPN: . 172.18.0.0/ 24,
Firmware: DD-WRT v3.0-r33772 std (11/16/17)
Zeit: 23:13:33 up 17:13, load average: 0.00, 0.04, 0.04
WAN IPv4: 192.168.2.254 IPv6: 2003:6:23e8:264:6670:2ff:fe5c:2733
Soweit klappt das auch . Alle Clienten bekommen vom DD-WRT eine IPv4 Adresse. Aber keine IPv6 obwohl unter Setup-> IPv6 Aktiv ist mit dem Type Native IPv6 from ISP. Aber keiner der Clients bekommt eine IPv6.
Weiteres Problem besteht wenn ich mich per OpenVPN einwähle von Außerhalb komme ich nicht auf den Speedport weder über 192.168.2.1 noch über speedport.ip. Auf 172.17.0.1 komme ich nach langen laden drauf .
Kann mir jemand helfen?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 357273
Url: https://administrator.de/forum/dd-wrt-ipv6-dhcp-klappt-nicht-357273.html
Ausgedruckt am: 16.04.2025 um 11:04 Uhr
8 Kommentare
Neuester Kommentar
Aber keiner der Clients bekommt eine IPv6.
Das ist unmöglich, denn eine Link Local mit FE80 müssten die immer bekommen. IPv6 braucht auch kein DHCP denn es kann es mit der SLAAC Funktion auch selber ohne DHCP !Was du vermutlich meinst ist das die Prefix Delegation nicht klappt, also die Weitergabe des vom Provider zugeteilten IPv6 Subnetzes, richtig ?
Die generelle Frage ist ober der SP Hybrid das überhaupt supportet. Generell auch ob im LTE Netz überhaupt IPv6 benutzt wird mit Dual Stack. Das solltest du im Router Status überhaupt mal checken ob dort sowohl auf dem WAN xDSL und auf dem LTE Interface eine öffentliche IPv6 Adresse vergeben wurde.
Im LTE Netz wird in der Regel eine private RFC 1918 IP Adressierung verwendet in Verbindung mit Carrier Grade NAT. Einem zentralen NAT (IP Adress Translation) beim Provider auf das du keinen Einfluss hast.
Damit ist eine OpenVPN Einwahl dann technisch unmöglich, da du die NAT Firewall im Providernetz nicht überwinden kannst.
Das würde dann auch deine OpenVPN Probleme erklären. Der remote Zugriff aus dem Internet funktioniert nur dann wenn du am SP eine öffentliche IP Adresse bekommst.
Für die muss dann auf dem SP ein Port Forwarding für UDP 1194 (OpenVPN Default) eingetragen sein auf die WAN IP des kaskadierten DD-WRT. Siehe auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
oder hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Hier ist es wichtig das das Port Forwarding auf entweder einem WAN Port oder beiden funktioniert, denn eine eingehende OpenVPN Connection kann ja sowohl über den WAN als auch LTE Port reinkommen.
Bei Problemem sollte man testeweise immer einen Wireshark an den SP hängen der die gleiche IP Adresse hat wie der DD-WRT (den natürlich testweise abklemmen).
Mit dem Wireshark Sniffer filtert man dann auf OpenVPN Pakete UDP 1194. Wenn man jetzt von remote aus dem Internet den OVPN Client die öffentliche Ziel IP des Speedport an einem dessen WAN Porets anspricht, dann sollte der gemäß seine Port Weiterleitung alle diese eingehenden UDP 1194 Pakete an den DD-WRT weiterleiten was jetzt temporär der Wireshark Sniffer ist.
Diese Pakete solltest du dann sehen im Wireshark Sniffer.
Ist das der Fall klappt das Port Forwarding.
Siehst du nicht, dann stimmt schon generell am SP etwas im Setup nicht oder die OpenVPN Pakete erreichen den SP schon gar nicht erst wegen der CGN, RFC 1918 Adress problematik.
Das solltest du erstmal genau klären !
Zitat von @aqui:
Was du vermutlich meinst ist das die Prefix Delegation nicht klappt, also die Weitergabe des vom Provider zugeteilten IPv6 Subnetzes, richtig ?
Also eine Locale IPv6 bekommen die Clients aber keine öffentliche .Aber keiner der Clients bekommt eine IPv6.
Das ist unmöglich, denn eine Link Local mit FE80 müssten die immer bekommen. IPv6 braucht auch kein DHCP denn es kann es mit der SLAAC Funktion auch selber ohne DHCP !Was du vermutlich meinst ist das die Prefix Delegation nicht klappt, also die Weitergabe des vom Provider zugeteilten IPv6 Subnetzes, richtig ?
Der SP bekommt eine IPv4 und eine IPv6 adresse siehe Bild im Anhang.
Bis gestern Abend hat die Verbindung vom Handy über OpenVPN zum DDWRT Geklappt .Aber jetzt steht immer da Waiting for server.
Der SP bekommt eine IPv4 und eine IPv6 adresse siehe Bild im Anhang.
Das sieht gut aus !Auch die v4 IP ist eine öffentliche. Dann kann man CGN Probleme sicher ausschliessen.
Leider hast du das Port Forwarding nicht gepostet aber wenn du im OpenVPN Client als Ziel die 93.242.98.162 eingibst und der Router ein Port Forwarding hat was UDP 1194 auf die lokale 192.168.2.x IP am WAN Port des kaskadierten DD-WRTs weiterleitet, dann sollte sofort eine OVPN Verbindung zustande kommen !
Vermutlich hast du wechselnde IPs am SP WAN Port so das die 93.242.98.162 nicht ewig bleibt. hier musst du dann ggf. mit DynDNS arbeiten aber zum testen reicht erstmal die nackte IP. Man muss nur täglich nachsehen ob die sich geändert hat und dann im Client entsprechend anpassen.
IPv4 seitig sieht das also gut aus.
Was das Thema v6 anbetrifft ist die Frage ob der DD-WRT am WAN Port einen v6 DHCP Requests sendet zur Prefix Delegation.
Das solltest du am besten mit einem Wireshark mal checken. Ohne das wird ihm der SP vermutlich keine öffentliche v6 IP weiterreichen.
Sinnvoll wäre es hier mit dem Wireshark mal zu sehen ob die beiden sich überhaupt IPv6 Adresstechnisch unterhalten.
v4 seitig sollte aber alles sauber funbktionieren auch mit OVPN.
Was sagt denn das OVPN Log wenn du mit dem Client zugreifst ?? Da wäre mal ein Posting sowohl des Logs vom Client und besonders vom Server sehr hilfreich.
Also die Portweiterleitung Klappt und eine VPN Verbindung kommt zustande aber nur über TCP nicht über UDP.
Log Client:
Und das Log vom Server:
Server Config:
Log Client:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
Thu Dec 07 18:49:11 2017 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Thu Dec 07 18:49:11 2017 Windows version 6.1 (Windows 7) 64bit
Thu Dec 07 18:49:11 2017 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Enter Management Password:
Thu Dec 07 18:49:11 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Thu Dec 07 18:49:11 2017 Need hold release from management interface, waiting...
Thu Dec 07 18:49:12 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Thu Dec 07 18:49:12 2017 MANAGEMENT: CMD 'state on'
Thu Dec 07 18:49:12 2017 MANAGEMENT: CMD 'log all on'
Thu Dec 07 18:49:12 2017 MANAGEMENT: CMD 'echo all on'
Thu Dec 07 18:49:12 2017 MANAGEMENT: CMD 'hold off'
Thu Dec 07 18:49:12 2017 MANAGEMENT: CMD 'hold release'
Thu Dec 07 18:49:12 2017 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Thu Dec 07 18:49:12 2017 MANAGEMENT: >STATE:1512668952,RESOLVE,,,,,,
Thu Dec 07 18:49:12 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]93.242.98.162:1194
Thu Dec 07 18:49:12 2017 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Dec 07 18:49:12 2017 Attempting to establish TCP connection with [AF_INET]93.242.98.162:1194 [nonblock]
Thu Dec 07 18:49:12 2017 MANAGEMENT: >STATE:1512668952,TCP_CONNECT,,,,,,
Thu Dec 07 18:49:13 2017 TCP connection established with [AF_INET]93.242.98.162:1194
Thu Dec 07 18:49:13 2017 TCP_CLIENT link local: (not bound)
Thu Dec 07 18:49:13 2017 TCP_CLIENT link remote: [AF_INET]93.242.98.162:1194
Thu Dec 07 18:49:13 2017 MANAGEMENT: >STATE:1512668953,WAIT,,,,,,
Thu Dec 07 18:49:13 2017 MANAGEMENT: >STATE:1512668953,AUTH,,,,,,
Thu Dec 07 18:49:13 2017 TLS: Initial packet from [AF_INET]93.242.98.162:1194, sid=6d27bac9 eee6c92b
Thu Dec 07 18:49:13 2017 VERIFY OK: depth=1, C=DE, ST=Thueringen, L=Sondershausen, O=Privat, OU=OpenVPN, CN=OpenVPN, name=OpenVPN, emailAddress=top40@wb-mail.org
Thu Dec 07 18:49:13 2017 VERIFY OK: nsCertType=SERVER
Thu Dec 07 18:49:13 2017 VERIFY OK: depth=0, C=DE, ST=Thueringen, L=Sondershausen, O=Privat, OU=OpenVPN, CN=OpenVPN, name=OpenVPN, emailAddress=top40@wb-mail.org
Thu Dec 07 18:49:14 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Dec 07 18:49:14 2017 [OpenVPN] Peer Connection Initiated with [AF_INET]93.242.98.162:1194
Thu Dec 07 18:49:15 2017 MANAGEMENT: >STATE:1512668955,GET_CONFIG,,,,,,
Thu Dec 07 18:49:15 2017 SENT CONTROL [OpenVPN]: 'PUSH_REQUEST' (status=1)
Thu Dec 07 18:49:15 2017 PUSH: Received control message: 'PUSH_REPLY,route 192.168.2.0 255.255.255.0,route 172.17.0.0 255.255.255.0,route 172.18.0.0 255.255.255.0,dhcp-options DNS 192.168.2.1,dhcp-options DNS 172.17.0.1,route-gateway 172.18.0.1,topology subnet,ping 10,ping-restart 120,socket-flags TCP_NODELAY,ifconfig 172.18.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Thu Dec 07 18:49:15 2017 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:4: dhcp-options (2.4.4)
Thu Dec 07 18:49:15 2017 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:5: dhcp-options (2.4.4)
Thu Dec 07 18:49:15 2017 OPTIONS IMPORT: timers and/or timeouts modified
Thu Dec 07 18:49:15 2017 OPTIONS IMPORT: --socket-flags option modified
Thu Dec 07 18:49:15 2017 Socket flags: TCP_NODELAY=1 succeeded
Thu Dec 07 18:49:15 2017 OPTIONS IMPORT: --ifconfig/up options modified
Thu Dec 07 18:49:15 2017 OPTIONS IMPORT: route options modified
Thu Dec 07 18:49:15 2017 OPTIONS IMPORT: route-related options modified
Thu Dec 07 18:49:15 2017 OPTIONS IMPORT: peer-id set
Thu Dec 07 18:49:15 2017 OPTIONS IMPORT: adjusting link_mtu to 1627
Thu Dec 07 18:49:15 2017 OPTIONS IMPORT: data channel crypto options modified
Thu Dec 07 18:49:15 2017 Data Channel: using negotiated cipher 'AES-256-GCM'
Thu Dec 07 18:49:15 2017 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Dec 07 18:49:15 2017 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Dec 07 18:49:15 2017 interactive service msg_channel=0
Thu Dec 07 18:49:15 2017 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 I=12 HWADDR=50:e5:49:c2:d1:2a
Thu Dec 07 18:49:15 2017 open_tun
Thu Dec 07 18:49:15 2017 TAP-WIN32 device [LAN-Verbindung 3] opened: \\.\Global\{E272887F-4DCD-4AA2-A730-B31C3B055346}.tap
Thu Dec 07 18:49:15 2017 TAP-Windows Driver Version 9.21
Thu Dec 07 18:49:15 2017 Set TAP-Windows TUN subnet mode network/local/netmask = 172.18.0.0/172.18.0.2/255.255.255.0 [SUCCEEDED]
Thu Dec 07 18:49:15 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 172.18.0.2/255.255.255.0 on interface {E272887F-4DCD-4AA2-A730-B31C3B055346} [DHCP-serv: 172.18.0.254, lease-time: 31536000]
Thu Dec 07 18:49:15 2017 Successful ARP Flush on interface [20] {E272887F-4DCD-4AA2-A730-B31C3B055346}
Thu Dec 07 18:49:15 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Dec 07 18:49:15 2017 MANAGEMENT: >STATE:1512668955,ASSIGN_IP,,172.18.0.2,,,,
Thu Dec 07 18:49:21 2017 TEST ROUTES: 3/3 succeeded len=3 ret=1 a=0 u/d=up
Thu Dec 07 18:49:21 2017 MANAGEMENT: >STATE:1512668961,ADD_ROUTES,,,,,,
Thu Dec 07 18:49:21 2017 C:\Windows\system32\route.exe ADD 192.168.2.0 MASK 255.255.255.0 172.18.0.1
Thu Dec 07 18:49:21 2017 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Thu Dec 07 18:49:21 2017 Route addition via IPAPI succeeded [adaptive]
Thu Dec 07 18:49:21 2017 C:\Windows\system32\route.exe ADD 172.17.0.0 MASK 255.255.255.0 172.18.0.1
Thu Dec 07 18:49:21 2017 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Thu Dec 07 18:49:21 2017 Route addition via IPAPI succeeded [adaptive]
Thu Dec 07 18:49:21 2017 C:\Windows\system32\route.exe ADD 172.18.0.0 MASK 255.255.255.0 172.18.0.1
Thu Dec 07 18:49:21 2017 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Thu Dec 07 18:49:21 2017 Route addition via IPAPI succeeded [adaptive]
Thu Dec 07 18:49:21 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Dec 07 18:49:21 2017 Initialization Sequence Completed
Thu Dec 07 18:49:21 2017 MANAGEMENT: >STATE:1512668961,CONNECTED,SUCCESS,172.18.0.2,93.242.98.162,1194,192.168.178.20,37217Und das Log vom Server:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
20171207 18:47:29 MANAGEMENT: Client disconnected
20171207 18:49:06 N client1/146.52.255.68:35101 Connection reset restarting [-1]
20171207 18:49:06 client1/146.52.255.68:35101 SIGUSR1[soft connection-reset] received client-instance restarting
20171207 18:49:12 I TCP connection established with [AF_INET]146.52.255.68:37217
20171207 18:49:13 146.52.255.68:37217 TLS: Initial packet from [AF_INET]146.52.255.68:37217 sid=29c04e22 47a4f0e5
20171207 18:49:13 146.52.255.68:37217 VERIFY OK: depth=1 C=DE ST=Thueringen L=Sondershausen O=Privat OU=OpenVPN CN=OpenVPN name=OpenVPN emailAddress=top40@wb-mail.org
20171207 18:49:13 146.52.255.68:37217 VERIFY OK: depth=0 C=DE ST=Thueringen L=Sondershausen O=Privat OU=OpenVPN CN=client1 name=OpenVPN emailAddress=top40@wb-mail.org
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_VER=2.4.4
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_PLAT=win
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_PROTO=2
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_NCP=2
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_LZ4=1
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_LZ4v2=1
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_LZO=1
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_COMP_STUB=1
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_COMP_STUBv2=1
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_TCPNL=1
20171207 18:49:13 I 146.52.255.68:37217 peer info: IV_GUI_VER=OpenVPN_GUI_11
20171207 18:49:14 146.52.255.68:37217 Control Channel: TLSv1.2 cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 2048 bit RSA
20171207 18:49:14 I 146.52.255.68:37217 [client1] Peer Connection Initiated with [AF_INET]146.52.255.68:37217
20171207 18:49:14 I client1/146.52.255.68:37217 MULTI_sva: pool returned IPv4=172.18.0.2 IPv6=(Not enabled)
20171207 18:49:14 client1/146.52.255.68:37217 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_5416227b321ac202.tmp
20171207 18:49:14 client1/146.52.255.68:37217 MULTI: Learn: 172.18.0.2 -> client1/146.52.255.68:37217
20171207 18:49:14 client1/146.52.255.68:37217 MULTI: primary virtual IP for client1/146.52.255.68:37217: 172.18.0.2
20171207 18:49:15 client1/146.52.255.68:37217 PUSH: Received control message: 'PUSH_REQUEST'
20171207 18:49:15 client1/146.52.255.68:37217 SENT CONTROL [client1]: 'PUSH_REPLY route 192.168.2.0 255.255.255.0 route 172.17.0.0 255.255.255.0 route 172.18.0.0 255.255.255.0 dhcp-options DNS 192.168.2.1 dhcp-options DNS 172.17.0.1 route-gateway 172.18.0.1 topology subnet ping 10 ping-restart 120 socket-flags TCP_NODELAY ifconfig 172.18.0.2 255.255.255.0 peer-id 0 cipher AES-256-GCM' (status=1)
20171207 18:49:15 client1/146.52.255.68:37217 Data Channel: using negotiated cipher 'AES-256-GCM'
20171207 18:49:15 client1/146.52.255.68:37217 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20171207 18:49:15 client1/146.52.255.68:37217 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20171207 18:49:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 18:49:34 D MANAGEMENT: CMD 'state'
20171207 18:49:34 MANAGEMENT: Client disconnected
20171207 18:49:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 18:49:34 D MANAGEMENT: CMD 'state'
20171207 18:49:34 MANAGEMENT: Client disconnected
20171207 18:49:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 18:49:34 D MANAGEMENT: CMD 'state'
20171207 18:49:34 MANAGEMENT: Client disconnected
20171207 18:49:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 18:49:34 MANAGEMENT: Client disconnected
20171207 18:49:34 NOTE: --mute triggered...
20171207 18:49:34 1 variation(s) on previous 3 message(s) suppressed by --mute
20171207 18:49:34 D MANAGEMENT: CMD 'status 2'
20171207 18:49:34 MANAGEMENT: Client disconnected
20171207 18:49:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 18:49:34 D MANAGEMENT: CMD 'status 2'
20171207 18:49:34 MANAGEMENT: Client disconnected
20171207 18:49:35 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 18:49:35 D MANAGEMENT: CMD 'log 500'
20171207 18:49:35 MANAGEMENT: Client disconnected
20171207 19:12:48 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 19:12:48 D MANAGEMENT: CMD 'state'
20171207 19:12:48 MANAGEMENT: Client disconnected
20171207 19:12:48 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 19:12:48 D MANAGEMENT: CMD 'state'
20171207 19:12:48 MANAGEMENT: Client disconnected
20171207 19:12:49 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 19:12:49 D MANAGEMENT: CMD 'state'
20171207 19:12:49 MANAGEMENT: Client disconnected
20171207 19:12:49 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 19:12:49 MANAGEMENT: Client disconnected
20171207 19:12:49 NOTE: --mute triggered...
20171207 19:12:49 1 variation(s) on previous 3 message(s) suppressed by --mute
20171207 19:12:49 D MANAGEMENT: CMD 'status 2'
20171207 19:12:49 MANAGEMENT: Client disconnected
20171207 19:12:49 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 19:12:49 D MANAGEMENT: CMD 'status 2'
20171207 19:12:49 MANAGEMENT: Client disconnected
20171207 19:12:49 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20171207 19:12:49 D MANAGEMENT: CMD 'log 500'
19700101 01:00:00 Server Config:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
keepalive 10 120
verb 3
mute 3
syslog
writepid /var/run/openvpnd.pid
management 127.0.0.1 14
management-log-cache 100
topology subnet
script-security 2
port 1194
proto tcp4-server
cipher aes-256-cbc
auth sha256
client-connect /tmp/openvpn/clcon.sh
client-disconnect /tmp/openvpn/cldiscon.sh
client-config-dir /tmp/openvpn/ccd
comp-lzo adaptive
tls-server
duplicate-cn
client-to-client
tcp-nodelay
tun-mtu 1500
mtu-disc yes
server 172.18.0.0 255.255.255.0
dev tun2
push "route 192.168.2.0 255.255.255.0"
push "route 172.17.0.0 255.255.255.0"
push "route 172.18.0.0 255.255.255.0"
push "dhcp-options DNS 192.168.2.1"
push "dhcp-options DNS 172.17.0.1"
Wegen dem IPv6 . Der DD-WRT bekommt eine IP vom SP zugewiesen.WAN IPv4: 192.168.2.254 IPv6: 2003:6:219a:9c40:6670:2ff:fe5c:2733
Weiterhin ist über eine aktive VPN Verbindung kein zugriff auf den SP möglich ( 192.168.2.1 , speedport.ip)
Die Netzwerkdaten vom Client sehen wie folgt aus:
Ausgabe route print
Weiterhin ist über eine aktive VPN Verbindung kein zugriff auf den SP möglich ( 192.168.2.1 , speedport.ip)
Die Netzwerkdaten vom Client sehen wie folgt aus:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Verbindungsspezifisches DNS-Suffix:
Beschreibung: TP-LINK 300Mbps Wireless N Adapter
Physikalische Adresse: A0-F3-C1-45-52-AD
DHCP-aktiviert: Ja
IPv4-Adresse: 172.17.0.104
IPv4-Subnetzmaske: 255.255.255.0
Lease erhalten: Freitag, 8. Dezember 2017 10:58:37
Lease läuft ab: Dienstag, 12. Dezember 2017 10:58:37
IPv4-Standardgateway: 172.17.0.1
IPv4-DHCP-Server: 172.17.0.1
IPv4-DNS-Server: 172.17.0.1, 192.168.2.1
IPv4-WINS-Server:
NetBIOS über TCPIP aktiviert: Ja
Verbindungslokale IPv6-Adresse: fe80::3d27:98b9:1693:82b3%12
IPv6-Standardgateway:
IPv6-DNS-Server:Ausgabe route print
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
===========================================================================
Schnittstellenliste
12...a0 f3 c1 45 52 ad ......TP-LINK 300Mbps Wireless N Adapter
1...........................Software Loopback Interface 1
20...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter
19...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 172.17.0.1 172.17.0.104 25
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
172.17.0.0 255.255.255.0 Auf Verbindung 172.17.0.104 281
172.17.0.104 255.255.255.255 Auf Verbindung 172.17.0.104 281
172.17.0.255 255.255.255.255 Auf Verbindung 172.17.0.104 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306
224.0.0.0 240.0.0.0 Auf Verbindung 172.17.0.104 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
255.255.255.255 255.255.255.255 Auf Verbindung 172.17.0.104 281
===========================================================================
St„ndige Routen:
Keine
IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 306 ::1/128 Auf Verbindung
12 281 fe80::/64 Auf Verbindung
12 281 fe80::3d27:98b9:1693:82b3/128
Auf Verbindung
1 306 ff00::/8 Auf Verbindung
12 281 ff00::/8 Auf Verbindung
===========================================================================
St„ndige Routen:
Keinekommt zustande aber nur über TCP nicht über UDP.
Sorry aber das wäre technischer Blödsinn. Das kann dann nur eine Fehlkonfiguration von Server und Client sein. IP seitig ist es ja identisch nur das der TCP Overhead fehlt.Der Fehler wäre hier "proto tcp4-server "
Das müsste im Server
port 1194
proto udp
lauten und im Client entsprechend:
client
dev tun
proto udp
Oder dein Provider filtert den Port UDP 1194 wovon aber mal nicht auszugehen ist oder wenn doch kannst du das überlisten indem du mal eine freien Ephemal Port dafür nutzt und Server und Client auf UDP 611194 setzt testweise. Das sollte immer klappen.
port 61194
proto udp
lauten und im Client dann wieder entsprechend:
client
dev tun
proto udp
remote <server_ip> 61194
Wegen dem IPv6
Der Dativ ist dem Genitiv sein Tod !!Weiterhin ist über eine aktive VPN Verbindung kein zugriff auf den SP möglich
Mmmhh !Sieh dir doch mal die Routing Tabellen an im OVPN Client route print !!!
Kannst du dort sehen das das 192.168.2.0 /24 Netz dort auch in den Tunnel geroutet wird ???
Wenn ja dann ist es eine Firewall Frage !
Macht dein DD-WRT NAT zum SP am WAN Port (Gateway Mode) ?
Hallo und Danke für deine Antwort
OpenVpn über UDP klappt. Hatte einen fehler in den Config Dateien.
Thema IPv6 : Keiner der Clients bekommt eine Öffentliche v6 Adresse zugewiesen. Als Test habe ich den Laptop diereckt an den SP geklemmt und dort DHCP usw aktiviert. Resultat Laptop bekommt eine Öffentliche v6 Adresse. Wenn der DD-WRT dazwischen hängt gibt es nur noch eine fe80 adresse.
Routing: wenn ich per vpn verbunden bin und in der server config sage push "route 192.168.2.0 255.255.255.0" bzw in der client config route 192.168.2.0 255.255.255.0 ändert sich nix. wie kann ich es umsetzen das ich vom vpn netz 172.18.0.0 255.255.255.0 ins netz des SP komme? (192.168.2.1 255.255.255.0 )
SP LAN1 -> WAN DD-WRT . Läuft im Gateway Modus SPI Firewall Deaktiviert
Hier mal die Routing Tabelle vom DD-WRT
OpenVpn über UDP klappt. Hatte einen fehler in den Config Dateien.
Thema IPv6 : Keiner der Clients bekommt eine Öffentliche v6 Adresse zugewiesen. Als Test habe ich den Laptop diereckt an den SP geklemmt und dort DHCP usw aktiviert. Resultat Laptop bekommt eine Öffentliche v6 Adresse. Wenn der DD-WRT dazwischen hängt gibt es nur noch eine fe80 adresse.
Routing: wenn ich per vpn verbunden bin und in der server config sage push "route 192.168.2.0 255.255.255.0" bzw in der client config route 192.168.2.0 255.255.255.0 ändert sich nix. wie kann ich es umsetzen das ich vom vpn netz 172.18.0.0 255.255.255.0 ins netz des SP komme? (192.168.2.1 255.255.255.0 )
SP LAN1 -> WAN DD-WRT . Läuft im Gateway Modus SPI Firewall Deaktiviert
Hier mal die Routing Tabelle vom DD-WRT
1
2
3
4
5
6
2
3
4
5
6
Ziel-LAN-Netz Netzmaske Gateway Markierungen Metrik Schnittstelle
default 0.0.0.0 192.168.2.1 UG 0 WAN
169.254.0.0 255.255.0.0 * U 0 LAN & WLAN
172.17.0.0 255.255.255.0 * U 0 LAN & WLAN
172.18.0.0 255.255.255.0 * U 0 tun2
192.168.2.0 255.255.255.0 * U 0 WANOpenVpn über UDP klappt. Hatte einen Fehler in den Config Dateien.
Wäre auch sehr verwunderlich gewesen wenn es nicht geklappt hätte... 
Keiner der Clients bekommt eine Öffentliche v6 Adresse zugewiesen
Vermutlich gibt der DD-WRT die Prefix Delegation vom davor kaskadierten SP nicht weiter. Dann ist es logisch das Clients im dortigen LAN natürlich keine öffentliche v6 Adresse bekommen.Hast du mal geprüft ob der v6 DHCP Client und Server überhaupt rennt im DD-WRT ??
Das geht mit ps wenn du über SSH (z.B. PuTTY) mal aufs DD-WRT CLI connectest.
Hier wären auch folgende Outputs mal spannenend:
ifconfig
ip -6 route
cat /tmp/dhcp6c.conf
cat /tmp/radvd.conf
cat /tmp/dhcp6s.conf
Der DD-WRT muss die Prefix Delegation ja durchreichen an seinen LAN Port, sonst scheitert das ganze. Gg.f musst du in der DD-WRT Knowledgebase mal danach suchen ob da noch Konsolen Handarbeit ggf. für nötig ist.
Du bekommst ja einen /56er Prefix zugewiesen mit 2003:0006:219a:9c00::, hast also auch die Möglichkeit eine v6 Adresse statisch zu vergeben:
Der SP hat am LAN das Subnetz 2003:0006:219a:9c53:: /64 Du kannst dem DD-WRT ja ganz einfach mal statische v6 IP Adressen vergeben um wenigstens die generelle Funktion des v6 Routings mal zu testen
z.B. 2003:0006:219a:9c54:: /64
Die v6 Adressierung sähe dann so aus:
SP LAN Port: 2003:0006:219a:9c53::1 /64
DD-WRT WAN Port: 2003:0006:219a:9c53::affe /64
DD-WRT LAN Port: 2003:0006:219a:9c54::affe /64
v6 Default Route DD-WRT: 2003:0006:219a:9c53::1
Das sollte für einen ersten v6 Test sauber funktionieren z.B. auf http://www.kame.net oder http://test-ipv6.com
Vermutlich aber nicht für ewig, denn wenn die v6 Privacy Extension wieder zuschlägt bekommst du einen neuen Prefix.
Wenn es klappt (wenigstesn temporär) zeigt das aber die generell v6 Funktion des Routers und man muss dann nur noch die v6 Prefix Delegation zum Fliegen bekommen im DD-WRT.
