Messages

[Disclaimer: "Mini" jumbo frames do not work with german Telekom and their reseller ISPs, so the best you can get is a 1492 byte MTU.]

...und so, wie es aussieht, ist das bei Telekom-DSL-Infrastruktur nicht der Fall, was im verlinkten Artikel auch deutlich steht:

Disclaimer: "Mini" jumbo frames do not work with german Telekom and their reseller ISPs, so the best you can get is a 1492 byte MTU.

Maybe your switch or the FreeBSD network driver gets VLAN layers wrong. One should never mix tagged and untagged networks on the same physical NIC with FreeBSD. If you can, try to separate both (V)LANs on different NICs as untagged and tag only one of them on your managed switch.

Yes, I see that, too.

Yes for the floating rules: 10/10 displayed now. No for the interface group with 16 rules, still 22 in the list when I select it. Also no for one of my interfaces with 1 rules, where 3 are listed.

As it turns out, the rules with "any" are also listed when any specific interface is selected, which can be argued as expected.... this probably explains the higher number for the other categories.

At least the displayed number of rules in each group does not match the number shown next to the group.

I had 10 floating rules, selecting them yields 10. 16 rules in an interface group, yielding 22, 1 on an interface, yielding 3.

So it seems that the actual filtering has different results than the count.

Please open a report on github and link it to here...

Ja, klar, genau wie O2 alles verkauft, was nicht bei drei auf dem Baum ist. VLAN 7 spricht aber für Telekom-Zugang.

Normalerweise ist 1&1 ja Reseller von der Telekom. Eigentlich habe ich noch nichts davon gehört, dass die MAC-Locking betreiben, aber wenn die Fritzbox funktioniert und die OpnSense nicht, könnte man:

a. versuchen, die MAC der Fritzbox zu klonen
b. eine Zeit warten, um die neue MAC zu akzeptieren (es gibt ISPs, die einen Wechsel erst nach 1-2h mitbekommen)
c. beim Support anrufen, um nachzufragen, ob die neue MAC freigeschaltet werden muss

[P.S.: Du nutzt offenbar Hyper-V - keine Ahnung, wie das dazwischenspuckt. Der Virtualisierungslayer kann ggf. Firewall-Regeln haben, die PPPoE-Pakete gar nicht erst durchlassen, was eine sehr gute Erklärung für das Verhalten wäre, falls sonst alles korrekt konfiguriert ist.]

Stelle sicher, dass die "Kette" stimmt:

WAN (=pppoe0) -> PPPOEVLAN (vlan0.7) -> "physisches Interface" (hn1?)

Das sieht dann unter Interfaces -> Assignments etwa so aus:

You cannot view this attachment.

Bei mir ist igc3 das physische Interface und igc3_vlan40 entspricht Deinem vlan0.7 (man kann mit den aktuellen OpnSense-Versionen so einen Namen wie igc3_vlan40 nicht mehr über die GUI anlegen, obwohl ich das viel klarer finde). Ich habe das auch namentlich als PPPOEVLAN zugewiesen, das ist aber m.W. nicht notwendig.

Die Reihenfolge zum Anlegen ist:

1. VLAN volan0.7 auf das physische Interface (hn1?) einrichten.
2. PPPoE mit dem VLAN vlan0.7 und den Zugangsdaten einrichten.
3. WAN auf pppoe0 zuweisen. Das ist notwendig, weil das WAN-Interface typischerweise schon eine NAT-Regel bekommt (kann aktuell schon anders sein).


P.S.: Du nutzt offenbar Hyper-V - keine Ahnung, wie das dazwischenspuckt. Der Virtualisierungslayer kann ggf. Firewall-Regeln haben, die PPPoE-Pakete gar nicht erst durchlassen, was eine sehr gute Erklärung für das Verhalten wäre, falls sonst alles korrekt konfiguriert ist.

Because ip66.dev is what the OP mentioned. IPinfo was thrown into the mix only after that.

As I said, I only though that the ASN columns were needed. In fact, they are not from the GeoIP data at all. It was all down to having to set the HTTP header if you want to coerce OpnSense to read a .csv.gz file like the one from IPinfo.

Even if it does use privacy extensions, it will most probably have an EUI-64-based management IPv6. I have never seen any client using privacy extensions with no management IP as well. As the name suggests: Those are extensions, which means those addresses are used "on top" of any other assigned IP for outbound connections only.

Thus, for addressability, you can always use the management EUI-64 IP. DNSmasq only makes use of that convention and it does not even handle the case when a DUID is used instead of the MAC.

If you have static prefixes, then you can guess what the IP will be, so you do not strictly need DNSmasq. If you have dynamic prefixes, you can at least guess the EUI-64 part (regardless of MAC or DUID) and use that for a dynamic DNS entry that is managed by OpnSense.

There is an existing cron job for doing exactly that, it is called "Renew DNS on stale Wireguard connections", you only have to enable it.

Matter-of-fact you need it because Wireguard does retries, but never resolves a given DNS name after it was started.

Was ist so schwierig daran, einen CSV-Export aus den ISC Reservierungen und danach einen CSV-Import in den Kea Reservierungen durchzuführen?

Aber bitte: https://homenetworkguy.com/how-to/migrate-from-isc-dhcp-to-dnsmasq-or-kea-dhcp-in-opnsense/

@Patrick: You probably misunderstood, @IPinfo is not with IP66...

There are tools to extract CSV or JSON data from MMDB files, which seem to be the only ones that IP66 offers, unlike Maxmind and IPinfo.

However, I was unable to extract all data, including ASN with those, and I got errors all over the place during import to OpnSense, so I wrote my own: https://github.com/meyergru/opnsense-ip66

Later, I found the main problem is that for IPinfo-style .gz files, you need to send a Content-Disposition HTTP header - if you fail to do that, the file will get misinterpreted as a ZIP file in Maxmind format (with multiple files contained in it).

The number of entries is approximately (all have IPv4 and IPv6):

1. IPinfo: 3900000
2. IP66: 1200000
3. Maxmind (Geoip Lite): 1100000

So IPinfo has the clear lead in terms of detail.

Wenn Du keine speziellen Anforderungen hast, kannst Du einfach ISC durch Kea DHCPv4 ersetzen und weiterhin RADVD für SLAAC nutzen.

Die festen Reservierungen kann man aus ISC per CSV-Export in Kea übernehmen.

Pardon me for my ignorance, but isn't all of that besides the point?

If indeed two devices in the same broadcast domain do have the same MAC for whatever reason, you will be out of luck anyway, because both will use the same ethernet header and that is independent of IPv4 with ARP or IPv6 with NDP.