Kein Zugriff auf Synology über VPN

[connorxxl]

Hallo miteinander,

Ich habe hier ein Problem, das ich einfach nicht lösen kann... daher freue ich mich über Eure Hilfe.

Folgende Umgebung habe ich hier:
- pfSense 2.3.1p5 (auf pcengine APU2)
- Zyxel GS1910-24 (aktuelle Firmware)
- Synology DS-2415+ (DSM 6.0.1-7393 Update 1), LACP mit zwei Ports ins LAN (derzeit nicht aktiv)
(- Linksys/Cisco SLM2008 zum ausprobieren)

Also... Ich habe auf der pfSense sowohl IPSec VPN (Client IP Bereich 10.0.130.x) als auch OpenVPN (Client IP Range 10.0.3.x) eingerichtet. Und mit beiden VPN Systemen komme ich nicht auf meine Synology, ping geht nicht. Im internen Netz (10.0.1.x) komme ich ohne Probleme auf die Synology. 10.0.1.10 oder 10.0.1.55 lassen sich ohne Probleme über VPN pingen.

Einstellungen auf der pfSense:
- Regeln für IPSec und OpenVPN lassen alles durch.
- Keine Einschränkungen im LAN.

Einstellungen auf der Synology:
- Alle Sicherheitseinstellungen (Autoblock IP, Firewalls, etc.) sind ausgeschaltet (soweit ich das sehe).

Folgendes habe ich probiert:
- Ping über VPN auf andere Server im LAN, zum Beispiel 10.0.1.10 oder 10.0.1.55 funktioniert.
- LACP der Synology wieder abgeschaltet, kein Erfolg.
- Switch ausgetauscht (auf LinkSys), Problem bleibt.
- Separates Netz auf der pfSense konfiguriert (separate IP Range 10.0.200.x), Regeln auf pfsense komplett offen, kann über dieses Netz 10.0.1.10 oder 10.0.1.55 anpingen, aber nicht 10.0.1.40.

Wenn mir alle Ergebnisse anschaue, kann es eigentlich nur die Synology sein. Ich finde aber leider nichts, was den Zugriff von ausserhalb des LAN Bereichs (10.0.1.x) irgendwie einschränken würde.

Interessanterweise ging das früher mal. Ich habe seit ca. zwei Monaten Probleme, gefühlt seit ich das erste Mal LACP ausprobiert habe... DSM 6 habe ich erst später installiert. Mit Updates auf der pfSense bin ich mir nicht sicher...

Ich wäre schon froh, wenn ich irgendwas probieren könnte, und sehen, wo die Pings hängen oder welches System den Zugriff verweigert auf die Synology, bzw. warum die Synology den Zugriff von ausserhalb 10.0.1.x verweigert.

Bedanke mich im voraus für Eure Ideen und Hilfe!

Gruss,

Chris

 

[Fusion]

Denke das Problem leigt eher bei pfSense und der VPN config. Dass die drei Netze (lokal, VPN, remote) getrennte IP-Bereiche nutzen hast du ja denke ich nach deinen Angaben schon sichergestellt.
Die VPN Clients müssen jetzt aber auch eine Route gesetzt bekommen auf das lokale Netz. Sprich, wenn der Client z.B. in einem anderen LAN/WLAN unterwegs ist und sich ins VPN einwählt, weiß er erstmal nur vom remote Netz z.B: 192.168.1.x und vom Transfer-Netz 10.0.3.x. Damit er jetzt auch IPs im lokalen Netz 10.0.1.x und damit auch die DS erreichen kann braucht er eine Router dortin. Die ist entweder in der Client config einzutragen oder vom VPN server per push auszuliefern.
Gleichzeitig muss auch die DS wissen in welches Netz sie ihre Antworten schicken soll, weil sie ja erstmal keine Ahnung von dem VPN Netz hat. Ist das Gateway der Zyxel oder pfsense?

https://blog.remibergsma.com/2013/0...emote-network-using-openvpn-and-some-routing/

 

[connorxxl]

Hallo Fusion, erstmal vielen Dank, dass Du Dich durch meine Beschreibung gekämpft hast.
Ja, die verschiedenen Netze haben unterschiedliche IP-Bereiche.
Das mit den Routen stimmt prinzipiell. Ich kann aber durch die VPN Tunnel (OpenVPN, IPSec) andere Server in meinem LAN anpingen (10.0.1.10 oder 10.0.1.55), aber eben nicht meine Synology (10.0.1.40). Wenn die Routen nicht gesetzt wären, dann sollte ich die anderen Server auch nicht anpingen können, oder?
Gateway ist die pfSense. Zyxel nutze ich nur als Switch...

Danke...

 

[JudgeDredd]

Hallo connorxxl,

da Dein Eingangspost ja recht umfangreich ist, fasse ich kurz nochmal zusammen.

pfSense:
VPN: IPsec / Client Configuration / Virtual Address Pool:
10.0.130.0/24

DS:
10.0.1.40/24

pfSense Firewall: Rules (IPsec):

Einstellungen auf der Synology:
- Alle Sicherheitseinstellungen (Autoblock IP, Firewalls, etc.) sind ausgeschaltet (soweit ich das sehe).

Die FW der DS habe ich jetzt nicht im Kopf, auf jeden Fall darf für ein Ping das Protokoll ICMP nicht geblockt sein.
Zum testen, versichere Dich aber nochmal das alles auf Scheunentor steht.

Wenn der VPN Tunnel aufgebaut ist, dann pinge mal vom Client die DS an und VORHER machst Du auf der pfSense mal ein
Diagnostic/Packet Capture vom IPsec Interface und postet das Resultat mal hier.

Gruß,
Andreas

 

[connorxxl]

Hallo Andreas,

Deine Zusammenfassung ist korrekt. Hier der Packet Capture bei Ping auf 10.0.1.40 über IPSec (der ja nicht funktioniert):

16:12:48.780203 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.58922 > 10.0.1.1.80: tcp 0
16:12:48.815155 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.58922 > 10.0.1.1.80: tcp 0
16:12:48.816853 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.58922 > 10.0.1.1.80: tcp 0
16:12:48.818596 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.58922 > 10.0.1.1.80: tcp 0
16:12:51.086836 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 0, length 64
16:12:52.082681 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 1, length 64
16:12:53.087690 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 2, length 64
16:12:54.089015 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 3, length 64
16:12:55.096219 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 4, length 64
16:12:55.289094 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.15642 > 104.41.229.63.50001: UDP, length 25
16:12:55.290302 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.15642 > 40.113.11.102.50003: UDP, length 24
16:12:55.325093 (authentic,confidential): SPI 0x0827a1dd: IP 104.41.229.63.50001 > 10.0.130.1.15642: UDP, length 23
16:12:55.326655 (authentic,confidential): SPI 0x0827a1dd: IP 40.113.11.102.50003 > 10.0.130.1.15642: UDP, length 23
16:12:55.779561 (authentic,confidential): SPI 0x0827a1dd: IP 46.18.68.21.35761 > 10.0.130.1.15642: UDP, length 3
16:12:56.092612 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 5, length 64
16:12:56.187183 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.53155 > 10.0.1.1.53: UDP, length 32
16:12:57.098803 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 6, length 64
16:12:57.566918 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.15642 > 46.18.68.21.35761: UDP, length 3
16:12:57.586701 (authentic,confidential): SPI 0x0827a1dd: IP 46.18.68.21.35761 > 10.0.130.1.15642: UDP, length 46
16:12:58.100846 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 7, length 64
16:12:59.130456 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 8, length 64
16:13:00.109581 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 9, length 64
16:13:01.113604 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 10, length 64
16:13:04.424257 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.59298 > 10.0.1.1.53: UDP, length 33
16:13:05.538637 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.53840 > 10.0.1.1.53: UDP, length 29
16:13:05.540098 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.60036 > 10.0.1.1.53: UDP, length 32
16:13:05.974769 (authentic,confidential): SPI 0x0827a1dd: IP 46.18.68.21.35761 > 10.0.130.1.15642: UDP, length 3

Ich werde daraus nicht so schlau, muss ich zugeben...

Hier ein Ping über IPSec auf einen anderen Server (10.0.1.10), der Ping funktioniert:

16:14:28.590117 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.59104 > 10.0.1.1.80: tcp 0
16:14:28.593790 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.59104 > 10.0.1.1.80: tcp 0
16:14:28.595251 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.59104 > 10.0.1.1.80: tcp 0
16:14:28.627938 (authentic,confidential): SPI 0x0827a1dd: IP 162.125.34.129.443 > 10.0.130.1.58605: tcp 0
16:14:28.637162 (authentic,confidential): SPI 0x0827a1dd: IP 162.125.34.129.443 > 10.0.130.1.58605: tcp 0
16:14:29.222062 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.50873 > 10.0.1.1.53: UDP, length 33
16:14:29.223756 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.64768 > 10.0.1.1.53: UDP, length 29
16:14:29.225485 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.58315 > 10.0.1.1.53: UDP, length 33
16:14:30.223317 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.50873 > 10.0.1.1.53: UDP, length 33
16:14:30.227782 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.64768 > 10.0.1.1.53: UDP, length 29
16:14:30.230449 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.58315 > 10.0.1.1.53: UDP, length 33
16:14:30.410358 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 0, length 64
16:14:30.410739 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 0, length 64
16:14:30.496086 (authentic,confidential): SPI 0x0827a1dd: IP 46.18.68.21.35761 > 10.0.130.1.15642: UDP, length 3
16:14:31.415107 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 1, length 64
16:14:31.415449 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 1, length 64
16:14:32.416957 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 2, length 64
16:14:32.417302 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 2, length 64
16:14:32.705640 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.64668 > 10.0.1.1.53: UDP, length 45
16:14:33.306117 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.50873 > 10.0.1.1.53: UDP, length 33
16:14:33.307781 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.64768 > 10.0.1.1.53: UDP, length 29
16:14:33.309267 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.58315 > 10.0.1.1.53: UDP, length 33
16:14:33.420401 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 3, length 64
16:14:33.420754 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 3, length 64
16:14:34.426391 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 4, length 64
16:14:34.426787 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 4, length 64
16:14:35.459003 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 5, length 64
16:14:35.459268 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 5, length 64
16:14:36.433191 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 6, length 64
16:14:36.433544 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 6, length 64
16:14:37.438963 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 7, length 64
16:14:37.439336 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 7, length 64
16:14:38.461165 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 8, length 64
16:14:38.461466 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 8, length 64
16:14:39.439573 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 9, length 64
16:14:39.439903 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 9, length 64
16:14:40.446767 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 10, length 64
16:14:40.447137 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 10, length 64
16:14:40.685252 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.15642 > 46.18.68.21.35761: UDP, length 3
16:14:40.687222 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.15642 > 46.18.68.21.35761: UDP, length 44
16:14:42.309215 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.50873 > 10.0.1.1.53: UDP, length 33
16:14:42.311123 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.64768 > 10.0.1.1.53: UDP, length 29
16:14:42.312367 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1.58315 > 10.0.1.1.53: UDP, length 33

Vielen Dank für Deine Hilfe!

Gruss,

Christian

 

[JudgeDredd]

Ich werde daraus nicht so schlau, muss ich zugeben...

OK, also hier kann man erkennen, das der Ping auf die DS durch den Tunnel geroutet wird:

16:12:58.100846 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.40: ICMP echo request, id 37395, seq 7, length 64

Allerdings fehlt der reply von der DS.

Anders ist es beim Ping auf den anderen Server, wie man hier sehen kann:

16:14:32.416957 (authentic,confidential): SPI 0xc9dfc098: IP 10.0.130.1 > 10.0.1.10: ICMP echo request, id 40979, seq 2, length 64
16:14:32.417302 (authentic,confidential): SPI 0x0827a1dd: IP 10.0.1.10 > 10.0.130.1: ICMP echo reply, id 40979, seq 2, length 64

Damit wäre also klar, das es nicht am VPN Routing liegt.

Die nächsten Schritte wären also doch nochmal die Firewall(s) zu checken.
Wie schaut denn die Firewallkonfig der DS aus. Sicher das da nicht auf einem Interface keine Regeln eingetragen sind
und vielleicht "Wenn keine Regel zutrifft" dann verweigern steht ?

Um die Firewall der pfSense zu überprüfen, kannst Du mal bei der "alles erlauben"-Regel die option
"Log packets that are handled by this rule" aktivieren und Dir die Logs der pfSense ansehen.