Windows 10 - Open VPN - internes Netz [gelöst]

scheffe2804

Moin erstmal,

erst nervt mich ungemein, dass ichs nicht hinbekomme, aber naja , nun brauch ich Hilfe.

Ich habe mich per OpenVPN mit meinem PFSense verbunden.
Per Portweiterleitung auf ner FritzBos ins interne Netz, auf den PFsense.
Funktioniert klasse. Kompletten Traffc redirekten geht auch wunderbar.
Ich kann die IP des Tunnel Netzwerks 192.168.111.0/24 , in dem Fall die .1 pingen
Ich kann die PFsense IP des internen Netzes pingen, in dem Fall die 10.10.6.1 und auf den PFsense zugreifen.

Ich kann aber keine aktive interne IP pingen.
Ein Traceroute ergibt

Routenverfolgung zu 10.10.6.27 über maximal 30 Hops

1 * 58 ms 49 ms 192.168.111.1
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.

Das heisst das Routing in eine Richtung stimmt schonmal.
In der VPN Server Konf. hab ich 10.10.6.0/24 als IPv4 Local Network angegeben.

Die Windows Firewall ist aus.

Ein netstat -a auf der PFsense ergibt

Internet:
Destination Gateway Flags Netif Expire
default 192.168.181.1 UGS re0
10.10.6.0 link#4 U em3
10.10.6.1 link#4 UHS lo0
localhost link#9 UH lo0
192.168.111.0 192.168.111.2 UGS ovpns1
192.168.111.1 link#10 UHS lo0
192.168.111.2 link#10 UH ovpns1
192.168.181.0 link#5 U re0
192.168.181.1 6c:62:6d:3d:4a:ce UHS re0
192.168.181.23 link#5 UHS lo0

Internet6:
Destination Gateway Flags Netif Expire
default fe80::ca0e:14ff:fe UGS re0
localhost link#9 UH lo0
2002:592:7b67:: link#5 U re0
2002:592:7b67:0:6e link#5 UHS lo0
2002:592:7b67:fc:: link#4 U em3
2002:592:7b67:fc:2 link#4 UHS lo0
fe80::ca0e:14ff:fe fe80::ca0e:14ff:fe UGHS re0
fe80::%em3 link#4 U em3
fe80::1:1%em3 link#4 UHS lo0
fe80::%re0 link#5 U re0
fe80::6e62:6dff:fe link#5 UHS lo0
fe80::%lo0 link#9 U lo0
fe80::1%lo0 link#9 UHS lo0
fe80::215:17ff:feb link#10 UHS lo0
ff01::%em3 2002:592:7b67:fc:2 U em3
ff01::%re0 fe80::6e62:6dff:fe U re0
ff01::%lo0 localhost U lo0
ff01::%ovpns1 fe80::215:17ff:feb U ovpns1
ff02::%em3 2002:592:7b67:fc:2 U em3
ff02::%re0 fe80::6e62:6dff:fe U re0
ff02::%lo0 localhost U lo0
ff02::%ovpns1 fe80::215:17ff:feb U ovpns1

Auf der Firewall habe ich (Testzwecken) folgende Regeln

WLAN3 (internes Netz 10.10.6.0/24)
192.168.111.0/24 allow any (VPN Netz)
WLAN3 net default allow to any rule (das interne 10.10.6.0/24)

OpenVPN

Die allow any to any rules vom OpenVPN Wizard

Auf dem WAN

192.168.111.0/24 any to any

Als Client im internen Netz (WLAN3), funtioniert der Zugriff auf alle Geräte.

Danke schonmal fürs "bis hierhin lesen" :-)

Chris

viragomann

@scheffe2804:

In der VPN Server Konf. hab ich 10.10.6.0/24 als IPv4 Local Network angegeben.

Trotz "Redirect gateway"??

@scheffe2804:

Ein netstat -a auf der PFsense ergibt

Internet:
Destination Gateway Flags Netif Expire
default 192.168.181.1 UGS re0
10.10.6.0 link#4 U em3
10.10.6.1 link#4 UHS lo0
localhost link#9 UH lo0
192.168.111.0 192.168.111.2 UGS ovpns1
192.168.111.1 link#10 UHS lo0
192.168.111.2 link#10 UH ovpns1
192.168.181.0 link#5 U re0
192.168.181.1 6c:62:6d:3d:4a:ce UHS re0
192.168.181.23 link#5 UHS lo0

Ich habe Zweifel, das "netstat -a" diesen Output liefert.
Außerdem liefert er zu wenig Information. Interessanter wäre "netstat -nr".

@scheffe2804:

Die Windows Firewall ist aus.

Auf dem Zielhost? Das wäre eigentlich mein großer Verdacht in dem Fall.

@scheffe2804:

Danke schonmal fürs "bis hierhin lesen" :-)

Bitte. :)

Jetzt sollte mir noch etwas Vernünftiges zu deinem Problem einfallen? Eigentleich müsste es laufen, wenn du alles so gesetzt hast.

Die pfSense ist ja in dem LAN, auf das du zugreifen willst, das Default Gateway, oder? Die auf 1 endende IP würde darauf hindeuten. Die Hosts richtig konfiguriert?

Wie erwähnt, die System-Firewall am Zielhost ist auch immer ein heißer Tipp.
Ach ja, falls du eine zusätzliche OpenVPN-Instanz laufen hast, sollte das auch hier Erwähnung finden.

Ansonsten würde ich Packet Capture der pfSense zum Troubleshooting einsetzen.
Stelle das Interface auf das, an dem der Zielhost hängt, das Protokoll auf ICMP und starte das Capture. Versuche einen Ping vom VPN-Client, stoppe das Capture und falls du es damit nicht selbst lösen kannst, poste den Output.
Mache auch eines am OpenVPN-Interface.

Grüße

scheffe2804

trotz "Redirect gateway"??

Nein, das ist wieder aus :-)

Im Moment pinge ich von der 192.168.111.2 (also dem Windows Rechner im VPN) vier Hosts im internen Pfsense WLAN3 Netz an.
10.10.6.20 , .25, .26, .27
sowie die PFsense IP des internen Netzes
10.10.6.1

Nun ein paar logs

Tcpdump auf WAN

[2.3.3-RELEASE][root@wlangate.fritz.box]/root: tcpdump -D
1.re0
2.ovpns1
3.em3
4.lo0
[2.3.3-RELEASE][root@wlangate.fritz.box]/root: tcpdump -nni re0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:20:39.988339 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2451, length 8
23:20:40.490328 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2452, length 8
23:20:40.996332 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2453, length 8
23:20:41.497323 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2454, length 8
23:20:42.018326 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2455, length 8
23:20:42.519326 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2456, length 8
23:20:43.029325 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2457, length 8
23:20:43.531340 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2458, length 8
23:20:44.041334 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2459, length 8
23:20:44.547536 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2460, length 8
23:20:45.048337 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2461, length 8
23:20:45.571575 IP 192.168.181.23 > 192.168.181.1: ICMP echo request, id 16101, seq 2462, length 8
^C
12 packets captured
164 packets received by filter
0 packets dropped by kernel

Die 192.168.181.23 ist die IP des PF sense in Richtung Fritzbox (Internet).
Die Echo Requests laufen weiter, unanhängig von meinen Pings, null Ahnung wo das herkommt.

tcpdump auf openvpn

[2.3.3-RELEASE][root@wlangate.fritz.box]/root: tcpdump -nni ovpns1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpns1, link-type NULL (BSD loopback), capture size 65535 bytes
23:24:53.336702 IP 192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 27020, length 40
23:24:53.336726 IP 10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 27020, length 40
23:24:53.895977 IP 192.168.111.2 > 10.10.6.20: ICMP echo request, id 8, seq 27021, length 40
23:24:54.343047 IP 192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 27022, length 40
23:24:54.343068 IP 10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 27022, length 40
23:24:54.392572 IP 192.168.111.2 > 10.10.6.25: ICMP echo request, id 8, seq 27023, length 40
23:24:54.392620 IP 192.168.111.2 > 10.10.6.26: ICMP echo request, id 8, seq 27024, length 40
23:24:55.346071 IP 192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 27025, length 40
23:24:55.346085 IP 10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 27025, length 40
23:24:55.898771 IP 192.168.111.2 > 10.10.6.20: ICMP echo request, id 8, seq 27026, length 40
23:24:56.350943 IP 192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 27027, length 40
23:24:56.350958 IP 10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 27027, length 40
23:24:56.893757 IP 192.168.111.2 > 10.10.6.27: ICMP echo request, id 8, seq 27028, length 40
23:24:57.354386 IP 192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 27029, length 40
23:24:57.354394 IP 10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 27029, length 40
23:24:57.393240 IP 192.168.111.2 > 10.10.6.20: ICMP echo request, id 8, seq 27030, length 40
23:24:57.896079 IP 192.168.111.2 > 10.10.6.20: ICMP echo request, id 8, seq 27031, length 40
23:24:58.365400 IP 192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 27032, length 40
23:24:58.365412 IP 10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 27032, length 40
23:24:59.361696 IP 192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 27038, length 40
23:24:59.361711 IP 10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 27038, length 40
23:24:59.392666 IP 192.168.111.2 > 10.10.6.25: ICMP echo request, id 8, seq 27039, length 40
23:24:59.392703 IP 192.168.111.2 > 10.10.6.26: ICMP echo request, id 8, seq 27040, length 40
23:25:00.365687 IP 192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 27041, length 40
23:25:00.365695 IP 10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 27041, length 40
23:25:01.372373 IP 192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 27042, length 40
23:25:01.372379 IP 10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 27042, length 40
23:25:01.889785 IP 192.168.111.2 > 10.10.6.27: ICMP echo request, id 8, seq 27043, length 40

Der VPNrechner pingt, PFsense antwortet brav.
Aber keine Spur von den Pings zu den anderen Rechnern!?

Tcpdump auf em3 also WLAN3


[2.3.3-RELEASE][root@wlangate.fritz.box]/root: tcpdump -nni em3 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em3, link-type EN10MB (Ethernet), capture size 65535 bytes

Nun das Ganze mit dem Packet Capture

WAN


23:33:20.556529 IP (tos 0x0, ttl 64, id 39372, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->f5aa)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 411, length 8
23:33:21.088531 IP (tos 0x0, ttl 64, id 40867, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->efd3)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 412, length 8
23:33:21.620517 IP (tos 0x0, ttl 64, id 46631, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->d94f)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 413, length 8
23:33:22.130534 IP (tos 0x0, ttl 64, id 43214, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->e6a8)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 414, length 8
23:33:22.632263 IP (tos 0x0, ttl 64, id 43863, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->e41f)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 415, length 8
23:33:23.157281 IP (tos 0x0, ttl 64, id 41977, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->eb7d)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 416, length 8
23:33:23.659264 IP (tos 0x0, ttl 64, id 21204, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->3ca3)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 417, length 8
23:33:24.184285 IP (tos 0x0, ttl 64, id 42714, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->e89c)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 418, length 8
23:33:24.716514 IP (tos 0x0, ttl 64, id 49848, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->ccbe)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 419, length 8
23:33:25.224283 IP (tos 0x0, ttl 64, id 27740, offset 0, flags [none], proto ICMP (1), length 28, bad cksum 0 (->231b)!)
    192.168.181.23 > 192.168.181.1: ICMP echo request, id 22207, seq 420, length 8

OpenVPN

23:34:41.877168 IP (tos 0x0, ttl 128, id 26672, offset 0, flags [none], proto ICMP (1), length 60)
192.168.111.2 > 10.10.6.27: ICMP echo request, id 8, seq 28749, length 40
23:34:41.937859 IP (tos 0x0, ttl 128, id 6614, offset 0, flags [none], proto ICMP (1), length 60)
192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 28750, length 40
23:34:41.937875 IP (tos 0x0, ttl 64, id 28417, offset 0, flags [none], proto ICMP (1), length 60)
10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 28750, length 40
23:34:42.376855 IP (tos 0x0, ttl 128, id 30466, offset 0, flags [none], proto ICMP (1), length 60)
192.168.111.2 > 10.10.6.20: ICMP echo request, id 8, seq 28751, length 40
23:34:42.944751 IP (tos 0x0, ttl 128, id 6616, offset 0, flags [none], proto ICMP (1), length 60)
192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 28752, length 40
23:34:42.944767 IP (tos 0x0, ttl 64, id 516, offset 0, flags [none], proto ICMP (1), length 60)
10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 28752, length 40
23:34:43.950033 IP (tos 0x0, ttl 128, id 6617, offset 0, flags [none], proto ICMP (1), length 60)
192.168.111.2 > 10.10.6.1: ICMP echo request, id 8, seq 28753, length 40
23:34:43.950042 IP (tos 0x0, ttl 64, id 57164, offset 0, flags [none], proto ICMP (1), length 60)
10.10.6.1 > 192.168.111.2: ICMP echo reply, id 8, seq 28753, length 40
23:34:44.377044 IP (tos 0x0, ttl 128, id 28235, offset 0, flags [none], proto ICMP (1), length 60)
192.168.111.2 > 10.10.6.26: ICMP echo request, id 8, seq 28754, length 40
23:34:44.381782 IP (tos 0x0, ttl 128, id 23357, offset 0, flags [none], proto ICMP (1), length 60)
192.168.111.2 > 10.10.6.25: ICMP echo request, id 8, seq 28755, length 40

em3 (WLAN3)

Keine Ergebnisse

Nun das Ganze per Windump auf dem Windows VPN PC

C:\Users\christian\Downloads>windump -d
windump: listening on \Device\NPF_{840BAA92-EDA0-4078-88E3-2900055B0D89}
(000) ret      #96

C:\Users\christian\Downloads>windump -D
1.\Device\NPF_{2AF82981-DE2F-4DAB-8D5E-D206044B8171} (Intel(R) 82567LF-2 Gigabit Network Connection)
2.\Device\NPF_{840BAA92-EDA0-4078-88E3-2900055B0D89} (TAP-Windows Adapter V9)
3.\Device\NPF_{BE912181-A207-412C-BDCD-5A31A2D77E9E} (Realtek RTL8139/810x Family Fast Ethernet NIC                                   )

C:\Users\christian\Downloads>windump -i \Device\NPF_{840BAA92-EDA0-4078-88E3-2900055B0D89}
windump: listening on \Device\NPF_{840BAA92-EDA0-4078-88E3-2900055B0D89}
23:58:35.462124 IP christian-PC > 10.10.6.26: ICMP echo request, id 8, seq 32900, length 40
23:58:35.975840 IP christian-PC > 10.10.6.1: ICMP echo request, id 8, seq 32901, length 40
23:58:35.992510 IP 10.10.6.1 > christian-PC: ICMP echo reply, id 8, seq 32901, length 40
23:58:36.235471 IP christian-PC.137 > 10.10.6.26.137: UDP, length 50
23:58:36.961372 IP christian-PC > 10.10.6.20: ICMP echo request, id 8, seq 32902, length 40
23:58:36.979799 IP christian-PC > 10.10.6.1: ICMP echo request, id 8, seq 32903, length 40
23:58:36.996499 IP 10.10.6.1 > christian-PC: ICMP echo reply, id 8, seq 32903, length 40
23:58:37.734888 IP christian-PC.137 > 10.10.6.26.137: UDP, length 50
23:58:37.985034 IP christian-PC > 10.10.6.1: ICMP echo request, id 8, seq 32904, length 40
23:58:38.000949 IP 10.10.6.1 > christian-PC: ICMP echo reply, id 8, seq 32904, length 40
23:58:38.961645 IP christian-PC > 10.10.6.27: ICMP echo request, id 8, seq 32905, length 40
23:58:38.962618 IP christian-PC > 10.10.6.27: ICMP echo request, id 8, seq 32906, length 40
23:58:38.988114 IP christian-PC > 10.10.6.1: ICMP echo request, id 8, seq 32907, length 40
23:58:39.011130 IP 10.10.6.1 > christian-PC: ICMP echo reply, id 8, seq 32907, length 40
23:58:39.235136 IP christian-PC.137 > 10.10.6.26.137: UDP, length 50
23:58:39.992297 IP christian-PC > 10.10.6.1: ICMP echo request, id 8, seq 32908, length 40
23:58:40.007130 IP 10.10.6.1 > christian-PC: ICMP echo reply, id 8, seq 32908, length 40
23:58:40.461356 IP christian-PC > 10.10.6.26: ICMP echo request, id 8, seq 32909, length 40
23:58:40.997449 IP christian-PC > 10.10.6.1: ICMP echo request, id 8, seq 32910, length 40
23:58:41.012427 IP 10.10.6.1 > christian-PC: ICMP echo reply, id 8, seq 32910, length 40
23:58:41.961041 IP christian-PC > 10.10.6.20: ICMP echo request, id 8, seq 32911, length 40
23:58:42.000554 IP christian-PC > 10.10.6.1: ICMP echo request, id 8, seq 32912, length 40
23:58:42.018931 IP 10.10.6.1 > christian-PC: ICMP echo reply, id 8, seq 32912, length 40
23:58:43.005717 IP christian-PC > 10.10.6.1: ICMP echo request, id 8, seq 32913, length 40
23:58:43.031594 IP 10.10.6.1 > christian-PC: ICMP echo reply, id 8, seq 32913, length 40
23:58:43.962900 IP christian-PC > 10.10.6.27: ICMP echo request, id 8, seq 32915, length 40
23:58:43.962903 IP christian-PC > 10.10.6.27: ICMP echo request, id 8, seq 32914, length 40
23:58:44.008924 IP christian-PC > 10.10.6.1: ICMP echo request, id 8, seq 32916, length 40
23:58:44.029809 IP 10.10.6.1 > christian-PC: ICMP echo reply, id 8, seq 32916, length 40
23:58:44.202240 IP
30 packets captured
98 packets received by filter
0 packets dropped by kernel

Netstat -r auf Windows Rechner

C:\Users\christian\Downloads>netstat -r
===========================================================================
Schnittstellenliste
  9...00 1c c0 88 24 7b ......Intel(R) 82567LF-2-Gigabit-Netzwerkverbindung
 18...00 ff 84 0b aa 92 ......TAP-Windows Adapter V9
 23...00 0e 2e f1 ca 20 ......Fast-Ethernet-Netzwerkkarte für Realtek RTL8139/810x-Familie
  1...........................Software Loopback Interface 1
 17...00 00 00 00 00 00 00 e0 Microsoft Teredo Tunneling Adapter
 21...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 11...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.162     25
        10.10.6.0    255.255.255.0    192.168.111.1    192.168.111.2    291
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
      192.168.1.0    255.255.255.0   Auf Verbindung     192.168.1.162    281
    192.168.1.162  255.255.255.255   Auf Verbindung     192.168.1.162    281
    192.168.1.255  255.255.255.255   Auf Verbindung     192.168.1.162    281
    192.168.111.0    255.255.255.0   Auf Verbindung     192.168.111.2    291
    192.168.111.2  255.255.255.255   Auf Verbindung     192.168.111.2    291
  192.168.111.255  255.255.255.255   Auf Verbindung     192.168.111.2    291
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.111.2    291
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.1.162    281
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.111.2    291
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.1.162    281
===========================================================================
Ständige Routen:
  Keine

Net stat auf dem PFSense

Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
default            192.168.181.1      UGS         re0
10.10.6.0/24       link#4             U           em3
10.10.6.1          link#4             UHS         lo0
127.0.0.1          link#9             UH          lo0
192.168.111.0/24   192.168.111.2      UGS      ovpns1
192.168.111.1      link#10            UHS         lo0
192.168.111.2      link#10            UH       ovpns1
192.168.181.0/24   link#5             U           re0
192.168.181.1      6c:62:6d:3d:4a:ce  UHS         re0
192.168.181.23     link#5             UHS         lo0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
default                           fe80::ca0e:14ff:fe8d:6b79%re0 UGS         re0
::1                               link#9                        UH          lo0
2002:592:7b67::/64                link#5                        U           re0
2002:592:7b67:0:6e62:6dff:fe3d:4ace link#5                        UHS         lo0
2002:592:7b67:fc::/62             link#4                        U           em3
2002:592:7b67:fc:215:17ff:febc:ffc2 link#4                        UHS         lo0
fe80::ca0e:14ff:fe8d:6b79         fe80::ca0e:14ff:fe8d:6b79%re0 UGHS        re0
fe80::%em3/64                     link#4                        U           em3
fe80::1:1%em3                     link#4                        UHS         lo0
fe80::%re0/64                     link#5                        U           re0
fe80::6e62:6dff:fe3d:4ace%re0     link#5                        UHS         lo0
fe80::%lo0/64                     link#9                        U           lo0
fe80::1%lo0                       link#9                        UHS         lo0
fe80::215:17ff:febc:ffc1%ovpns1   link#10                       UHS         lo0
ff01::%em3/32                     2002:592:7b67:fc:215:17ff:febc:ffc2 U           em3
ff01::%re0/32                     fe80::6e62:6dff:fe3d:4ace%re0 U           re0
ff01::%lo0/32                     ::1                           U           lo0
ff01::%ovpns1/32                  fe80::215:17ff:febc:ffc1%ovpns1 U        ovpns1
ff02::%em3/32                     2002:592:7b67:fc:215:17ff:febc:ffc2 U           em3
ff02::%re0/32                     fe80::6e62:6dff:fe3d:4ace%re0 U           re0
ff02::%lo0/32                     ::1                           U           lo0
ff02::%ovpns1/32                  fe80::215:17ff:febc:ffc1%ovpns1 U        ovpns1

Die pfSense ist ja in dem LAN, auf das du zugreifen willst, das Default Gateway, oder? Die auf 1 endende IP würde darauf hindeuten. Die Hosts richtig konfiguriert?

Wie erwähnt, die System-Firewall am Zielhost ist auch immer ein heißer Tipp.
Ach ja, falls du eine zusätzliche OpenVPN-Instanz laufen hast, sollte das auch hier Erwähnung finden.

Ja, die Clients holen sich das per DHCP.
Die Windows Firewall ist aus.

Ach ja :

die DHCP Leases

10.10.6.26 	80:2a:a8:74:42:9c (Ubiquiti Networks) 	NanoBeam-M5-Slave 		2017/03/15 22:51:13 	2017/03/16 00:51:13 	online 	active 	
10.10.6.25 	68:72:51:07:55:57 (Ubiquiti Networks) 			2017/03/15 22:51:03 	2017/03/16 00:51:03 	online 	active 	
10.10.6.27 	80:2a:a8:a8:ba:1f (Ubiquiti Networks) 	NanoBeam-M5-Master 		2017/03/15 22:44:31 	2017/03/16 00:44:31 	online 	active 	
10.10.6.20 	68:72:51:06:55:16 (Ubiquiti Networks) 			2017/03/15 21:18:29 	2017/03/15 23:18:29 	online 	active

Mehr fällt mir nicht mehr ein :-)

chris

scheffe2804

Nachtrag:
Ich hab die Clients geprüft, die holen sich alle per DHCP ihre IP , Gateway stimmt.

Chris

scheffe2804

So,

habe es rausgefunden.
Man MUSS anscheinend eine Outbound NAT Regel setzen auf dem entsprechenden LAN Port (bei mir WLAN3).

Interface : WLAN3
Source : OpenVPN Netz
Address : Interface Adress

obwohl bei allen LAN Clients der PFSense der Gateway ist.

Chris

viragomann

Hallo,

die SNAT-Regel ist nur ein Workaround. Wenn du selbst aber der einzige VPN-Client bist, ist das absolut okay. Problem dabei ist nur, dass jeder Zugriff auf die LAN-Hosts mit der IP der pfSense erfolgt und dadurch VPN-Clients nicht unterschieden werden können.

Ansonsten ist, wenn die SNAT-Regel zum Erfolg führt, entweder die Firewall am Zielhost das Problem, oder die pfSense IP ist nicht als Gateway definiert und der Zielhost schickt seine Antworten an eine andere Adresse.
Beides wohl schon erwähnt.

Grüße

scheffe2804

Jaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaber

:-)

Die PFsense IST bei allen LAN CLients als Gateway definiert.
An dem VPN lClient, ist die Windows Firewall deaktiviert.

Beispiel der WLAN AP

Type: dhcp
Address: 10.10.6.25
Netmask: 255.255.255.0
Gateway: 10.10.6.1
DNS 1: 10.10.6.1
Connected: 6d 0h 27m 22s

und ca 130 Clients die gerade dranhängen :-)

Gruß Chris

JeGr

Dann stimmt an der Stelle was anderes nicht. Virago hat da schon recht, dein SNAT ist nicht die Lösung, sondern ein Workaround. Wäre dein VPN korrekt eingerichtet und würden BEIDE Seiten ordentlich routen, wäre das NATting unnötig, weil alle Stellen wissen wo die Pakete hinsollen. Da du nichts schreibst, wie das OpenVPN konfiguriert ist, kann man da schlecht was zu sagen. Evtl. falscher Modus, keine Rückroute, etc.

viragomann

@scheffe2804:

An dem VPN lClient, ist die Windows Firewall deaktiviert.

Es geht um die Firewall am Zielhost!

Bspw. die Windows-Firewall blockiert standardmäßig Zugriffe von einem fremden (nicht am Host selbst definierten) Subnetz. Und die Quell-IP wäre ohne NAT eine aus dem VPN-Tunnel, also eine, die der Host nicht kennt.

scheffe2804

Es geht um die Firewall am Zielhost!

Bspw. die Windows-Firewall blockiert standardmäßig Zugriffe von einem fremden (nicht am Host selbst definierten) Subnetz. Und die Quell-IP wäre ohne NAT eine aus dem VPN-Tunnel, also eine, die der Host nicht kennt.

Mit Zielhost meinste du den PFSense oder die clients?
An den Clients, in dem Fall, 2x5 Ghz + 1 x 2,4 Ghz Access Points .. sind die Firewalls deaktiviert .

Versteht mich bitte nicht falsch, ich denke auch, dass da was nicht stimmt.

Ich liefere nun mal die openvpn confs nach

dev ovpns1
verb 3
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 192.168.181.23
tls-server
server 192.168.111.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user TG9jYWwgRGF0YWJhc2U= false server1 1194" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'WLangateRathaus' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 10.10.6.0 255.255.255.0"
duplicate-cn
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server1.tls-auth 0
persist-remote-ip
float
topology subnet
push "route 10.10.6.0 255.255.255.0"

client conf vom Windows Rechner

dev tun
persist-tun
persist-key
float
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
#remote 192.168.181.23 1194 udp 
remote blah.myfritz.net 1194 udp 
verify-x509-name "WLangateRathaus" name
auth-user-pass
pkcs12 wlangate-udp-1194-scheffe.p12
tls-auth wlangate-udp-1194-scheffe-tls.key 1
ns-cert-type server

viragomann

Mit Zielhost meinte ich das Gerät hinter der pfSense. Das, welches du vom VPN-Client aus erreichen möchtest.
Als Client hätte ich eben letzteren verstanden.

An den OpenVPN Einstellungen kann es meiner Meinung nicht liegen. Das Routing vom Client ins LAN auf der anderen Seite des Tunnel funktioniert ja. Mehr ist bei diesem Problem auf einem Access Server nicht relevant.

Das Packet Capture am OpenVPN Interface zeigt, wie du auch festgestellt hast, nur Antworten der pfSense selbst, während du auch andere Geräte im LAN pingst.

Der VPNrechner pingt, PFsense antwortet brav.
Aber keine Spur von den Pings zu den anderen Rechnern!?

Wenn du das untersuchen möchtest, mach ein Capture am LAN-Interface (ohne Details). Das zeigt, ob die Pakete überhaupt an der pfSense ankommen. Ich vermute mal, nein.

Am WAN pingt die pfSense das eingestellte Gateway (dpinger), allerdings sollten da schon Antworten von der FB kommen, ansonsten wird das GW als offline angezeigt.

Auch interessant wäre die Routingtabelle (route, route print) vom Zielhost und ggf. ein TCP Dump an dessen Schnittstelle.