Messages

Zertifikate können dahingehend tricky werden, dass man schon bei der Erstellung penibel genau aufpassen muss, welche zusätzlichen Infos man in den SAN-Feldern hinterlegt: FQDN, FQUN, IP-Adressen, ...
Strongswan scheint da recht genau zu prüfen, ob das präsentierte Zertifikat auch wirklich zur angelegten Verbindung passt. Das hat viele Fehlermöglichkeiten und hat mich auch schon die eine oder andere Stunde Debugging gekostet... PSK hingegen nimmt einige zusätzliche Variablen aus dem Spiel und ist speziell bei IPSEC mit Gegenstellen anderer Hersteller da unempfindlicher.

Um es klar zu sagen: Zertifikate sind natürlich sicherer und bei PSK gibt es den einen oder anderen Angriffsvektor, je nach Passwort und IKE-Version/Konfig.

Bei IPsec habe ich noch nie mit Zertifikaten herumgespielt/getestet/etc - bin da noch bei 0 - weswegen es mich wundert, warum da die Zertifikatsmeldung war und deswegen habe ich diese genannt

Ich habe die Erfahrung gemacht, dass man primär auf beiden Seiten für jede Stellschraube exakt die gleichen Werte einstellen muss. Dann klappt es in aller Regel auch. Problem ist natürlich auch die unterschiedliche Benennung. Problematisch sind da die Identitätstypen (meine Empfehlung: FQUN / E-Mail-Adresse, speziell bei Dyndns) und die Einstellungen für PFS (in der Regel DH14, sowohl bei Phase1 als auch bei Phase2). Dann müssen die Hash-Funktionen übereinstimmen (SHA256 oder SHA512). Und AES-256 ist was anderes als AES-256-GCM, also genau prüfen. Ein bisschen Transferleistung ist auch immer nötig, leider.

Meine Erfahrung zeigt, dass bei einem FQUN funktioniert und beim anderen FQDN! :D Ich checke noch nicht die Logik, wann genau es funktioniert, da ich hier echt rumspielen/testen musste und es dann mal geklappt hat, obwohl es eigentlich schon vorher hätte funktionieren müssen

Auf der OPNsense wird der PSK nur 1x eingegeben, bei Lancom gibt es den lokalen PSK und den entfernten PSK. Da also 2x das gleiche Passwort rein.

Ansonsten gehen mir die Ideen leider langsam aus.

Habe ich so gemacht, ohne Erfolg.

Dir gehen die Ideen aus? - Freut mich trotzdem sehr dich kennen gelernt zu haben! :D

2025-04-22T14:33:15    Informational    charon    12[IKE] <con7|491> authentication of 'subdomain.dyndns.tld' (myself) with pre-shared key   
2025-04-22T14:33:15    Informational    charon    12[IKE] <con7|491> sending cert request for "C=DE, ST=##, L=##########, O=##########, E=mail@domain.tld, CN=CA"   

Der Part von deinem Log auf der OPNsense irritiert mich. Anscheinend wird versucht, eine Authentifizierung mit Zertifikat vorzunehmen. Bei PSK auf der Lancom-Seite ist dies jedoch zum Scheitern verurteilt.

Hast Du schonmal versucht, die Verbindung auf der OPNsense komplett zu löschen und neu anzulegen? Vielleicht ist irgendwo im Hintergrund durch die Testerei Schrott hängen geblieben, der jetzt stört.

Ich kann am Montag die Verbindung neu anlegen. Vielleicht hilft es wenn ich das inklusive Neustarts mache. Vielleicht lag es nicht an mir, dass sich da eine PSK eingeschlichen hat sondern an der OPNsense/LANCOM. (wobei im Moment und auch schon die ganze Zeit nichts eingestellt war soweit ich weiß)

Ich habe schon eine IKEv1 Verbindung getestet, ohne Erfolg.

-----

Danke für deine Antworten! :) Ich melde mich am Montag wieder!
Liebe Grüße! Schönes Restwochenende bzw. schöne neue Woche! :)

Hi!

Auf beiden Seiten sind die korrekten DynDNS eingetragen als Ziel (konnte ich eben bei einem Ping erfolgreich auflösen, wobei die OPNsense den WAN-Ping nicht beantwortet hat! :D)

Die OPNsense hat am WAN Port eine feste IP

Der LANCOM hat zwei andere funktionierende/aktive IPsec Tunnel vorhanden

Die OPNsense hat noch ca. 5 andere IPsec Tunnel vorhanden, die funktionieren

Kurz: Ich bin mir 100% sicher dass hier kein CGNAT vorhanden ist! :)

P.S:: Der LANCOM hat auf den Ping reagiert :D

-----

Du sagst dass es bei der Verwendung von PSK anstelle von Zertifikaten weniger relevant ist?

Ich habe die Erfahrung bei vorherigen IPsec Tunnel mit OPNsense/LANCOM/noch ein anderer Hersteller gemacht, dass bei der Authentifizierung ich rumspielen musste mit "FQDN" oder "FQUN" oder "IP Adresse" und es irgendwann mal funktioniert hat.
(ich habe hier leider die Logik noch nicht ganz verstanden)

Auf beiden Seiten ist überall der gleiche PSK eingetragen
(an der OPNsense unter "pre-Shared Schlüssel" und im LANCOM bei der lokalen Identität als PW und bei der entfernten Identität als PW - Typ ist korrekt gewählt (Domänen-Name im Moment) und der Eintrag der Identität ist im Moment korrekt (so hoffe ich doch! :D - die lokale und entfernte DynDNS Adresse) )
- wie gesagt - ich spielte bisschen herum mit der Einstellung (FQDN/FQUN/IP-Adresse) und irgendwann hatte es funktioniert.
- leider aber nicht bei diesem Tunnel ;-(

Hast du noch eine Idee? :D
( P.S.: Vielen lieben Dank für deine Antworten bisher! :) )

Schönes Wochenende! :)

Ein Update von mir:

Es wurde mir geraten, da ich DynDNS auf beiden Seiten benutze, die DynDNS Adressen als "Meine Kennung" und "Peer Identifier" einzutragen.
(und auf dem LANCOM als "Lokale Identität" und "Entfernte Identität". Daten-Typ auf OPNsense: "Eindeutiger Name" - Daten-Typ auf LANCOM: "FQDN")

Das hört sich logisch an, aber im Moment gehe ich davon aus, dass auch FQUN benutzt werden können ohne "Zusammenhang" zu den restlichen Einstellungen.
(z.B. dass man irgendeine FQUN oder irgendeine random ausgedachte IP für lokal/remote hinterlegt werden kann - muss aber nur an beiden Seiten gleich sein)

Ich habe dies dann erneut getestet, da ich mich erinnere, schon IP als ID sowie FQDN als ID getestet zu haben:
- habe in der OPNsense unter "Meine Kennung" die im LANCOM eingetragene DynDNS Adresse angegeben (Im LANCOM als Ziel für den Verbindungsaufbau sowie als entfernte Identität, die ich eben auch eingetragen habe)
- beim "Peer-Identifizier" die DynDNS Adresse des LANCOM Routers (und im LANCOM als lokale Identität)

Das kam raus:

Code Select Expand

2025-04-22T14:33:15 Informational charon 12[IKE] <con7|491> received AUTHENTICATION_FAILED notify error
2025-04-22T14:33:15 Informational charon 12[ENC] <con7|491> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
2025-04-22T14:33:15 Informational charon 12[NET] <con7|491> received packet: from 4.1.7.8[4500] to 2.2.3.1[4500] (96 bytes)
2025-04-22T14:33:15 Informational charon 12[NET] <con7|491> sending packet: from 2.2.3.1[4500] to 4.1.7.8[4500] (512 bytes)
2025-04-22T14:33:15 Informational charon 12[ENC] <con7|491> generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
2025-04-22T14:33:15 Informational charon 12[IKE] <con7|491> establishing CHILD_SA con7{981}
2025-04-22T14:33:15 Informational charon 12[IKE] <con7|491> authentication of 'subdomain.dyndns.tld' (myself) with pre-shared key
2025-04-22T14:33:15 Informational charon 12[IKE] <con7|491> sending cert request for "C=DE, ST=##, L=##########, O=##########, E=mail@domain.tld, CN=CA"
2025-04-22T14:33:15 Informational charon 12[CFG] <con7|491> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
2025-04-22T14:33:15 Informational charon 12[ENC] <con7|491> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
2025-04-22T14:33:15 Informational charon 12[NET] <con7|491> received packet: from 4.1.7.8[500] to 2.2.3.1[500] (432 bytes)
2025-04-22T14:33:14 Informational charon 12[NET] <con7|491> sending packet: from 2.2.3.1[500] to 4.1.7.8[500] (508 bytes)
2025-04-22T14:33:14 Informational charon 12[ENC] <con7|491> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2025-04-22T14:33:14 Informational charon 12[IKE] <con7|491> initiating IKE_SA con7[491] to 4.1.7.8
2025-04-22T14:33:14 Informational charon 01[CFG] received stroke: initiate 'con7'
Mich wundert es, dass er die Certificate Authority erwähnt, die wir für OpenVPN Verbindungen benutzen.
In den IPsec Einstellungen sehe ich nirgends eine aktive CA für IPsec.
(wir benutzen die CA bisher auch ausschließlich für OpenVPN)

Ich stelle die OPNsense von "Authentifizierungsmethode" von "Mutual PSK" und danach wieder zurück - vielleicht hat sich doch intern etwas aufgehangen/etc. wobei ich mir 100% sicher bin, nie bei IPsec den "Mutual RSA" oder "Mutual Public Key" aktiviert zu haben.
(habe dann danach den PSK manuell wieder eintragen müssen)
- es kam beim Verbindungsaufbau genau der gleiche Output wie vorher - mit Zertifikats-Daten im Log!

Hast du Tipps welche Trace ich im LANCOM Trace Tool aktivieren soll um zu sehen, ob und was von der OPNsense kommt?

Vielen lieben Dank nochmal! :)

Hi! :D

1 Eindeutiger Benutzername, Ok!

2 Charon Log und NAT-T: Auf der OPNsense laufen noch andere IPsec Tunnel, alle mit NAT-T - aus diesem Grund wurden die nötigen Regeln für Port 500 (ISAKMP) und Port 4500 (NAT-T) sowie das ESP Protokoll schon gemacht - ein zusätzliches NAT sollte es nicht geben

3 LANCOM bietet ja mit der LANconfig Software auch ein Trace an: Habe "VPN-Status" aktiviert und auf der OPNsense ein Verbindungsaufbau angeklickt:
Von der OPNsense sehe ich keinen einzigen Eintrag - dafür aber von anderen IPsec's des LANCOM Routers (eine ins RZ und eine zu einem anderen Standort)
P.S.: Da kam doch ein Eintrag von der IKEv1 Verbindung die ich versucht habe und noch nicht gelöscht habe - ich denke da brauche ich nichts zu machen

Code Select Expand

[VPN-Status] 2025/04/17 13:13:17,543  Devicetime: 2025/04/17 13:13:20,767
starting external DNS resolution for OPNSENSEIKEV1
IpStr=>standort.dyndns.de<, IpAddr(old)=2.7.3.96, IpTtl(old)=300s

[VPN-Status] 2025/04/17 13:13:17,620  Devicetime: 2025/04/17 13:13:20,828
external DNS resolution for OPNSENSEIKEV1
IpStr=>standort.dyndns.de<, IpAddr(old)=2.7.3.96, IpTtl(old)=300s
IpStr=>standort.dyndns.de<, IpAddr(new)=2.7.3.96, IpTtl(new)=300s
P.S.: Etwas später hat er dasselbe DNS Lookup gemacht für die OPNsense IKEv2

Code Select Expand

[VPN-Status] 2025/04/17 13:14:30,984  Devicetime: 2025/04/17 13:14:34,214
starting external DNS resolution for XXOPNSENSE
IpStr=>standort.dyndns.de<, IpAddr(old)=2.7.3.96, IpTtl(old)=293s

[VPN-Status] 2025/04/17 13:14:30,984  Devicetime: 2025/04/17 13:14:34,221
external DNS resolution for XXOPNSENSE
IpStr=>standort.dyndns.de<, IpAddr(old)=2.7.3.96, IpTtl(old)=293s
IpStr=>standort.dyndns.de<, IpAddr(new)=2.7.3.96, IpTtl(new)=227s
4 Trace mit ip-router @ WAN.IP.OPNsense gestartet: Mit der IP sowie der DynDNS Adresse kam kein Eintrag auf dem Trace vom LANconfig

Code Select Expand

[TraceStarted] 2025/04/17 13:20:41,583
Used config:
# Trace config
trace + IP-Router @ 2.7.3.96

# Show commands
show bootlog
show locked-jobs

Code Select Expand

[TraceStarted] 2025/04/17 13:21:54,659
Used config:
# Trace config
trace + IP-Router @ standort.dyndns.de

# Show commands
show bootlog
show locked-jobs
Ich habe von der OPNsense Testweise Pings rausgehauen.
Egal ob IP oder DynDNS Adresse, diese wurden im LANconfig Trace nicht angezeigt.
(Gehört ICMP nicht auch unter den "IP-Router" Abschnitt? :D)

-----

Ich bin im Moment Ideenlos!
Wie gesagt - wenn ich anstatt "AES" und "265" ein anderes Protokoll wähle, sagt er eine Proposal Fehlermeldung.
Mit AES 256 sagt er, Authentication failed - ich meine, damit eine Authentication failed muss es ja eine Verbindung geben?

Ich habe noch mal einen anderen Trace gestartet:

Code Select Expand

[TraceStarted] 2025/04/17 13:29:22,018
Used config:
# Trace config
trace + IPSEC
trace + VPN-Status
trace + VPN-Packet
trace + VPN-IKE
trace + VPN-Debug
trace + VPN
trace + IPv4-WAN-Packet
trace + IPv4-Packet
trace + IP-Router
trace + ICMP

# Show commands
show bootlog
show locked-jobs

Ich habe die Ergebnisse nach der IP + DynDNS Adresse gefiltert - ich sehe nicht mal die Pings/ICMP von der OPNsense, obwohl die eine Antwort bekommen und obwohl im LANconfig Trace ICMP mit aktiviert wurde ... (ich sehe genau 0 Einträge der IP/Adresse)

Über Ideen/Rat/Tipps freue ich mich sehr!

P.S.: Das Trace vom LANconfig: Ich habe schon vor einer Weile versucht damit zurecht zu kommen: Ich sollte im Moment alles richtig gemacht haben. Aber, da er mir nicht mal das Ping/ICMP anzeigt, vermute ich, vielleicht bin ich das Problem beim Trace vom LANconfig ... (auch wenn ich im Moment nicht davon ausgehe - die anderen Ausgaben hat er mir ja korrekt gebracht)

Guten Tag!

Ich versuche von einer OPNsense-business 24.10.1 eine IPsec Verbindung zu einem LANCOM 1790VA (Firmware: 10.80.0833RU9 14.10.2024) Router aufzubauen, ohne Erfolg bisher.

Konfiguration OPNsense:
- IPsec -> Tunnel Settings [legacy] mit IPv4 IKEv2
- Anschlussart Standard mit V2, IPv4, die einzige WAN Schnittstelle
- Fernes Gateway ist eine DynDNS Adresse die sich korrekt pingen lässt (auch von der OPNsense aus, er bekommt eine Antwort)
- Mutual PSK
- Meine Kennung: Eindeutiger Benutzername (mail1@domain1.tld)
- Peer-Identifizierer: Eindeutiger Benutzername (mail1@domain1.tld)
- PSK an OPNsense und LANCOM hinterlegt
- AES -> 256
- SHA256, SHA512
- DH 14
- Richtlinie installieren: Häkchen gesetzt
- NAT-T: AKtiviert
- Close Action: Keines
- Unique: Ersetzen
- der Rest ist leer
Phase2:
- Tunnel IPv4
- LAN Subnetz
- 192.168.0.0/24 Remote Netz
- ESP
- AES256, aes256gcm16
- SHA256, SHA512
- PFS: 14
- Lebenszeit: 3600

Konfiguration LANCOM:
- VPN -> IKEv2/IPsec
- Entferntes Gateway auch eine DynDNS Adresse die sich korrekt auflöst bei einem Ping von meinem W11 Client
- Verschlüsselung, folgendes aktiviert:
- DH: 14
- PFS: Ja
- IKE-SA: AES-CBC-256, AES-GCM,356
- Hash-Liste: SHA-512, SHA-256
- Child-SA folgt:
- Verschlüsselungsliste: AES-CBC256, AES-GCM,256
- Hash-Liste: SHA-512, SHA-256
- Authentifizierung folgt:
- lokaler/Entfernter Identitätstyp: "E-MailAdresse (FQUN)": dieselbe wie bei der OPNsense - lokal und remote dasselbe! (mail1@domain1.tld)
- Passwort habe ich bei lokal und entfernt den PSK eingetragen von der OPNsense (hatte bei anderen Geräten schon funktioniert wie ich mich erinnere)
- der Rest wie vor eingestellt!
- P.S.: Ich nutzte den LANCOM Wizard zum erstellen des Tunnels und wählte Responder als Art (er reagiert auf Verbindungen, baut keine Aktiv auf)

Fehlermeldung: (P.S.: Die IP Adressen sind gefaked!)
2025-04-14T16:21:39   Informational   charon   06[IKE] <con7|344> received AUTHENTICATION_FAILED notify error   
2025-04-14T16:21:39   Informational   charon   06[ENC] <con7|344> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]   
2025-04-14T16:21:39   Informational   charon   06[NET] <con7|344> received packet: from 4.12.9.23[4500] to 21.27.30.16[4500] (96 bytes)   
2025-04-14T16:21:39   Informational   charon   06[NET] <con7|344> sending packet: from 21.27.30.16[4500] to 4.12.9.23[4500] (496 bytes)

Ich habe schon verschiedenes versucht wie z.B. IKEv1 (da sah ich laut LANCOM Trace nicht mal ein Verbindungsaufbauversuch, gar nichts) und verschiedene Proposals getestet (OPNsense akzeptiert anscheinend nur "AES" mit "256" - alle andere will er anscheinend nicht)

Ich freue mich natürlich sehr über Rückmeldung, ich wünsche eine schöne Woche und verbleibe
mit freundlichen Grüßen
GutFred

P.S.: Ich habe natürlich auch anstatt FQUN einen Domain-Name versucht, die eigene IP als lokal und die entfernte IP als remote Identifier - ich habe eine Menge versucht und bin am verzweifeln (deswegen auch der IKEv1 Versuch)

Guten Tag!

Ist es ein bekannter Bug, dass manchmal unter Firewall -> Regeln die "OpenVPN" Schnittstelle/der Container nicht mehr angezeigt wird?

1 Ich habe das Verhalten schon paar mal erlebt
- das letzte mal hatten wir unter Schnittstellen -> Überblick etwas an der ovpns1 Schnittstelle geändert, dann ging es wieder
- (soweit ich mich erinnere, hatten wir diese sogar neu angelegt, da sie weg war und gar nicht mehr funktionierte und wir die OPNsense nicht Neustarten konnten)

2 Dieses Mal
- ich testete OpenVPN und bemerkte, dass die DNS Namensauflösung nicht funktioniert
- an einem Client vor Ort war nicht der Windows DC, sondern ein LANCOM Router der DNS ...
- ... habe diesen eingetragen, ohne Erfolg - DNS mit Ping geht im Moment nur vor Ort ...
- dann fiel mir auf: "normale" Pings ohne DNS funktionieren auch nicht mehr!
- Dann: Oh Schreck, unter Firewall -> Regeln zeigt er nicht mehr OpenVPN an
- ich habe dann unter System -> Schnittstellen -> LAN das Häkchen gesetzt bei "Verhindere die Schnittstellenentfernung" und dann "Übernommen"
- Firewall -> Regeln -> OpenVPN ist wieder da, aber keine Pings funktionieren im Moment ...
-> Bevor ich manuell eine Schnittstelle erstelle, starte ich einfach mal die OPNsense neu und schaue was dann passiert (die ist sowieso vorhanden und als Aktiv markiert)
- in diesem Fall vermute ich, dass IPv6 beim Ping DNS Problem eine Rolle spielen kann
- oder die OPNsense sich irgendwo aufgehangen hat ...
- P.S.: Ich habe beim Vorgang ca. 2-3 mal den OpenVPN Server neugestartet

Jetzt starte ich die OPNsense neu und hoffe, Ihr kennt das Verhalten und könnt mir sagen wie ich am besten damit umgehe! :)

P.S.: Das Verhalten wurde an verschiedenen Versionen beobachtet in den letzten Jahren mit der ähnlichen Struktur
P.P.S.: Es gibt auch IPsec Site to Site Verbindungen - die funktionieren ohne Probleme (habe sogar eben den IPsec Dienst "aus versehen! :D" neu gestartet)
P.P.P.S.: Diese OPNsense soll bald einen LANCOM Router ersetzen (im Moment gibt es zwei WAN Verbindungen) - den Fehler unter den Firewall-Regeln habe ich aber vorher bei Setups mit nur 1 x WAN gehabt

-----

OPNsense Neustart:
- Ping ins LAN über OpenVPN funktioniert wieder, aber leider immer noch nicht mit DNS
- unter Firewall - Regeln ist OpenVPN wieder da
- IPsec Tunnel (und vermutlich alles andere bis auf DNS über OpenVPN) funktioniert

Vielen lieben Dank für Feedback!
Euch allen ein schönes Wochenende! :)
Grüße! Gutfred! :)

lol - danke! :D

Guten Tag allerseits!

Ich habe eine OPNsense Firewall bei der die Lizenz Morgen ausgelaufen wäre. (Datum war 2025-03-20)
Ich habe dann den neuen Lizenzkey eingetragen und "Auf Aktualisierungen prüfen" geklickt.
Nun wird dort angezeigt: "Licensed until" "2026-03-22"

Unter der Checkbox unter System -> Firmware -> Einstellungen wo ich die Lizenz eingetragen habe, steht folgendes:
"Um diese Änderungen der Einstellungen zu übernehmen, muss eine Firmware-Aktualisierung nach dem Speichern durchgeführt werden, was einen Neustart des Systems zur Folge haben kann."

Nun meine Frage: Muss ich jetzt wirklich noch eine Firmware-Aktualisierung durchführen oder ist die Lizenz bereits aktiv?
Ich gehe stark davon aus, dass die Lizenz aktiv ist, aber ich dachte, ich frage zur Sicherheit mal hier nach! :)

Im schlimmsten Fall muss ich Morgen nach Feierabend eine Firmware-Aktualisierung durchführen, im besten Fall habe ich noch Zeit! :D

Vielen lieben Dank für Feedback! Euch allen eine schöne Restwoche!

Grüße!
Gutfred

Guten Tag allerseits!

Wir hatten eine FRITZ!Box im EG und eine im Keller.
Diese waren über Mesh verbunden (Master und Client) und an beiden hängen DECT Telefone.

Zwischen diesen FRITZ!Boxen befindet sich nun eine OPNsense.
Bei der FRITZ!Box im EG funktioniert soweit alles sowie im LAN, dort funktioniert auch alles, bis auf dass die FRITZ!Boxen sich bzgl. Mesh und DECT sehen.

Habt Ihr Tipps/Ideen wie ich die Verbindung von der EG FB zur Keller FB bzgl. Mesh und DECT Funktionalität wiederherstellen kann?

Kurz noch paar Infos:
1 FB im EG ist Router und hat die IP 192.168.170.1
2 Diese FB ist am OPNsense WAN Port angesteckt. Der WAN Port lauscht auf 192.168.170.10
3 Am LAN-Port hat die OPNsense einen DHCP und hört auf dem LAN Port auf 192.168.160.1
4 Die FB im Keller hat eine reservierte IP 192.168.160.5

5 Ich habe in der FB im EG eine Route ins LAN gelegt (erreiche 192.168.160.0/24 über 192.168.170.10)
6 Ich habe Portweiterleitungen von den Ports 5060 und 53805 eingerichtet an der OPNsense. Pakete an diesen Ports werden weitergeleitet auf die 192.168.160.5
7 Gleichzeitig habe ich für diese Ports eine Weiterleitung zurück zur EG FB gemacht. Diese haben die Weiterleitung auf 192.168.170.1

8 Ich habe bei AVM eine Anfrage gestellt vor einigen Tagen und warte seitdem auf die Antwort

Vielen Dank schonmal für Antworten! :)

Grüße! Gutfred!

Nachtrag: Außerdem hat die FB im Keller die IP der FB im EG als DNS hinterlegt (192.168.170.1)