"Recent posts
#21
German - Deutsch / Re: Eigener DNS bei einer IPv6...
Last post by n3 - Today at 04:33:50 PMSchlimm wenn es nicht die eine Lösung gibt ;-) Verstehe ich es grob richtig, dass aktuelle zwei Ansätze diskutiert werden. Der eine zielt möglichst auf IPv6 only ab und bindet IPv4 dort ein, wo nötig. Führt aber zu einer komplexeren Konfiguration.
Der andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.
Welche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?
Gibt es einen Favoriten für mein Szenario (der initiale Aufwand mal außen vor gelassen):
- HomeLab
- Feste/Dynamisch IP Adresse möglich
- Mehrere Interfaces (Consumer-Clients, Server, Kameras, Außennetzwerk)
- proxmox mit opnsense, homeassistant, nextcloud, AdGuard, etc.
- Consumer-Clients sollten von am besten nahtlos von Außen auf homeassistant, nextcloud zugreifen können
- nextcloud sollte aber auch für Dritte verfügbar sein
- Prio 1 Sicherheit, Prio 2 Stabilität und Prio 3 Maintenance
P.S. Hab mich geirrt. Die feste IP kostet 10€ und ab dem 7. Monat dann 23€/mtl.
Der andere Ansatz ist Dual-Stack, was vielleicht nicht optimal ist, jedoch einfacher zu konfigurieren/betreiben.
Welche Vorteile hat Ansatz 1 und welche Nachteile Ansatz 2?
Gibt es einen Favoriten für mein Szenario (der initiale Aufwand mal außen vor gelassen):
- HomeLab
- Feste/Dynamisch IP Adresse möglich
- Mehrere Interfaces (Consumer-Clients, Server, Kameras, Außennetzwerk)
- proxmox mit opnsense, homeassistant, nextcloud, AdGuard, etc.
- Consumer-Clients sollten von am besten nahtlos von Außen auf homeassistant, nextcloud zugreifen können
- nextcloud sollte aber auch für Dritte verfügbar sein
- Prio 1 Sicherheit, Prio 2 Stabilität und Prio 3 Maintenance
P.S. Hab mich geirrt. Die feste IP kostet 10€ und ab dem 7. Monat dann 23€/mtl.
#22
German - Deutsch / Re: Eigener DNS bei einer IPv6...
Last post by Zapad - Today at 04:27:28 PMBitte ein paar beispiele für IP6-only Clients?
Bitte keine wo man Dualstack manuell deaktiviert.
Mmn. gibs es nur IP4-Only clients, zb meine Reolink Cams....
und wenn man Dualstack sowieso hat, ist man frei intern alles zu benutzen was man will.
Bitte keine wo man Dualstack manuell deaktiviert.
Mmn. gibs es nur IP4-Only clients, zb meine Reolink Cams....
und wenn man Dualstack sowieso hat, ist man frei intern alles zu benutzen was man will.
#23
High availability / Re: CARP OS-FRR timeout after ...
Last post by Monviech (Cedrik) - Today at 04:24:11 PMI need the exact configd call that timed out.
Can you search for that in the ssh shell via:
after triggering that issue?
Can you search for that in the ssh shell via:
Code Select
opnsense-log configd
after triggering that issue?
#24
German - Deutsch / Umstellung auf IPsec Connetion...
Last post by osmom - Today at 04:18:52 PMIch habe bisher eine legacy IPsec Verbindung, wo sich die User auf Windows-Clients für die VPN Verbindung gegen einen Radius Server authentifizieren. Dieser Radius Server ist ein MS-NPS und holt seine User-Daten aus einem Active Directory.
Radius Server, User und Firerwall kennen und nutzen eine gemeinsamme CA. Die Firerwall hat ein gültiges Server-Certifikat und nutzt in der Phase 1 EAP-Radius und Key-Exchange V2.
Der User baut unter Benutzung seines Users aus dem Active Diretory: domain\Userkennung + Passwort die VPN-Verbindung mit den in Windows Integrierten VPN-Client auf. In Phase 2 wird bei der legacy Verbindung das ESP Protokoll genutzt.
Bei den neuen Connections wird ESP nicht mehr unterstüzt. Meine Konfiguration habe ich nach https://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html#method-1-shared-ip-pool-for-all-roadwarriors aufgebaut und auf die Radius angepasst wo es für mich logisch war.
Zur Authentifizierung nutze ich dabe EAP-Radius und EAP-MSCHAPv2.
Der Windowsclient kann sich mit der Connections Verbindung aber nicht authentifizieren und im Log habe ich Einträge das die halboffene Verbindung beendet wird.
Im Anhang noch ein par Screenshots von meinen Einstellungen. Sieht vieleicht wer, was ich falsch gemacht habe?
Radius Server, User und Firerwall kennen und nutzen eine gemeinsamme CA. Die Firerwall hat ein gültiges Server-Certifikat und nutzt in der Phase 1 EAP-Radius und Key-Exchange V2.
Der User baut unter Benutzung seines Users aus dem Active Diretory: domain\Userkennung + Passwort die VPN-Verbindung mit den in Windows Integrierten VPN-Client auf. In Phase 2 wird bei der legacy Verbindung das ESP Protokoll genutzt.
Bei den neuen Connections wird ESP nicht mehr unterstüzt. Meine Konfiguration habe ich nach https://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html#method-1-shared-ip-pool-for-all-roadwarriors aufgebaut und auf die Radius angepasst wo es für mich logisch war.
Zur Authentifizierung nutze ich dabe EAP-Radius und EAP-MSCHAPv2.
Der Windowsclient kann sich mit der Connections Verbindung aber nicht authentifizieren und im Log habe ich Einträge das die halboffene Verbindung beendet wird.
Im Anhang noch ein par Screenshots von meinen Einstellungen. Sieht vieleicht wer, was ich falsch gemacht habe?
#25
High availability / Re: CARP OS-FRR timeout after ...
Last post by rkam - Today at 04:08:24 PMI need the BGP; I only mentioned it because it had no effect with or without BGP. I was trying to narrow down the error that way.
How do we proceed from here, and will there be a solution?
How do we proceed from here, and will there be a solution?
#26
German - Deutsch / Re: Eigener DNS bei einer IPv6...
Last post by meyergru - Today at 03:35:20 PM@Maurice: Das hast Du aber einen ganz hübschen Stapel von Mechanismen beisammen, um "modern" zu sein. Bin gespannt auf das HOWTO dazu... ;-)
#27
German - Deutsch / Re: Eigener DNS bei einer IPv6...
Last post by Maurice - Today at 03:33:30 PM@n3 Kannst Du so machen, wobei Du dann auch im Client-Netz GUA + ULA verwenden solltest.
IPv4-only-Clients am besten in ein eigenes IPv4-only-LAN packen. Über Tayga kannst Du dann die Brücke zu den IPv6-LANs herstellen.
Für einen Fünfer mehr würde ich definitiv das statische GUA-Präfix nehmen. Das hast Du zwar auch nicht bis in alle Ewigkeit, anders als z. B. eine Telefonnummer kann es nicht "portiert" werden und ist spätestens beim Provider-Wechsel weg. Aber ein manuelles Renumbering alle paar Jahre ist etwas völlig anderes als ein sich ständig änderndes dynamisches Präfix.
@meyergru
IPv4-only-Clients am besten in ein eigenes IPv4-only-LAN packen. Über Tayga kannst Du dann die Brücke zu den IPv6-LANs herstellen.
Für einen Fünfer mehr würde ich definitiv das statische GUA-Präfix nehmen. Das hast Du zwar auch nicht bis in alle Ewigkeit, anders als z. B. eine Telefonnummer kann es nicht "portiert" werden und ist spätestens beim Provider-Wechsel weg. Aber ein manuelles Renumbering alle paar Jahre ist etwas völlig anderes als ein sich ständig änderndes dynamisches Präfix.
@meyergru
Quote from: meyergru on Today at 03:09:58 PMDen Trick, den Maurice nennt, mal außen vorgelassen - dabei würdest Du den ULA-Clients die IPv4 niemals zeigen. Das bedeutet natürlich auch, dass diese Clients niemals irgendwelche IPv4 gezeigt bekommen - Zugriff auf IPv4-only Geräte im IoT Netz (z.B. schaltbare Steckdosen) ist damit dann per DNS-Name nicht mehr drin.Doch, natürlich. DNS64 (Unbound-Feature) synthetisiert AAAA-Records, falls es nur A-Records gibt. Und NAT64 (Tayga-Plugin) übersetzt zwischen IPv6 und IPv4. Mein Smartphone im IPv6-only-Netz greift so z. B. problemlos auf Smart Home-Kram im IPv4-only-Netz zu.
#28
25.7, 25.10 Series / Re: Error Updating: Release ty...
Last post by RobertoZ - Today at 03:13:58 PMHave you tried a different mirror?
#29
German - Deutsch / Re: Eigener DNS bei einer IPv6...
Last post by Zapad - Today at 03:11:16 PMQuote from: bimbar on Today at 02:44:20 PMIch habe für NAT64 noch nie einen guten Nutzen gefunden.
ich weiss nicht woher NAT64 (pfui) aufkommt aber in meinem Kontext habe ich immer NAT66 gemeint.
@n3
nutze die ULAS so wie du mags wenn es funktioniert und wenn ein ULA doch noch internet braucht kannst du ja immernoch NAT66 dazuschalten.
#30
German - Deutsch / Re: Eigener DNS bei einer IPv6...
Last post by meyergru - Today at 03:09:58 PM@Maurice: Klar, mit Tricks geht das. Aber 1. sind wir da wieder bei komplexen Umgehungslösungen und b. funktioniert auch das nur bedingt, siehe unten...
@Zapad: Das beweist wieder nichts. Ich streite dich nicht ab, dass Deine Clients IPv6 nutzen - und wenn sie nur ULAs haben, dann auch nur diese. Aber: sie nutzen die ULAs nicht für intra-LAN- oder (mutmaßlich) für inter-VLAN-Traffic!
Nochmal ganz simpel erklärt - mach mal einen Test: Trage eins Deiner Geräte mit IPv4 und IPv6 ULA in den DNS ein, sagen wir:
smtp.xyz -> 192.168.10.100 und fd05::100
Dann versuchst Du, auf irgendeinem IPv6-fähigen CLient den Namen aufzulösen:
#nslookup smtp.xyz
Server: 192.100.10.1
Address: 192.168.10.1#53
Non-authoritative answer:
Name: smtp.xyz
Address: 192.168.10.100
Name: smtp.xyz
Address: fd05::100
Fein. Und dann kontaktierst Du den Server:
#ping smtp.xyz
PING smtp.xyz (192.168.10.100) 56(84) bytes of data.
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=3 ttl=64 time=0.052 ms
Wie? Wieso IPv4? Wie gesagt, das ist das Standardverhalten. IPv4 wird den ULAs vorgezogen. Wenn Du also nicht ausschließlich ULAs (und keine IPv4) im DNS-Reply zurückbekommst, wird nur die IPv4 verwendet. Den Trick, den Maurice nennt, mal außen vorgelassen - dabei würdest Du den ULA-Clients die IPv4 niemals zeigen. Das bedeutet natürlich auch, dass diese Clients niemals irgendwelche IPv4 gezeigt bekommen - Zugriff auf IPv4-only Geräte im IoT Netz (z.B. schaltbare Steckdosen) ist damit dann per DNS-Name nicht mehr drin.
Über die IPv4-only Clients müssen wir nicht diskutieren, die nehmen ohnehin nur die IPv4-Adresse. Also:
Deine ULAs nutzen im LAN nichts - sie werden schlicht ignoriert, Du kannst sie ebensogut aus dem internen DNS löschen. Du nutzt bei LAN-internem Traffic de facto ausschließlich IPv4 - zumindest, wenn Du es "normal" per DNS probierst. Die Rahmenbedingungen habe ich in den Varianten genannt.
Den einzigen Effekt, den Du erzielst, ist, dass Du im LAN GUA vermeidest und stattdessen NAT66 benötigst. Warum das nützlich ist, ist mir immer noch unklar (außer, man will IPv6-only im LAN und muss dann für Github und andere IPv4-only Websites NAT machen).
@Zapad: Das beweist wieder nichts. Ich streite dich nicht ab, dass Deine Clients IPv6 nutzen - und wenn sie nur ULAs haben, dann auch nur diese. Aber: sie nutzen die ULAs nicht für intra-LAN- oder (mutmaßlich) für inter-VLAN-Traffic!
Nochmal ganz simpel erklärt - mach mal einen Test: Trage eins Deiner Geräte mit IPv4 und IPv6 ULA in den DNS ein, sagen wir:
smtp.xyz -> 192.168.10.100 und fd05::100
Dann versuchst Du, auf irgendeinem IPv6-fähigen CLient den Namen aufzulösen:
#nslookup smtp.xyz
Server: 192.100.10.1
Address: 192.168.10.1#53
Non-authoritative answer:
Name: smtp.xyz
Address: 192.168.10.100
Name: smtp.xyz
Address: fd05::100
Fein. Und dann kontaktierst Du den Server:
#ping smtp.xyz
PING smtp.xyz (192.168.10.100) 56(84) bytes of data.
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from smtp.xyz (192.168.10.100): icmp_seq=3 ttl=64 time=0.052 ms
Wie? Wieso IPv4? Wie gesagt, das ist das Standardverhalten. IPv4 wird den ULAs vorgezogen. Wenn Du also nicht ausschließlich ULAs (und keine IPv4) im DNS-Reply zurückbekommst, wird nur die IPv4 verwendet. Den Trick, den Maurice nennt, mal außen vorgelassen - dabei würdest Du den ULA-Clients die IPv4 niemals zeigen. Das bedeutet natürlich auch, dass diese Clients niemals irgendwelche IPv4 gezeigt bekommen - Zugriff auf IPv4-only Geräte im IoT Netz (z.B. schaltbare Steckdosen) ist damit dann per DNS-Name nicht mehr drin.
Über die IPv4-only Clients müssen wir nicht diskutieren, die nehmen ohnehin nur die IPv4-Adresse. Also:
Deine ULAs nutzen im LAN nichts - sie werden schlicht ignoriert, Du kannst sie ebensogut aus dem internen DNS löschen. Du nutzt bei LAN-internem Traffic de facto ausschließlich IPv4 - zumindest, wenn Du es "normal" per DNS probierst. Die Rahmenbedingungen habe ich in den Varianten genannt.
Den einzigen Effekt, den Du erzielst, ist, dass Du im LAN GUA vermeidest und stattdessen NAT66 benötigst. Warum das nützlich ist, ist mir immer noch unklar (außer, man will IPv6-only im LAN und muss dann für Github und andere IPv4-only Websites NAT machen).
