14
Kein IPv6 ping6 von LAN nach WAN mit pfSense möglich
Hallo zusammen,
ich habe eine aktuelle pfSense (2.3.4-RELEASE-p1) Installation auf einem ESXi.
LAN seitig hat der Router folgende Adressen:
v4: 192.168.31.1/24 and
v6: 2a02:xxxx:yyyy:c910::1234/64
WAN seitig hat der Router folgende Adressen:
v4: 10.20.20.32/16 and
v6: 2a02:xxxx:yyyy:c900::1234/64
Das WAN ist bei mir eigentlich ein 10.0.0.0/8 Firmennetz. Von dort geht es über einen weiteren Router ins Internet.
Public v4: 24.x.y.z and
Public: v6: 2a02:xxxx:yyyy:c900/56
Private v4: 10.20.2.254
Private v6: fe80::/10 (nur link-local address)
Im LAN habe ich einen Host 1 mit IPv6: 2a02:xxxx:yyyy:c910::100.
Im firmeninternen (quasi) WAN habe ich einen weiteren Host 2 mit IPv6: 2a02:xxxx:yyyy:c900::100.
Was ich machen möchte ist ein ping6 aus dem LAN ins firmeninterne WAN o. auch raus ins Internet.
Das ich für die beiden Host unique-global Adressen mit "einfacher" Interface ID vergebe habe hat seinen Grund darin, dass ich bis dato nicht durchdringend verstanden habe, wann und wie der Router entscheidet, Traffic passieren zu lassen. Link-local fe80::/10 werden nie geroutet, unique-local fc00/7, fd00/8 und site-local Adressen können geroutet werden, blos nicht ins Internet.
Folgende ping's gehe bei mir.
Inside LAN:
ping -6 2a02:xxxx:yyyy:c910::100 - works, Host 1
ping -6 2a02:xxxx:yyyy:c910::1234 - works, GW-LAN
ping -6 2a02:xxxx:yyyy:c900::1234 - works, GW-WAN
ping -6 2a02:xxxx:yyyy:c900::100 - does not work!!!, from Host1 inside LAN to Host 2 inside WAN
Inside Company WAN:
ping -6 2a02:xxxx:yyyy:c900::100 - works, Host 2
ping -6 2a02:xxxx:yyyy:c900::1234 - works
ping -6 2a02:xxxx:yyyy:c910::1234 - works
ping -6 2a02:xxxx:yyyy:c910::100 - works too!!!, from Host2 inside WAN to Host 1 inside LAN
Was aber nicht geht ist der ping 6 aus dem LAN von Host 1 nach Host 2 ins WAN und natürlich somit auch keinen Host im Internet (wie beispielhaft Google's DNS).
ping -4 8.8.8.8 geht zwar
ping -6 2001:4860:4860::8888 geht aber nicht
Im Router habe ich bereits zusätzlich unter Firewall/Rules/LAN eingestellt:
Protocol: IPv6 ICMP any
Source: *
Port: *
Destination: *
Port: *
Gateway:: *
Queue: none
Obiges für Firewall/Rules/WAN ebenfalls, da ja der Echo Request ein Echo Reply zur Folge hat. Unter Interfaces/LAN(WAN)/Reserved Networks sind die Tickboxen zu "Block private networks", "Block bogon networks" NICHT getickt.
Ich habe zusätzlich mittel pathping und tracert festgestellt, dass beim ping das Gateway nicht gescheit gefunden wird. Daher habe ich (vorerst zu Testzwecken) eine statische Route gesetzt:
Host 1 (im c910er Netz): Prefix: 2a02:xxxx:yyyy:c900::/64 Gateway: 2a02:xxxx:yyyy:c910::1234
Host 2 (im c900er Netz): Prefix: 2a02:xxxx:yyyy:c910::/64 Gateway: 2a02:xxxx:yyyy:c900::1234
Trotzdem, immer noch kein ping -6 aus dem LAN ins WAN.
Was kann ich noch tun?
Vielen Dank im vorraus....
ich habe eine aktuelle pfSense (2.3.4-RELEASE-p1) Installation auf einem ESXi.
LAN seitig hat der Router folgende Adressen:
v4: 192.168.31.1/24 and
v6: 2a02:xxxx:yyyy:c910::1234/64
WAN seitig hat der Router folgende Adressen:
v4: 10.20.20.32/16 and
v6: 2a02:xxxx:yyyy:c900::1234/64
Das WAN ist bei mir eigentlich ein 10.0.0.0/8 Firmennetz. Von dort geht es über einen weiteren Router ins Internet.
Public v4: 24.x.y.z and
Public: v6: 2a02:xxxx:yyyy:c900/56
Private v4: 10.20.2.254
Private v6: fe80::/10 (nur link-local address)
Im LAN habe ich einen Host 1 mit IPv6: 2a02:xxxx:yyyy:c910::100.
Im firmeninternen (quasi) WAN habe ich einen weiteren Host 2 mit IPv6: 2a02:xxxx:yyyy:c900::100.
Was ich machen möchte ist ein ping6 aus dem LAN ins firmeninterne WAN o. auch raus ins Internet.
Das ich für die beiden Host unique-global Adressen mit "einfacher" Interface ID vergebe habe hat seinen Grund darin, dass ich bis dato nicht durchdringend verstanden habe, wann und wie der Router entscheidet, Traffic passieren zu lassen. Link-local fe80::/10 werden nie geroutet, unique-local fc00/7, fd00/8 und site-local Adressen können geroutet werden, blos nicht ins Internet.
Folgende ping's gehe bei mir.
Inside LAN:
ping -6 2a02:xxxx:yyyy:c910::100 - works, Host 1
ping -6 2a02:xxxx:yyyy:c910::1234 - works, GW-LAN
ping -6 2a02:xxxx:yyyy:c900::1234 - works, GW-WAN
ping -6 2a02:xxxx:yyyy:c900::100 - does not work!!!, from Host1 inside LAN to Host 2 inside WAN
Inside Company WAN:
ping -6 2a02:xxxx:yyyy:c900::100 - works, Host 2
ping -6 2a02:xxxx:yyyy:c900::1234 - works
ping -6 2a02:xxxx:yyyy:c910::1234 - works
ping -6 2a02:xxxx:yyyy:c910::100 - works too!!!, from Host2 inside WAN to Host 1 inside LAN
Was aber nicht geht ist der ping 6 aus dem LAN von Host 1 nach Host 2 ins WAN und natürlich somit auch keinen Host im Internet (wie beispielhaft Google's DNS).
ping -4 8.8.8.8 geht zwar
ping -6 2001:4860:4860::8888 geht aber nicht
Im Router habe ich bereits zusätzlich unter Firewall/Rules/LAN eingestellt:
Protocol: IPv6 ICMP any
Source: *
Port: *
Destination: *
Port: *
Gateway:: *
Queue: none
Obiges für Firewall/Rules/WAN ebenfalls, da ja der Echo Request ein Echo Reply zur Folge hat. Unter Interfaces/LAN(WAN)/Reserved Networks sind die Tickboxen zu "Block private networks", "Block bogon networks" NICHT getickt.
Ich habe zusätzlich mittel pathping und tracert festgestellt, dass beim ping das Gateway nicht gescheit gefunden wird. Daher habe ich (vorerst zu Testzwecken) eine statische Route gesetzt:
Host 1 (im c910er Netz): Prefix: 2a02:xxxx:yyyy:c900::/64 Gateway: 2a02:xxxx:yyyy:c910::1234
Host 2 (im c900er Netz): Prefix: 2a02:xxxx:yyyy:c910::/64 Gateway: 2a02:xxxx:yyyy:c900::1234
Trotzdem, immer noch kein ping -6 aus dem LAN ins WAN.
Was kann ich noch tun?
Vielen Dank im vorraus....
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 378506
Url: https://administrator.de/contentid/378506
Printed on: April 19, 2024 at 12:04 o'clock
14 Comments
Latest comment
Liest man sich das alles durch wird der vermutliche Grund schnell klar.
Erstmal erkennt man das du ziemlich betriebsblind bist und nicht den gesamten Weg eines ICMPv6 Paketes betrachtest und vermutlich auch nicht bedenkst das bei v6 kein NAT in der FW gemacht wird.
Desweiteren ist die "zusätzliche" Route am LAN Port ja Quatsch, denn dort werkelt vermutlich ja eh die Default Route die so oder so IP seitig ALLES nach draußen zulässt.
Mal ganz abgesehen von dem ebenso falschen Source: any. Ein Sicherheitsfehler, denn hier gibt man logischerweise immer das IP Netz der Absenderadresse an. Aber egal...
Knackpunkt ist hier der WAN Port !
Den hast du nämlich vermutlich gar nicht auf dem Radar ! Kann das sein ?
Inbound am WAN blockt die FW hier natürlich ALLES. Du musst also Traffic egal welcher Art ins lokale v6 LAN explizit zulassen.
Dein ICMPv6 Echo Request Paket aus dem lokalen LAN kommt also vermutlich am Zielhost egal wo an, dessen Reply Paket bleibt aber am WAN Port ohne eine Regel hängen.
Hier brauchst du also am WAN Port eine inbound Rule mit:
Protocol: IPv6 ICMP
Source: *
Destination: network 2a02:xxxx:yyyy:c910::
Das lässt dann Antwort ICMPv6 Pakete von egal welcher Source IP auf dein lokales LAN zu und sollte dein Problem sofort fixen.
Wenn nicht, und deine Testgeräte Winblows Rechner sind, dann blockt Windows bekanntlich per Default ICMP sowohl in der v4 als auch v6 in der lokalen Windows Firewall.
Das sollte man dann natürlich auch tunlichst erlauben damit es klappt:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Desweiterin hilfreich ist wenn du mit Wireshark oder tcpdump grundsätzlich erstmal prüfst ob die ICMPv6 Pakete auch am Zielhost ankommen. Könnte ja sein das du wirklich noch einen anderen Kincken in der LAN Port Rule hast.
Erstmal erkennt man das du ziemlich betriebsblind bist und nicht den gesamten Weg eines ICMPv6 Paketes betrachtest und vermutlich auch nicht bedenkst das bei v6 kein NAT in der FW gemacht wird.
Desweiteren ist die "zusätzliche" Route am LAN Port ja Quatsch, denn dort werkelt vermutlich ja eh die Default Route die so oder so IP seitig ALLES nach draußen zulässt.
Mal ganz abgesehen von dem ebenso falschen Source: any. Ein Sicherheitsfehler, denn hier gibt man logischerweise immer das IP Netz der Absenderadresse an. Aber egal...
Knackpunkt ist hier der WAN Port !
Den hast du nämlich vermutlich gar nicht auf dem Radar ! Kann das sein ?
Inbound am WAN blockt die FW hier natürlich ALLES. Du musst also Traffic egal welcher Art ins lokale v6 LAN explizit zulassen.
Dein ICMPv6 Echo Request Paket aus dem lokalen LAN kommt also vermutlich am Zielhost egal wo an, dessen Reply Paket bleibt aber am WAN Port ohne eine Regel hängen.
Hier brauchst du also am WAN Port eine inbound Rule mit:
Protocol: IPv6 ICMP
Source: *
Destination: network 2a02:xxxx:yyyy:c910::
Das lässt dann Antwort ICMPv6 Pakete von egal welcher Source IP auf dein lokales LAN zu und sollte dein Problem sofort fixen.
Wenn nicht, und deine Testgeräte Winblows Rechner sind, dann blockt Windows bekanntlich per Default ICMP sowohl in der v4 als auch v6 in der lokalen Windows Firewall.
Das sollte man dann natürlich auch tunlichst erlauben damit es klappt:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Desweiterin hilfreich ist wenn du mit Wireshark oder tcpdump grundsätzlich erstmal prüfst ob die ICMPv6 Pakete auch am Zielhost ankommen. Könnte ja sein das du wirklich noch einen anderen Kincken in der LAN Port Rule hast.
Vielen Dank erstmal für Deine schnelle Antwort. Werde Deine Punkte durchgehen und überprüfen.
Das Ganze ist nur zu Testzwecken da; absolut kein produktiver Einsatz in diese Konstellation.
Die ICMPv6 Regeln LAN- und WAN-seitig habe ich nur angelegt, damit der Router sich aus LAN und WAN pingen lässt. (Nur zu Testzwecken)
Dazu ist natürlich kein "any" notwendig; nur Echo Request (ja noch nicht mal Echo Reply). Analog natürlich auch "Source: *" Trage ich keine solche ICMP Regeln ein, lässt sich der Router weder v4 noch v6 pingen.
Um mich dem Problem aber als Neuling weiter zu nähern bin ich nach dem Ausschlußprinzip vorgegengen. Den Strick enger ziehen kann ich später immer.
Das mit dem WAN Port verstehe ich (jetzt) so noch nicht. ICMP kennt keine Ports und bei mir geht der ping6 von WAN nach LAN durch, aber nicht von LAN nach WAN! Ersteres ist eher verwunderlich...
Werde auch Wireshark und tcpdump benutzten; dachte aber die ping Konfiguration ist Standardszenario mit Standardkonfiguration.
Meine beiden Host 1,2 sind Windows 10 Rechner (ja mein Gott, ist eben so und kann man sich nicht immer aussuchen). In beiden habe ich die Echo Request Regeln korrekt eingerichtet. Und wie bereits geschrieben lassen sich beide Host im jeweiligen Link auch v4 und v6 pingen.
Das Ganze ist nur zu Testzwecken da; absolut kein produktiver Einsatz in diese Konstellation.
Die ICMPv6 Regeln LAN- und WAN-seitig habe ich nur angelegt, damit der Router sich aus LAN und WAN pingen lässt. (Nur zu Testzwecken)
Dazu ist natürlich kein "any" notwendig; nur Echo Request (ja noch nicht mal Echo Reply). Analog natürlich auch "Source: *" Trage ich keine solche ICMP Regeln ein, lässt sich der Router weder v4 noch v6 pingen.
Um mich dem Problem aber als Neuling weiter zu nähern bin ich nach dem Ausschlußprinzip vorgegengen. Den Strick enger ziehen kann ich später immer.
Das mit dem WAN Port verstehe ich (jetzt) so noch nicht. ICMP kennt keine Ports und bei mir geht der ping6 von WAN nach LAN durch, aber nicht von LAN nach WAN! Ersteres ist eher verwunderlich...
Werde auch Wireshark und tcpdump benutzten; dachte aber die ping Konfiguration ist Standardszenario mit Standardkonfiguration.
Meine beiden Host 1,2 sind Windows 10 Rechner (ja mein Gott, ist eben so und kann man sich nicht immer aussuchen). In beiden habe ich die Echo Request Regeln korrekt eingerichtet. Und wie bereits geschrieben lassen sich beide Host im jeweiligen Link auch v4 und v6 pingen.
Die ICMPv6 Regeln LAN- und WAN-seitig habe ich nur angelegt, damit der Router sich aus LAN und WAN pingen lässt.
Das ist ja per se auch richtig.Nur von WAN Port regeln schreibst du ja oben kein Wort.
Dazu ist natürlich kein "any" notwendig; nur Echo Request (ja noch nicht mal Echo Reply)
Gut, zum Testen aber erstmal OK, denn da sollten dann so wenige "Fussfallen" wie möglich erstmal drin sein.Als Quercheck kannst du ja ein Scheunentor machen mit PASS any any.
Damit wird es ganz sicher gehen und dann weisst du auch ganz sicher das dein Fehler rein nur in einer falschen Firewall Regel verborgen ist !
bin ich nach dem Ausschlußprinzip vorgegengen. Den Strick enger ziehen kann ich später immer.
Ist ja auch der richtige Weg ! Nur....wo bleibt dein WAN Port ? Bedenke das IP Pakete auch immer einen Rückweg haben !Das mit dem WAN Port verstehe ich (jetzt) so noch nicht. ICMP kennt keine Ports
Sorry das hast du missverstanden !Gemeint war hier das physische WAN Interface der Firewall und die Regeln auf diesem Interface. Natürlich keine TCP oder UDP Ports, die es ja bekanntermaßen bei ICMP so oder so gar nicht gibt !
Da hab' ich mich gedrückt vermutlich etwas missverständlich aus. Sorry...
dachte aber die ping Konfiguration ist Standardszenario mit Standardkonfiguration.
Nicht denken sondern nachdenken.Auf einer Firewall ist nichts Standard ! Dort ist wie immer alles grundsätzlich verboten was nicht explizit erlaubt ist !!
und kann man sich nicht immer aussuchen
Eigentlich schon... Man hat wie immer im Leben die freie Wahl. MS Knecht oder Freiheit. Du hast dich halt für ersteres entschieden und das respektieren wir natürlich auch hier.Es gibt ja auch noch Raspberry Pis (übrigens perfekt zum Testen !!) und Linux und Apple Mac.
Aber egal...das ist ja auch nicht dein grundlegendes Problem, das sind die (falschen) Interface FW Regeln.
Das bekommen wir aber ganz sicher gefixt.
Für IPv6 ist das übrigens ein sehr guter Leitfaden:
https://danrl.com/projects/ipv6-workshop/
Hallo nochmal,
sorry, dass ich mich da bisschen zu lax ausgedrückt habe. Ich bin kein IT Administrator - wollte dieses Forum hier aber auch nicht mißbrauchen. Hab' bis dato nur Firewalls gekannt für die eine Checkbox beispielhaft ala "Allow Ping Request" zu klicken ausreichte, um den Ping zu ermöglichen.
Ich schrieb:
"Im Router habe ich bereits zusätzlich unter Firewall/Rules/LAN eingestellt:
Obiges für Firewall/Rules/WAN ebenfalls, da ja der Echo Request ein Echo Reply zur Folge hat."
Das ist vielleicht in der Masse an Text untergegangen.
Die Wahl von Windows hat natürlich einen tieferen Hintergrund; diese externe Anforderung kann ich aber nicht blockieren.
Vielen Dank auch für den Literaturhinweis und ich check' erstmal die einzelnen Punkte erneut durch.
sorry, dass ich mich da bisschen zu lax ausgedrückt habe. Ich bin kein IT Administrator - wollte dieses Forum hier aber auch nicht mißbrauchen. Hab' bis dato nur Firewalls gekannt für die eine Checkbox beispielhaft ala "Allow Ping Request" zu klicken ausreichte, um den Ping zu ermöglichen.
Ich schrieb:
"Im Router habe ich bereits zusätzlich unter Firewall/Rules/LAN eingestellt:
Obiges für Firewall/Rules/WAN ebenfalls, da ja der Echo Request ein Echo Reply zur Folge hat."
Das ist vielleicht in der Masse an Text untergegangen.
Die Wahl von Windows hat natürlich einen tieferen Hintergrund; diese externe Anforderung kann ich aber nicht blockieren.
Vielen Dank auch für den Literaturhinweis und ich check' erstmal die einzelnen Punkte erneut durch.
Ein Screenshot der Rules kann da jede Missverständnisse vermeiden
Fakt ist aber auch das du sehr wahrscheinlich einen Fehler in den v6 Rules hast.
Versuch mal die das Scheunentor. Kurzfristig kann man das machen. Wenns damit geht hast du Sicherheit das wirklich was faul ist an deinem Ruleset.
Bedenke dort immer die zwei allerwichtigsten Regeln:
Klicki Bunti ist eben noch nicht alles
Fakt ist aber auch das du sehr wahrscheinlich einen Fehler in den v6 Rules hast.
Versuch mal die das Scheunentor. Kurzfristig kann man das machen. Wenns damit geht hast du Sicherheit das wirklich was faul ist an deinem Ruleset.
Bedenke dort immer die zwei allerwichtigsten Regeln:
- Regeln greifen immer nur INBOUND, also alles was vom Draht in die FW geht
- "First match wins !" Also der erste positive Hit in den Regeln bewirkt das nachfolgende NICHT mehr abgearbeitet werden !
Klicki Bunti ist eben noch nicht alles
Hallo aqui,
noch konnte ich von gestern auf heute viel machen; ist nicht mein Tagesgeschäft - deshalb. Ein paar Illustrationen habe ich zwischenzeitlich aber gemacht.
Gem. 1ter Grafik kann ich pingen:
- ping 4 von (1) nach (2)
- ping 4 von (1) nach (3)
- ping 4 von (1) nach (4)
- ping 6 von (1) nach (2)
- ping 6 von (1) nach (3)
- ping 6 von (1) nach (4) --- geht nicht !!!
- ping 4 von (4) nach (3)
- ping 4 von (4) nach (2)
- ping 4 von (4) nach (1)
- ping 6 von (4) nach (3)
- ping 6 von (4) nach (2)
- ping 6 von (4) nach (1) --- das geht nur, wenn ich in client1 eine statische Route hinzufüge via
- netsh interface ipv6 add route 2a02:xxxx:xxxx:c910::/64 "Ethernet (red, default)" 2a02:xxxx:xxxx:c900::1234
Durchaus möglich, dass ich momentan den Wald vor lauter Bäumen nicht sehe und erst mal Abstand nehmen muss...
noch konnte ich von gestern auf heute viel machen; ist nicht mein Tagesgeschäft - deshalb. Ein paar Illustrationen habe ich zwischenzeitlich aber gemacht.
Gem. 1ter Grafik kann ich pingen:
- ping 4 von (1) nach (2)
- ping 4 von (1) nach (3)
- ping 4 von (1) nach (4)
- ping 6 von (1) nach (2)
- ping 6 von (1) nach (3)
- ping 6 von (1) nach (4) --- geht nicht !!!
- ping 4 von (4) nach (3)
- ping 4 von (4) nach (2)
- ping 4 von (4) nach (1)
- ping 6 von (4) nach (3)
- ping 6 von (4) nach (2)
- ping 6 von (4) nach (1) --- das geht nur, wenn ich in client1 eine statische Route hinzufüge via
- netsh interface ipv6 add route 2a02:xxxx:xxxx:c910::/64 "Ethernet (red, default)" 2a02:xxxx:xxxx:c900::1234
Durchaus möglich, dass ich momentan den Wald vor lauter Bäumen nicht sehe und erst mal Abstand nehmen muss...
noch konnte ich von gestern auf heute viel machen; ist nicht mein Tagesgeschäft - deshalb.
Der Satz ist etwas verwirrend...?? Du konntest viel machen oder nicht viel machen ?!?das geht nur, wenn ich in client1 eine statische Route hinzufüge via
Eigentlich Blödsinn bei v6 aber zeigt das du ein Routing Problem im lokalen LAN Netz der pfSense hast wo dieser client1 ist.Kann es wohlmöglich sein das du v6 Route Advertisements am Switch filterst die diese Komponenten verbinden oder das ggf. auf der pfSense in den Rules deaktiviert hast ?? Das sit NDP
https://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol
Wie gesagt hier ggf. Testweise mal eine Scheunentor Regel aktivieren um mal zu sehen obs wirklich am Regelwerk liegt. Screenshot fehlt ja das wir erstmal nur raten können.
Das würde erklären das falsche oder keine v6 Routen in das interne Netz kommen und du dann diesen Unsinn mit der Route am Client frickeln musst.
Am besten mal einen Wireshark nehmen und checken.
Hier wäre natürlich die v6 Routing Tabelle des ws-client7 mal sehr spannend. Die entlockst du ihm mit einem route print.
Ebenso die v6 Routing Tabelle der pfSense (Diagnostics).
Sieht also eher nach einem v6 Routing Problem aus statt Firewall Problem....
Etwas verwirrend auch die Zeichnung.
Die FB hat am Internet Port einen /56er Prefix aber komischerweise dann keinen am lokalen LAN obwohl sie hier eigentlich einen bekommen müsste per Prefix Delegation.
Ebenso müsste sie dieses Subnetz dann weitergeben an das LAN Segment was ja dein WAN Koppelnetz ist.
Ist das jetzt ein Druckfehler in der Zeichnung. Zumal dort dann auch ein c900 Subnetz auftaucht was aber ja niemals mit dem am FB Internet Port identisch sein kann und darf. Ist jetzt blöd das da die Maske fehlt um das sicher sagen zu können...
meinte "nicht viel Zeit" 
sorry
siehe hier:
sorrysiehe hier:
OK, auf dem lokalen Interface der pfSense kommt das noch an aber geht von dort nicht mehr weiter.
Jetzt gilt es herauszufinden ob der v6 Ping am Host ws-client1 überhaupt ankommt oder schon in der pfSense hängen bleibt.
Oder... ob er ankommt aber die Rückantwort hängenbleibt.
Dazu sind folgende Dinge wichtig:
Mit den ToDos solltest du den bösen Buhmann schnell finden.
Jetzt gilt es herauszufinden ob der v6 Ping am Host ws-client1 überhaupt ankommt oder schon in der pfSense hängen bleibt.
Oder... ob er ankommt aber die Rückantwort hängenbleibt.
Dazu sind folgende Dinge wichtig:
- Routing Tabelle des Clients ws-client1 um hier zu checken das dort eine Route vorhanden ist ins c910er Subnetz via pfSense c900::1234 Interface
- Wireshark Trace am ws-client1 um zu sehen ob das Pingv6 Paket vom ws-client7 dort ankommt und ein Reply rausgeht
- Firewall Logg der pfSense (vor dem Ping Test löschen wegen der Übersichtlichkeit) um zu sehen ob sie irgendwo v6 ICMP Pakete blockt.
- Scheunentor Regel PASS any any testweise an LAN und WAN Port um zu sehen das es NICHT am Regelwerk liegt.
Mit den ToDos solltest du den bösen Buhmann schnell finden.
Ich schicke von client7 im LAN einen ping6 and den client1 im WAN. client7 verwendet in diesem Fall folgende temp. IPv6 Adresse.
Der Ping geht auch durch den pfSense Router, aber client1 antwortet nicht mit einem Reply ?
Das verstehe ich jetzt nicht, denn ich habe zusätzlich im WAN einen weiteren client2, der problemlos client1 anpingen kann.
Und Wireshark zeigt auch den entspr. Reply von client1 zurück an client2.
Warum antwortet client1 mit einem Reply wenn der ping von client2 kommt, aber nicht wenn der ping vom Router kommt ???
Der Ping geht auch durch den pfSense Router, aber client1 antwortet nicht mit einem Reply ?
Das verstehe ich jetzt nicht, denn ich habe zusätzlich im WAN einen weiteren client2, der problemlos client1 anpingen kann.
Und Wireshark zeigt auch den entspr. Reply von client1 zurück an client2.
Warum antwortet client1 mit einem Reply wenn der ping von client2 kommt, aber nicht wenn der ping vom Router kommt ???
Ich hab' jetzt in client1 eine Firewallregel hinzugefügt.
Jetzt klappt es mit dem ping6 von client7 nach client1. Einen analogen Eintrag für ICMPv4 habe ich im Regelwerk der Firewall allerdings nicht gefunden. Trotzdem hat ja der ping 4 von client 7 nach client 1 schon immer funktioniert.
Jetzt klappt es mit dem ping6 von client7 nach client1. Einen analogen Eintrag für ICMPv4 habe ich im Regelwerk der Firewall allerdings nicht gefunden. Trotzdem hat ja der ping 4 von client 7 nach client 1 schon immer funktioniert.
Wie immer das typische Winblows Problem !!
Wurde ja oben auch schon mehrfach gesagt aber wie immer übersehen oder überlesen...
Nimm bitte beim nächsten Test einen Raspberry Pi da passiert dieser Mist nicht und wir haben weniger Stress
Case closed !
Und bitte dann auch
How can I mark a post as solved?
nicht vergessen !
Wurde ja oben auch schon mehrfach gesagt aber wie immer übersehen oder überlesen...
Nimm bitte beim nächsten Test einen Raspberry Pi da passiert dieser Mist nicht und wir haben weniger Stress
Case closed !
Und bitte dann auch
How can I mark a post as solved?
nicht vergessen !
Ja mach' ich und vielen Dank für Deine Unterstützung, aqui.
Immer gerne wieder
