Unerklärlicher Packetloss nur bei IPv6
-
WAN und LAN reicht, Floating wäre ja nur für beide Interfaces zusammen. Nutze das ungern, weil Floating VOR Gruppen und Einzelinterfaces abgearbeitet wird und dadurch gern die Reihenfolgen durcheinander bringt ;) Aber ja, wenn überall offen, dann sollte das kein Thema sein.
-
OK dann werde ich das nun mal so austesten und berichten. Es irritiert mich nur dass es mit der VDSL Leitung sauber läuft und nur mit der Unitymedia Leitung die Probleme gibt. Weiterhin kann ich selbst wenn vom LAN nur noch Packetloss ist, von der pfSense selbst wenn ich WAN Interface wähle pingen. Wähle ich das LAN Interface, habe ich den exakt gleichen Paketloss.
-
-
Danke! Was genau bewirkt das und kann das Nachteile haben?
Wie es scheint entsteht mein Problem sobald ich mein Failover Gateway bei IPv6 nutze. Lösche ich das Gateway und setze es nicht in den IPv6 Firewallregeln, habe ich seither keinen Packetloss mehr. Doch warum ist das nur bei der Unitymedia Leitung ein Problem und bei der Telekom nicht?
-
Nachdem die Dokumentation der Pfsense sehr ausführlich und genau ist (Sarkasmus aus) …. steht eh alles da. Kann mir schon Nebenwirkungen vorstellen, z.B. bei schrägen Angriffen. Aber einen Versuch ist es wert. Warum die zwei unterschiedlich sind, können dir nur die ISP beantworten. Allerdings müsste man langsam wirklich die gesamte FW Konfig durchschauen, ob da noch andere Punkte sind.
-
Also das hat leider keinen Unterschied gebracht. Ich kann es jedoch reproduzieren wenn ich das Failovergateway in die Rules setze oder nicht. Mit default läuft es! Doch wieso, wo ist der Haken?
Falls Du Teamviewer hast, könnte ich anbieten dass Du mal drüber schaust.
-
@mrsunfire Naja das Default Gateway ist das (einzelne), was gerade im System aktiv ist. Ggf. also das VDSL, nicht UM Gateway? Ansonsten ist das alles ziemlich verworren, wo das Problem herrühren könnte...
-
So, nachdem es nun seit gestern Abend mit dem default Gateway lief, fing plötzlich um 14:10 Uhr wieder der Paketloss an. An der Config habe ich nichts geändert.
Zudem erscheint in den Systemlogs seit heute Morgen 8 Uhr regelmäßig die Meldung:
"cannot forward src fe80:3::3138:bc66:96d5:ad08, dst 2a02:26f0:ef::5f65:4d21, nxt 6, rcvif igb2, outif igb0"Wieso? Was sagt mir das?
EDIT:
Ich habe nun explizit die pfSense als DNS Server in den Firewallregeln freigegeben, doch plötzlich kommt mein Ping nicht mehr ganz durch zu heise.de. Google.de läuft. Wie kann das sein?
EDIT2:
Es wird immer wilder. Jetzt kommt der Ping wieder durch, ist dafür jedoch durchweg 10ms höher?!
EDIT3:
OK, ich werde nun anders geroutet als zuvor, daher der höhere Ping. Doch wieso? Ich nutze noch immer die pfSense als DNS Resolver, nur diese Regel habe ich hinzugefügt:
-
@mrsunfire
Hör halt einfach auf mit dem halbgaren Unsinn. Schalte IPv6 entweder ganz ab oder hol dir einen He.net Tunnel, der kann dann auch zwischen den Gateways geswitched werden. -
Was ist daran halbgarer Unsinn? Ich habe natives IPv6 vom Provider mit /56 Prefix. Was will ich da mit einem Tunnelbroker hantieren?
-
@mrsunfire
Das hier: https://forum.netgate.com/topic/131644/mark-gateway-as-down-and-don-t-use-it
Das gleiche Problem mit unterschiedlichen Informationen in verschiedenen Threads zu diskutieren ist übrigends nicht zu empfehlen. -
Es geht dort nicht um das gleiche Problem. Das dort besprochene Problem bezieht sich auf Paketloss welcher durch Ingress im Kabelnetz entsteht und somit IPv4 sowie IPv6 sehr träge macht. Daher lasse ich auf die Telekomleitung umschalten. Diese kann ebenfalls Dualstack! Aber pfSense kann kein Failover mit dynamischen Prefixen, von daher nutze ich dort nur IPv4.
Mein Problem hier, betrifft rein IPv6 und dort nur der Traffic der aus dem LAN Interface kommt. Anderer IPv6 Traffic läuft sauber.
Siehe:
Von WAN
Von LAN
-
Interessant, wenn ich mich via IPsec auf die pfSense verbinde, ist der Paketloss weg!
Was bewirkt das also dass es dann geht?!
-
Kann hier nochmal jemand drüber schauen bitte? Vielleicht ist hier einfach der Wurm drin bei der Adressvergabe:
WAN:
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=6400bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6> ether 40:62:31:00:xx:xx hwaddr 40:62:31:00:xx:xx inet6 fe80::4262:31ff:fe00:3a5%igb0 prefixlen 64 scopeid 0x1 inet6 2a02:8071:800:0:xxxx:xxxx:9945:6ffe prefixlen 128 inet 46.223.xxx.xxx netmask 0xfffffc00 broadcast 255.255.255.255 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> media: Ethernet 1000baseT <full-duplex> status: active
LAN:
igb2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=6500bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6> ether 40:62:31:00:xx:xx hwaddr 40:62:31:00:xx:xx inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 2a02:8071:886:5200:4262:xxxx:xxxx:3a7 prefixlen 64 inet6 fe80::1:1%igb2 prefixlen 64 scopeid 0x3 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet 1000baseT <full-duplex> status: active
Von Extern kann ich auf die WAN IPv6 pingen ( 2a02:8071:800:0:xxxx:xxxx:9945:6ffe ). Die LAN IPv6 jedoch nicht, bzw. nur mit viel Paketloss ( 2a02:8071:886:5200:4262:xxxx:xxxx:3a7 ). Genauso verhält es sich mit den Clients, diese erreiche ich auch kaum. Die Clients jedoch können auch die WAN IP sauber pingen. Sprich auf dem WAN Interface wird nicht sauber geroutet, oder?
Regeln sind eigentlich alle offen. (ICMPv6 any any)
-
Ich hab das Problem gelöst! Musste jedoch das komplette Setup ändern. Nun fordere ich nur noch ein /56 Prefix an, keine IP mehr und nutze zum verteilen den DHCPv6 Server im LAN. Dadurch làuft es nun sauber.
Wieso Unitymedia hier komplett anders ist weiß ich jedoch nicht.