Messages

Ja, alles so wie du sagst. Ping geht auch die Ersten 120 Sekunden lang.

ABER
Ich bin jetzt auf GRE gewechselt und das funktioniert anstandslos. Keine Probleme derzeit.

SIT = GIF

Route64 bietet neben GIF auch Wireguard an.
Ev. Probier ich es mal damit.

Ich denke, nur das Problem liegt eher auf meiner Seite, weil es so aussieht, als ob der Kernel komplett aufhört, die Pakete zu verarbeiten. Ich sehe nach den 120 s nämlich nichts mehr, weder in den Logs noch sonst wo.

Ist das wirklich so speziell das keiner eine Antwort hat?

Bei mir war es so, dass KEA nicht laufen wollte, solange ISC auch nur auf einer Schnittstelle gelaufen ist.
Ich musste ISC wirklich komplett abdrehen, damit KEA angefangen hat, zu arbeiten.

Das hat meinen Plan, Schnittstelle für Schnittstelle langsam umzustellen, schön durcheinandergebracht ...

Hello,

I'm at my wit's end, and Copilot is just sending me around in circles. ^^

I have a PPPoE setup. My "Stone Age" provider (A1) doesn't offer IPv6 on my connection, so I set up a GIF tunnel with route64.
My problem
After rebooting the firewall, IPv6 works for ~120 seconds, then I only get timeouts.

What Copilot suggested and I implemented (without success):
Gateway monitoring disabled
Static route set to the end address of Route64. (Because I'm not using the actual tunnel address, but the also routed /56 subnet.)
An allow-all rule on the interface for the GIF tunnel
Checked the rule on the WAN interface for Protocol 41 ["Reply to" disabled] and set [Status Type] to "No State."
MTU settings and MSS as well.

As soon as my pings only throw timeouts. I don't see anything even in the packet capture.

Hallo,

Ich bin am ende mit meinem Latein und Copilot schickt mich auch nur noch im Kreis ^^.

Ich habe ein Setup mit PPPoE. Mein "Steinzeit"-Provider (A1) Bietet kein IPv6 auf meinem Anschluss also habe ich einen GIF Tunnel mit Rout64 eingerichtet.
Mein Problem
Nach einem Reboot der Firewall funktioniert IPv6 ~120 Sekunden lang dann bekomme ich nur noch timeouts.

Was Copilot mir vorgeschlagen hat und umgesetzt wurde (ohne Erfolg):
Gateway monitoring deaktiviert
Statische Route gesetzt zur Endadresse von Rout64 (Weil ich nicht die eigenliche Tunneladresse verwende sondern das ebenfalls geroutete /56 subnetz)
Eine Allow All Rule auf dem Interace für den GIF Tunnel
Bei der Regel auf dem Wan Interface ür Protocol 41 ["Antwort-an" deaktivieren] angehackt und [Status-Typ] auf "Kein Zustand" gestellt.
MTU alles mögliche und MSS auch.

Sobald meine Pings nur noch timeouts werfen. Sehe ich selbst bei der Paketaufzeichnung nichts.

I nailed down the problem to a dependency with the DHCP service. When giving out new leases. The DHCP service seams to restart UnboundDNS to register the server's name for DNS resolve. Sometimes this seems to fail.

The solution that would work best in my opinion is some UnboundDNS API that could register and unregister names on the fly so that service restarts are not needed.
Or not so elegant to solve the service restart problem.

Oh and if UnboundDNS fails the Intrusion Detection fails too.

The error I get for UnboundDNS if it fails is in the general system protocolls.

Code Select Expand

/usr/local/sbin/pluginctl: The command '/bin/kill -'TERM' '37665''(pid:/var/run/unbound.pid) returned exit code '1', the output was 'kill: 37665: No such process'
I do not see realy more than that.

The MAC should not change, I'm not seeing this on my XCP-NG systems. if it did I have one application that would fail because it is "licensed" against the MAC address.

On my lab system I've moved one win 10 eval all over the place and the mac (and dhcp) did not move.

Just to be complete. Here is the forum link where even the devs will tell you that MAC address will change if you do a VM restore or a vm copy operation or a vm move operation. https://xcp-ng.org/forum/topic/5535/preventing-new-network-detection-on-different-xcp-ng-hosts

Ich verstehe etwas nicht:
In meinem Subnetz DMZ habe ich eine Regel aktiv die jeglichen Netzwerkverkehr nach außen erlaubt.
Trotzdem sehe ich im log immer wieder Abgelehnte Pakete.

Sehr verwirrend ist allerdings das es nicht Konsistent ist. Hin und wieder werden Pakete angenommen und hin und wieder nicht.
Die Regel ist definiert als Eingehend
Protokoll: IPv4+6 *
Quelle: DMZ Netzwerk
Quellport, Ziel, Zielport Gateway Zeitplan: *

Keine Ahnung warum.

Nach einer Nacht voll Kaffee und herumprobieren habe ich es geschafft  ;D

Ich habe die Zusätzlichen Adressen als Virtuelle IPs angelegt und den Gateway den PPPoE ermittelt als Gateway eingetragen.

Ich kann die IPs von außen pingen und ein source ping von innen heraus funktioniert auch mit den IPs.
Eine Verbindung ist also da, wenn jetzt noch etwas nicht funktioniert kann es nur an den NATs liegen aber die habe ich jetzt noch nicht ausprobiert und dazu bin ich jetzt auch zu müde.
Ich könnte auch schwören ich hab genau dieses Setup schon zig mal versucht ohne Erfolg.

Einzig eines ist mir eingefallen. Der Gateway der von PPPoE gemeldet wird. Ich weiß nicht ob dieser immer der selbe ist oder ob der ev. wechseln könnte. Gibt es eine Möglichkeit der Virtuellen IP zu sagen das sie immer den eingerichteten Gateway aus System->Gateways zu nehmen.
Den Namen kann man leider nicht angeben da eine IP Adresse erwartet wird.

Hallo,

Ich bins wieder mit einem ganz spezifischen Problem.
Ich sitze hier in Österreich hinter einem A1 Business Internetanschluss.
Technisch ist das ganze so aufgebaut das die Leitung zu mir in Haus kommt.
Dort ist ein Splitter von dem das Internet dann zum A1 Router geht, der das dann im Haus verteilt.
Da ich den A1 Router nicht mag und ich auch keine IP Adressen verschwenden will habe ich den A1 Router kurzerhand abgebaut und statt dessen eine OPNsense angehängt.
Dann habe ich PPPoE konfiguriert was auch einwandfrei funktioniert. Die OPNsense wählt sich ein bekommt eine IP und ich habe internet.

Die IP die ich bekommen ist a.b.c.d/32 was ok ist.
Das ist auch die 1. IP-Adresse laut provider. Mit der kann ich mich ins Internet verbinden.
OPNSense meldet mir dann auch eine GatewayIP die per pppoe bezogen wird, funktioniert alles fein.

ABER

Ich habe als Zusatzpaket noch weitere IP-Adressen w.x.y.z/29.
Egal was ich versuche ich bekomme diese IP-Adressen nicht zum laufen.
Ich habe schon Virtuelle IPs versucht.
Ich habe 1:1 NATs mit meinem TestPC versucht
Ich habe ausgehendes NAT mit meinem Internen Netzwerk versucht.
Aber wenn ich eine myip abfrage mache. Zeigt er entweder meine a.b.c.d IP an oder der Internetzugang geht gar nicht.
Das ganze ist mir deshalb wichtig weil ich mehrere VLANs betreibe.
VLAN 1: Soll genattet werden über a.b.c.d -> Funktioniert soweit
VLAN 2: Soll genattet werden über w.x.y.z1
VLAN 2 Server1: Soll 1:1 genattet werden über w.x.y.z2
Da ich mir sicher bin das der Fehler bei mir liegt wollte ich wissen, ob jemand ein ähnliches Setup hat und weiß, wie man das löst.

1. Das ist meine Heimfirewall und meine Spielwiese. Also nichts mit Produktiv  :P
2. Weil OPNsense ausdrücklich ISC als deprecated eingestuft hat.
3. Ich habe mir gedacht OPNsense kenne ich noch nicht und wenn ich es schon ausprobiere dann auch bitte die neuesten features.  8)

Ok, I found the solution.

I was too focused on Kea.

As I found out ISC is perfectly capable of linking the lease mapping with the DUID and not relying on the MAC Address.

So it looks like Kea is not capable of that yet, and ISC is the way to go. At least for the moment.

Ja, danke das wars.
Leider muss ich mich dazu von Kea verabschieden und wieder ISC benutzen.
Kea kann es nämlich im Moment noch nicht. Zumindest von der GUI aus