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



  • 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



  • @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



  • 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



  • 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 Adress

    obwohl 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 22s

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

    Gruß Chris


  • LAYER 8 Moderator

    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.



  • @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.



  • 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.


Log in to reply