LDAP/AD Connection von pfSense aus nicht möglich?!
-
Hallo,
als mehr oder weniger Neuankömmling bei pfSense, frage ich mich gerade, weshalb meine pfSense den AD-Controller nicht erreicht, der über IPsec mit der pfSense verbunden ist. Bzw. das Subnetz, in dem der ADC steht. Offensichtlich funktioniert es bei anderen, was also könnte bei mir in der Konfiguration fehlen?
Unten ein paar Screenshots:
- Bei der Phase2 werden alle Subnetze aktiviert und laufen offensichtlich.
- Lediglich LAN, DMZ und evtl. noch das OpenVPN-Gerät bekommen einen ping reply. Localhost und WAN erreichen die IP 10.65.20.11 nicht, aber auch nicht eine LAN-IP, 10.20.18.11 (z.B.).
Ich hätte jetzt angenommen, dass die pfSense zwischen all ihren bekannten Netzen routen kann/darf? Firewall Rules für IPsec, OpenVPN stehen aktuell auf any<>any. Im Firewall Log taucht auch nichts auf, was in Richtung 10.65.20.11 TCP389 gesperrt werden würde und ohne Logeintrag finde ich es schwierig, Fehler zu suchen.
Hat hier jemand Ideen?
Danke, Axel
-
Hi,
- Bei der Phase2 werden alle Subnetze aktiviert und laufen offensichtlich.
Zumindest die 3 die definiert sind sehen gut aus. Ich weiß nicht welche 3 das sind.
- Lediglich LAN, DMZ und evtl. noch das OpenVPN-Gerät bekommen einen ping reply. Localhost und WAN erreichen die IP 10.65.20.11 nicht, aber auch nicht eine LAN-IP, 10.20.18.11 (z.B.).
Ich vermute das /29 ist die DMZ und die anderen beiden sind LAN und VPN Netz? Ja dann sind das auch die 3 die dürfen.
Ich hätte jetzt angenommen, dass die pfSense zwischen all ihren bekannten Netzen routen kann/darf?
Routen tut sie, um "dürfen" geht es weniger.
Hat hier jemand Ideen?
Simpel: Auf der anderen Seite am VPN/IPSEC Tunnel lauschen und dann bspw. den "Select Container" Button in der UI noch ein paar Mal penetrieren. Sollte jedes Mal ein Paket auslösen. Das kann man im Normalfall auch sehen. Man kann auch im zweiten Fenster einen Packet Capture auf der pfSense laufen lassen auf dem IPSEC Interface, da sollten auch die Pakete zum AD/LDAP zeigen.
Das Problem wird eher sein, dass unklar ist, mit welcher IP die Sense zum AD spricht. Dadurch dass das IPSEC Interface keine IP bzw. kein Gateway hat - anders als ein OpenVPN Tunnel - ist unklar, mit welcher IP sie versucht zum LDAP zu kommen. Deshalb mal Capture machen und nachsehen, wahrscheinlich ist es eine Adresse die in keiner Phase 2 definiert ist, somit kein Routing, somit kein Empfang.
Gruß
-
Hallo JeGr,
richtig, pfSense-LAN 10.20.18.0/24, DMZ /29, OpenVPN 10.0.8.0/24 und das entfernte Subnetz der IPsec-Gegenstelle 10.65.20.0/22.
Habe auch schon daran gedacht, dass mir nicht klar ist, welche IP die pfSense nutzt, um mit dem ADC zu sprechen. Offensichtlich als Localhost oder mit der WAN-IP, da das ja auch die IPs sind, die keinen PING an das "IPsec-"Subnetz 10.65.20.0/22 senden können. Ohne einen Hinweis dazu ins LOG zu schreiben (alle Firewall-Regeln dbzgl. sollen ins Log schreiben, so ist es eingestellt.).Dein Vorschlag mit dem Packet Capture ist wohl unausweichlich.
Im Anhang den Routing Table:
wieso taucht hier das IPsec-Subnetz der Gegenstelle nicht auf? In anderen Firewalls habe ich die Netze immer in den Routing-Tables… pfSense verarbeitet das offensichtlich anders?
Ich hatte auch mal mit einer Static Route getestet, jedoch nur auf 127.0.0.1, was nichts gebracht hat, außer, dass das Subnetz dann in der Routing Tabelle auftauchte.Ciao
Axel
-
wieso taucht hier das IPsec-Subnetz der Gegenstelle nicht auf? In anderen Firewalls habe ich die Netze immer in den Routing-Tables… pfSense verarbeitet das offensichtlich anders?
siehe oben. FreeBSD / IPSEC nutzt kein echtes Interface und spannt kein Transfernetz wie OpenVPN. Daher kein Gateway und daher auch kein Routing Eintrag, da dafür das Gateway fehlen würde.
-
Ok, also eine Besonderheit von FreeBSD/IPSEC/pfSense, die mir so noch nicht bekannt war. Noch weniger ist mir dann bekannt, wie es dann funktioniert ;D
Also zumindest habe ich mit dem pfSense-Packet Capture nun sehen können, dass die pfSense mit ihrer "WAN Address" Richtung 10.65.20.11:389 sprechen möchte:
09:59:11.168777 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) xx.x.xxx.186.50050 > 10.65.20.11.389: Flags [s], cksum 0xbf3d (incorrect -> 0x94e0), seq 915543117, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 41280231 ecr 0], length 0 09:59:14.187234 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) xx.x.xxx.186.50050 > 10.65.20.11.389: Flags [s], cksum 0xbf3d (incorrect -> 0x8912), seq 915543117, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 41283253 ecr 0], length 0 09:59:29.194190 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) xx.x.xxx.186.58159 > 10.65.20.11.389: Flags [s], cksum 0xbf3d (incorrect -> 0xad36), seq 2841387800, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 41298254 ecr 0], length 0 09:59:32.206124 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) xx.x.xxx.186.58159 > 10.65.20.11.389: Flags [s], cksum 0xbf3d (incorrect -> 0xa16c), seq 2841387800, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 41301272 ecr 0], length 0 09:59:35.461912 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) xx.x.xxx.186.58159 > 10.65.20.11.389: Flags [s], cksum 0xbf3d (incorrect -> 0x94b5), seq 2841387800, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 41304527 ecr 0], length 0 09:59:38.661939 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) xx.x.xxx.186.58159 > 10.65.20.11.389: Flags [s], cksum 0xbf3d (incorrect -> 0x8835), seq 2841387800, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 41307727 ecr 0], length 0 09:59:41.861950 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) xx.x.xxx.186.58159 > 10.65.20.11.389: Flags [s], cksum 0xbf3d (incorrect -> 0x7bb5), seq 2841387800, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 41310927 ecr 0], length 0 09:59:45.062059 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) xx.x.xxx.186.58159 > 10.65.20.11.389: Flags [s], cksum 0xbf3d (incorrect -> 0x6f35), seq 2841387800, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 41314127 ecr 0], length 0 09:59:51.261908 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) xx.x.xxx.186.58159 > 10.65.20.11.389: Flags [s], cksum 0xbf3d (incorrect -> 0x56fd), seq 2841387800, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 41320327 ecr 0], length 0 Wenn dann also im IPsec-Tunnel am Ende eine Anfrage von xx.x.xxx.186 kommen sollte (was noch zu prüfen wäre), wird es dafür also keine Rückroute geben?! Kann ich der pfSense irgendwie sagen, dass sie dafür die LAN-IP 10.20.18.1 nutzen soll?[/s][/s][/s][/s][/s][/s][/s][/s][/s] -
Wenn dann also im IPsec-Tunnel am Ende eine Anfrage von xx.x.xxx.186 kommen sollte (was noch zu prüfen wäre), wird es dafür also keine Rückroute geben?!
Doch natürlich, aber da das eine WAN Adresse ist, wird die Gegenseite versuchen, die Antwort ins Internet ans WAN zu schicken - und nicht via VPN Tunnel zurück.
Dein Problem ist IPSEC bedingt dieses:
https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN -
Gepriesen sei dieser Link/diese Info. Danke JeGr! ;D
Nun funktioniert es und ich habe etwas dazu gelernt. Darauf wäre ich schlicht nicht gekommen, da es mir, wie gesagt, von anderen Firewalls her nicht bekannt war.
Danke!
Ciao
Axel :) -
:) freut mich
