Posts by daimonion

Quote from maerte

Kann es sein dass bei Stiegeler intern das aktuell verwendete Modem registriert ist und somit kein anderes Gerät sich einwählen kann?

Ja, genau. Das ist Standard bei GF Anschlüssen.

Da viele GF-Netze GPON Netze sind, müssen die Versorger schauen, dass sich ONT's nicht stören können.
So zumindest die Erklärung in meinem Kopf. Wer es besser weiß darf mich gerne mit Wissen beschmeißen.

Wobei du ja an der Stelle nur einen 1G-SFP Modul nutzt. Klar, wenn der gebuchte Tarif nur der 500er ist, dann machts nichts aus, aber ich würde, dann schon gerne gleich ein 10G Modul nehmen wollen, wenn ich umstelle.

Aber schön zu hören, dass Stiegeler sich mittlerweile nicht mehr quer stellt, bei eigenen ONTs. Welche Daten musstest du denn dem Techniker geben, dass er es einrichten konnte?

Quote from maerte

Eigenlich bin ich aber heute auf diesen ForenThread gestoßen weil ich auch das Problem mit dem CGNAT umgehen wollte. Werde die Tage mal versuchen auf IPv6 umzustellen und schauen ob ich damit klar komme (Anfrage nach einer eigenen öffentlichen IPv4 läuft zwar habe aber bis lang noch keine Rückmeldung bekommen).

Ich hab, seit ich bei Stiegeler bin, den DualStack Anschluss und ne saubere V4 und V6 Verbindung. Läuft super.
Hab damals direkt den Techniker bei der Inbetriebnahme gefragt ob er mir den Haken bei öffentlicher v4 setzen kann.

Na zum Beispiel könnten sie anstelle der Adresse das Symbol/den Platzhalter für das Device nehmen. Ich glaube bei v4 geht das mehr oder weniger schon.

Klar die unten drunter liegende Regel muss das irgendwie dann auch abbilden können und letztlich ist die Firewall wahrscheinlich auch nur ein iptables, aber da Ubiquity in dem Bereich in der letzten Zeit sehr aktiv war bin ich guter Dinge.

Quote from DoPe

Wie meinste das? Die Firewall lässt jetzt an alle IPv6 Adressen, die in DMZ sind den Port 443 durch?

Naja, wenn da nichts anderes drin ist und auch nicht rein kommt ok. Aber das ist schon ziemlich dirty anders geht es aber mit der Firewall aktuell nicht.

Genau. In der DMZ ist nur der reverse proxy. Die eigentlichen Server sind in einem weiteren vlan.

Die v4 Adresse kann ich beim portforwardingn ja angeben. Die v6 ändert sich entsprechend der Präfixänderung. Mal schauen wann ubiquity das fixt bei der Firewall.

Ja das ist richtig.

Hab das gestern auch nur mal zum Testen rein gemacht. Ist in der aktuellen Regel auch schon wieder raus und die Regel schaut nun auf die Zone.

Quote from DoPe

Source Port ist falsch. Da muss Any hin ... Man verbindet auf Port 443, aber das Paket wird sicher nicht von Port 443 abgesendet.

Die IPv6 ist dynamisch? Dann wird es ja nur von 12 bis Mittag funktionieren.

*KopfTisch* Wie kann man nur so doof sein. Natürlich muss als src Any hin. Vielen Dank. DoPe
nmap zeigt nun Port 443 offen an. Ich checke mal ob ich nun die Verbindungen alle herstellen kann

Naichbindas

Keine festen, sondern nur die üblichen Subnetze. Ich tausche die DST später noch gegen eine Zone aus.

Hallo Jungs.

Ich versuche seit geraumer Zeit meinen Zoraxy Reverse Proxy, der in der DMZ Zone hängt, via v6 (und https ) erreichbar zu machen.

Dazu aktualisiert dieser Server seine v4 und v6 Adresse an den DNS (IPv64), so dass diese im Netz sichtbar wird.
Für v4 habe ich ein Portforwarding (443) eingerichtet und damit komme ich auch auf den Server drauf.

Ist der Besucher allerdings via v6 angeschaltet so kommt dieser nicht auf meinen Server.

Ebenso kann ich das nachvollziehen, indem ich von einem Server im Internet via nmap versuche zuzugreifen. (Siehe Screenshot)

Nun vermute ich dass ich in meiner UDM-Pro hier eine Firewallregel nicht richtig konfiguriert habe, so dass diese blockt. Aber ich wüßte nicht, was ich da falsch gemacht haben sollte. Siehe weitere Screenshots.

Hat das schon jemand mal gemacht und könntet ihr mal einen Blick auf die Screenshots werfen?

Irgendwas muss ich doch übersehen.

Danke schon mal im Voraus

Grüße

Daimonion

Super.

In der client config Datei der wireguard config trägst du deine DNS Adresse nun anstelle der IP ein und dann sollte das klappen.

WireGuard config file example - Ein Beispiel mit allen Optionen

Hier werden alle Optionen, die in einem WireGuard Config File gesetzt werden könnten, einmal erklärt und beleuchtet. Was ist genau wofür?

schroederdennis.de

Jup, denke ich. Da die sich eh ändert, brauchst du da nichts großartig hiden....

Alternativ kannst du deine IP via https://www.wieistmeineip.de/ herausfinden.

Eine öffentliche v4 Adresse ist das aber? Nicht das du CGNAT/DS-Lite hast.

Prüfe doch erst mal ob die duckdns Adresse deine IP übernimmt. Ansonsten kann das ja nicht funktionieren.
D.h. welche öffentliche IP bekommst du aktuell von deinem Provider (steht im Network Controller auf der Startseite) und kennt deine duckdns Adresse diese IP auch.
Du kannst das entweder in der duckdns Oberfläche oder via nslookup prüfen.

Wenn das alles passt, dann sollte eine Wirguardverbindung möglich sein.

Joa, wenn du nen duckdns laufen hast, dann einfach die domain in der wireguardconfig anstelle der IP eintragen und dann sollte das klappen.

du kannst in wireguard ja ne domain anstelle der IP angeben. Dann klappts auch nach der Trennung wieder.

Natürlich musst du die domain dann auch updaten, wenn sich die IP ändert.

Ich hab das Skript für einen Server in der DMZ aktualisiert, wo das Prefix anhand der v6 Adresse extrahiert wird:

#!/bin/bash

PREFIX_FILE="/root/cached_prefix"
DATE_FILE="/root/prefix_last_update"
DATE=$(date +%F_%H:%M:%S)

# Funktion, um den IPv6-Präfix eines Interfaces zu extrahieren
get_ipv6_prefix() {
    interface="$1"
        # Extrahiere bestehenden Prefix im Interface (z.B. bei Unifi)
    #ip -6 addr show dev "$interface" | grep -E 'inet6 [0-9a-fA-F:]+/[0-9]+' |head -n 1 | awk '{print $2}' | sed 's/::[0-9]*\//::\//'
        # Erzeuge ein Prefix aus einer kompletten Adresse
        ip -6 addr show dev "$interface" | grep -E 'inet6 [0-9a-fA-F:]+/[0-9]+' | head -n 1 | awk '{print $2}' | sed -E 's/^(([^:]*:){4}).*\/(.*)$/\1:\/\3/'
}

read_prefix_from_File() {
        if [ -f "$PREFIX_FILE" ]; then
                cat "$PREFIX_FILE"
        fi
}

get_dyndns_prefix() {
    nslookup schmesterle.home64.de | awk '/^Address: .*:.*:/ {ip=$2} END {split(ip, a, ":"); printf "%s:%s:%s:%s::/64\n", a[1], a[2], a[3], a[4]}'
}


prefixes_match() {
    local ipv6_prefix="$1"
    local saved_prefix="$2"
        echo "Prefix vom Interface $ipv6_prefix"
        echo "Prefix aus nslookup $saved_prefix"
    [ "$ipv6_prefix" = "$saved_prefix" ]
}

main ()
{
        # Interface-Name (br0 in diesem Fall)
        interface="eth0"

        local ipv6_prefix
        local saved_prefix

    echo "$DATE -> DDNS Update Start" >> "$DATE_FILE"


        # Den IPv6-Präfix des angegebenen Interfaces ausgeben
        ipv6_prefix=$(get_ipv6_prefix "$interface")
        saved_prefix=$(get_dyndns_prefix)

        if [ -z "$ipv6_prefix" ]; then
        echo "Fehler: Das IPv6-Präfix des Interfaces eth0 konnte nicht gefunden werden."
        exit 1
    fi

        if prefixes_match "$ipv6_prefix" "$saved_prefix"; then
                echo "Prefix gleich. Update nicht notwendig."
        else
                echo "Speichere Prefix $ipv6_prefix"
                echo "$ipv6_prefix" > "$PREFIX_FILE"
                echo "Update des neuen Prefix auf ipv64"
                curl -sSL "https://ipv6.ipv64.net/update.php?key=hQimZy2nNseGfHWLFk4BCqpxrOK16t30&ip6lanprefix=$ipv6_prefix&onlyprefix"
        fi
    echo "$DATE -> DDNS Update Ende" >> "$DATE_FILE"
}

main

Quote from gierig

Für alles was das VLAN verlässt also L3 ist ist dann die normale Firewall.

Das habe ich schon mit der ZBF gut konfiguriert. Grundsätzlich kommt nichts aus dem Server VLan raus, es sei denn es ist return traffic.

Quote from gierig

ACL währe die korrekte Adresse um L2 als IN VLAN Traffic zu Filtern

IN VLan bedeutet innerhalb des VLans? Was mir noch gekommen ist. Alle Server in dem VLan laufen ja auf der selben Proxmox Kiste. D.h. der Traffic zwischen den Servern sieht der Switch wahrscheinlich gar nicht. So gesehen würde ich mich mal mit den Proxmox Firewall regeln beschäftigen.

Danke mal für deine/eure Antworten!

Huhu. Danke für eure Antworten.

DoPe du hast natürlich recht. Ping sagen grundsätzlich noch nichts über die Kommunikation aus. Auch habe ich nichts über mein Setup gesagt.

Bei mir läuft eine UDM-PRO, und zwei USW-Pro-24 (1x PoE). D.h. die sollten das schaffen. Der Server, auf dem die virtuellen Clients laufen hängt an einem der beiden USW dran.

Die Server sollen sich nicht sehen, da sie unterschiedliche Dienste anbieten und nichts voneinander brauchen. (Aktuell vaultwarden und docmost) Sie werden lediglich von einem ReverseProxy angesprochen, der in einem DMZ VLan sitzt. Die Verbindung von RP im DMZ zu den jeweiligen Servern im Server VLan funktioniert auch prächtig. Weiters funktioniert es aktuell auch schon, dass die Server nicht auf andere Netzwerke zugreifen können.

Quote from gierig

Wenn die alle in der gleichen Broadcast Domain aka VLAN hängen aka gleiches IP Netz, kannst du nur alleine und einzig die Kommunikation untereinander verhindern wenn du es LOKAL also auf den Maschinen verhinderst. Also durch Lokale ACL/Firewall.

Ah, d.h. die Anleitungen von Ubiquity hinsichtlich ACL und Client Isolation beziehen sich immer nur auf Clients in unterschiedlichen VLans?! Hmm, okay. Das würde einiges erklären.

Hallo

Ich habe ein VLan "Server", in dem ich mehrere virtuelle Server reinhaue, die mir die entsprechenden Dienste bereitstellen. Diese sollen sich untereinander nicht sehen dürfen. (aber auf Pakete von einem Server aus einem anderen VLan reagieren dürfen)

Lt. Unifi soll das mit MAC-ACL's funktionieren, aber ich hab es noch nicht hinbekommen, dass sie die Clients untereinander nicht anpingen können.

Bei den ACL's habe ich erst mal alles in dem vlan blockiert, aber ich kann dennoch die Server untereinander anpingen. Klar von außerhalb des VLans komme ich dann nicht mehr drauf.

Was muss ich denn wo einstellen, dass ich die Server untereinander nicht mehr pingen kann. Reicht das als Beweis überhaupt aus, dass sie sich nicht sehen?

Danke schon mal für euere Hilfe

Grüße

Daimonion

So sehe ich das auch.

Theoretisch alles machbar. Der Praxistest steht nach wie vor aus.

Quote from DieserNexx

Hi
Hatte mir das mal angeguckt

Ich bin zwar technisch begabt und gelernter IT'ler ( IT-Systemelektroniker)
Aber alles was mit IP Adressen usw. zu tun hat habe ich nicht so ganz versanden....

du schreibst "Stellt man auf PPPoE Passthrough so muss man die VLAN ID 7 selbst eingeben."

Wo und wie mach ich das?
Am Freitag wird unser DSL Anschluss freigeschaltet im Haus.
Daraufhin will ich dann Abends die Fritzbox in Verbindung mit dem UCG und allen AP's in Betrieb nehmen.

Display More

In dem von mir verlinkten Artikel hatte ich ja meinen Weg beschrieben. Lediglich meine Annahme VLAN ID 7 einzurichten war falsch (Siehe Post 6)

Die Vlan ID 7 stellt man in der Fritzbox ein, die den DSL Sync macht. In der UCG richtet man dann ganz normal die PPPoE Verbindung ein.

Quote from DieserNexx

Wie bereits oben beschrieben war das nie mein Lieblingsgebiet

Gibt's dazu eine Erklärung für "Dummies" ?

Nutze in deinem internen Netz einfach eine IP-Range aus einem anderen Bereich als 192.168.1.1/24 z.B. 192.168.123.1/24. Damit hast du keine Probleme wenn mal eine VPN Verbindung mit einem Standardadressbereich von 192.168.1.1/xx reinkommt.

auf der 7590 PPPoE Passthrough einschalten und auf dem Gateway Ultra die I-Net Verbindung via PPPoE aufbauen.

https://avm.de/service/wissen…Box-einrichten/

Vlan und so, kommt auf deinen DSL Provider an.

Für meinen hatte ich das kurz vor Umstellung auf die GF wie hier beschrieben hinbekommen: UDM-Pro via PPPoE Passthrough über 7580 an ADSL Anschluss

Also die Config ist hinten raus denkbar einfach. Ich habe auf SLAAC und nen /64er Prefix gesetzt und dann bekam ich eine v6 Adresse.