OpenVPN Client verbunden, aber untereinander nicht erreichba

[micha1977]

Hallo zusammen,

ich habe es endlich geschafft, das meine Zertifikate usw. stimmen und sich meine Clients ins VPN verbinden.
Ich kann vom Client den VPN-Server anpingen und mit den Clients ins Internet.

Was leider nicht geht: Die Clients erreichen sich nicht über die IP die Ihnen zugeteilt wurde.
Ich bin sicher etwas völlig einfaches, aber ich bin in Routingeinstellungen überhaupt nicht fit.

Die client-to-client im openvpn hatte ich schon getestet, nur funktioniert das nicht.
Habe ich diese Option aktiv, kommen meine Clients nicht mehr ins Internet über das VPN, ist die Option deaktiviert ist es bis auf das untereinander erreichen alles gut.

So sieht meine server.conf aus:

Code: Alles auswählen

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh2048.pem
server 192.168.9.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

Die client.conf

Code: Alles auswählen

client
dev tun
proto udp
remote 164.132.abc.def 1194
resolv-retry infinite

nobind

user nobody
group nogroup

persist-key
persist-tun

ca ca.crt
cert client1.crt
key client1.key

ns-cert-type server

comp-lzo

verb 3

netstat -r

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.9.2     *               255.255.255.255 UH        0 0          0 tun0
192.168.9.0     192.168.9.2     255.255.255.0   UG        0 0          0 tun0
default         *               0.0.0.0         U         0 0          0 venet0

Ich möchte erreichen, dass der Traffic 192.168.9.0 im Tunnel verbleibt und alles andere über venet0 (eth0) ins Internet rausgehen darf.
Also Client1 192.168.9.10 soll beispielsweise Client2 192.168.9.12 erreichen und mit ihm Daten austauschen.

So ist die Konstruktion

VPN-Client1 (192.168.9.10 via OPENVPN DHCP)
|
|
|
VPN-Server (192.168.9.1) (jeweils Pingbar) --------- Internet venet0 (164.132.abc.def)
|
|
|
VPN-Client2 (192.168.9.12 via OPENVPN DHCP)

[mat6937]

Die client-to-client im openvpn hatte ich schon getestet, nur funktioniert das nicht.
Habe ich diese Option aktiv, kommen meine Clients nicht mehr ins Internet über das VPN, ist die Option deaktiviert ist es bis auf das untereinander erreichen alles gut.

Wie sind mit und ohne client-to-client-Option auf dem Server, bei den Clients und beim Server die Ausgaben von:

Code: Alles auswählen

route -n
ip a
iptables -nvx -L POSTROUTING -t nat

?

[micha1977]

Die client-to-client im openvpn hatte ich schon getestet, nur funktioniert das nicht.
Habe ich diese Option aktiv, kommen meine Clients nicht mehr ins Internet über das VPN, ist die Option deaktiviert ist es bis auf das untereinander erreichen alles gut.

Wie sind mit und ohne client-to-client-Option auf dem Server, bei den Clients und beim Server die Ausgaben von:

Code: Alles auswählen

route -n
ip a
iptables -nvx -L POSTROUTING -t nat

?

Ohne Client-to-Client:
route-n

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 venet0

ip a

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/void
    inet 127.0.0.2/32 scope host venet0
    inet 164.132.abc.def/32 brd 164.132.abc.def scope global venet0:0
    inet6 2001:xxxx:8:xxxx:500:500:xxxx:fc01/128 scope global
       valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0

iptables -nvx -L POSTROUTING -t nat

Code: Alles auswählen

[quote]Chain POSTROUTING (policy ACCEPT 69 packets, 5626 bytes)
    pkts      bytes target     prot opt in     out     source               destination
     548    68708 MASQUERADE  all  --  *      venet0  10.0.0.0/8           0.0.0.0/0
       0        0 SNAT       all  --  *      venet0  10.8.0.0/24          0.0.0.0/0            to:<164.132.abc.def>[/quote]

Mit der Option Client-to-Client:
route-n

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 venet0

ip a

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/void
    inet 127.0.0.2/32 scope host venet0
    inet 164.132.abc.def/32 brd 164.132.abc.def scope global venet0:0
    inet6 2001:xxxx:8:xxxx:500:500:xxxx:fc01/128 scope global
       valid_lft forever preferred_lft forever
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0

iptables -nvx -L POSTROUTING -t nat

Code: Alles auswählen

Chain POSTROUTING (policy ACCEPT 128 packets, 10582 bytes)
    pkts      bytes target     prot opt in     out     source               destination
     583    73221 MASQUERADE  all  --  *      venet0  10.0.0.0/8           0.0.0.0/0
       0        0 SNAT       all  --  *      venet0  10.8.0.0/24          0.0.0.0/0            to:164.132.abc.def

[mat6937]

Die client-to-client im openvpn hatte ich schon getestet, nur funktioniert das nicht.
Habe ich diese Option aktiv, kommen meine Clients nicht mehr ins Internet über das VPN, ist die Option deaktiviert ist es bis auf das untereinander erreichen alles gut.

Wie sind mit und ohne client-to-client-Option auf dem Server, bei den Clients und beim Server die Ausgaben von:

Das ist die Ausgabe vom Server. Und jetzt noch vom Client?

[micha1977]

Das kann ich leider nicht einsehen. Bzw. werde dann mal noch ein Linux aufsetzen.
An einem Android habe ich mal einen VPN Client installiert und die Config reingezogen und da habe ich aus dem OPENVPN-LOG folgendes:

Code: Alles auswählen

0 [redirect-gateway][def][bypass-dhcp]
1 [dhcp-option][DNS][208.67.222.222]
2 [dhcp-option][DNS][208.67.220.220]
3 [route][10.8.0.0][255.255.255.0]
4 [topology][net30]
5 [ping][10]
6 [ping-restart][120]
7 [ifconfig][10.8.0.14][10.8.0.13]

Ein Netstat Tool schreibt folgendes auf dem Client

Code: Alles auswählen

Kernel IP routing table

Destination	Gateway 	Genmask			Flags	MSS	Windows irrt	Iface
0.0.0.0		192.168.10.1	0.0.0.0			UG	0	0	0	wlan0
0.0.0.0		192.168.10.1	0.0.0.0			UG	313	0	0	wlan0
10.8.0.12	0.0.0.0		255.255.255.252		U	0	0	0	tun0
192.168.10.0	0.0.0.0		255.255.255.192		U	0	0	0	wlan0
192.168.10.0	0.0.0.0		255.255.255.192		U	313	0	0	wlan0
192.168.10.1	0.0.0.0		255.255.255.255		UH	0	0	0	wlan0

[mat6937]

Ein Netstat Tool schreibt folgendes auf dem Client

Ist das unabhängig von der Konfiguration des Servers (... betr. client-to-client)?

[micha1977]

Ein Netstat Tool schreibt folgendes auf dem Client

Ist das unabhängig von der Konfiguration des Servers (... betr. client-to-client)?

Ja da kommt das gleiche raus.
wenn ich TCP-Dump auf dem Server mache also "tcpdump -i tun0"

sehe ich auch die Anfragen des Clients (Ping Testtool), aber keinen Reply von dem anderen VPN-Client.

07:38:27.923037 IP 10.8.0.14 > 10.8.0.6: ICMP echo request, id 1836, seq 6, length 64
07:38:28.997817 IP 10.8.0.14 > 10.8.0.6: ICMP echo request, id 1837, seq 1, length 64
07:38:28.997831 IP 10.8.0.14 > 10.8.0.6: ICMP echo request, id 1837, seq 1, length 64
07:38:30.002126 IP 10.8.0.14 > 10.8.0.6: ICMP echo request, id 1837, seq 2, length 64

[mat6937]

sehe ich auch die Anfragen des Clients (Ping Testtool), aber keinen Reply von dem anderen VPN-Client.

Hm, ... Du kannst jetzt auch nicht testen, ob das "ICMP echo request" den Server verlässt, beim anderen Client ankommt und dieser evtl. nicht antwortet.

Hast Du keine Möglichkeit, statt die Android-Clients, zum testen Geräte mit einem Linux (als OS) zu verwenden?

[micha1977]

Hast Du keine Möglichkeit, statt die Android-Clients, zum testen Geräte mit einem Linux (als OS) zu verwenden?

Jetzt habe ich einen raspi aufgesetzt und als Client genommen.
Also auch der kann die anderen VPN Clients nicht pingen.

dafür hab ich jetzt Detailinfos vom Client


route -n

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.13       128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.10.1    0.0.0.0         UG    202    0        0 eth0
10.8.0.0        10.8.0.13       255.255.255.0   UG    0      0        0 tun0
10.8.0.1        10.8.0.13       255.255.255.255 UGH   0      0        0 tun0
10.8.0.13       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.0.13       128.0.0.0       UG    0      0        0 tun0
192.168.10.0    0.0.0.0         255.255.255.192 U     202    0        0 eth0

ip -a

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether b8:27:eb:aa:0d:bc brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.31/26 brd 192.168.10.63 scope global eth0

iptables -nvx -L POSTROUTING -t nat

Code: Alles auswählen

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.8.0.14 peer 10.8.0.13/32 scope global tun0
       valid_lft forever preferred_lft forever

[mat6937]

dafür hab ich jetzt Detailinfos vom Client

route -n

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.13       128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.10.1    0.0.0.0         UG    202    0        0 eth0
10.8.0.0        10.8.0.13       255.255.255.0   UG    0      0        0 tun0
10.8.0.1        10.8.0.13       255.255.255.255 UGH   0      0        0 tun0
10.8.0.13       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.0.13       128.0.0.0       UG    0      0        0 tun0
192.168.10.0    0.0.0.0         255.255.255.192 U     202    0        0 eth0

Versuch mal das default gateway über eth0, mit einer niedrigeren metric zu konfigurieren, als die metric für das gateway mit tun0.

[micha1977]

dafür hab ich jetzt Detailinfos vom Client

route -n

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.13       128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.10.1    0.0.0.0         UG    202    0        0 eth0
10.8.0.0        10.8.0.13       255.255.255.0   UG    0      0        0 tun0
10.8.0.1        10.8.0.13       255.255.255.255 UGH   0      0        0 tun0
10.8.0.13       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.0.13       128.0.0.0       UG    0      0        0 tun0
192.168.10.0    0.0.0.0         255.255.255.192 U     202    0        0 eth0

Versuch mal das default gateway über eth0, mit einer niedrigeren metric zu konfigurieren, als die metric für das gateway mit tun0.

Ich muss googeln wie das geht, aber macht das denn Sinn ?
Die eingehenden Pakete kann ich auf dem VPN-Server mit tcpdump auf dem VPN Interface -tun0 ja sehen.

[mat6937]

..., aber macht das denn Sinn ?
Die eingehenden Pakete kann ich auf dem VPN-Server mit tcpdump auf dem VPN Interface -tun0 ja sehen.

Naja, Du lieferst permanent zu wenige und unklare Informationen (... betr. Ausgaben und was Du von wo aus machst). Es ist schwierig dir zu helfen.