Windows 10 - Open VPN - internes Netz [gelöst]
-
In der VPN Server Konf. hab ich 10.10.6.0/24 als IPv4 Local Network angegeben.
Trotz "Redirect gateway"??
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 lo0Ich habe Zweifel, das "netstat -a" diesen Output liefert.
Außerdem liefert er zu wenig Information. Interessanter wäre "netstat -nr".Die Windows Firewall ist aus.
Auf dem Zielhost? Das wäre eigentlich mein großer Verdacht in dem Fall.
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
-
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.1Nun 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 kernelDie 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 40Der 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 bytesNun 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 8OpenVPN
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 40em3 (WLAN3)
Keine ErgebnisseNun 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 kernelNetstat -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: KeineNet 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 ovpns1Die 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 activeMehr fällt mir nicht mehr ein :-)
chris
-
Nachtrag:
Ich hab die Clients geprüft, die holen sich alle per DHCP ihre IP , Gateway stimmt.Chris
-
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 Adressobwohl bei allen LAN Clients der PFSense der Gateway ist.
Chris
-
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
-
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 22sund ca 130 Clients die gerade dranhängen :-)
Gruß Chris
-
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.
-
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.
-
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 -
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.
