Messages

Am Anfang Versuch Mal nicht die Server etc. mit VLANs zu konfigurieren. Dann hast du irgendwann zuviele Unbekannte
Mal eine Beispielkonfig:
VLANs:
1- Management
2 - normales LAN
3- Gäste LAN

Angenommen du hast einen 8 Port Switch
P1 - Opnsense
        Untagged:VLAN1,
        Tagged:  VLan 2&3
P2 - Unifi Ap
        Untagged:VLAN1,
        Tagged:  VLan 2&3
P3 - Unifi Controller
        Untagged: VLAN 1
P4,5&6- Irgend ein Client im LAN
        Untagged: VLAN 2
P8- Irgend ein Client im Gästenetz (per Kabel)
        Untagged: VLAN 3

Prinzip grundsätzlich verstanden?
Alle Untagged Ports im gleichen VLAN bilden eine Art virtuellen Switch.

Die Begriffe sind bei den Herstellern teilweise unterschiedlich.
Aruba redet von un-/tagged, bei anderen kommt dann noch Begriffe wie  PVID mit ins Spiel.

Management Switch vorhanden? Dann teste Leg dir erstmal 3 Ports untagged in jedes Vlan und teste ob DHCP funktioniert.
(zumindest bei der Apu3 muss "Disable VLAN Hardware Filtering" gesetzt werden, sonst klappt das nicht)

Ohne Switch würde ich erstmal nen Lapti an den Port hängen, DHCP kontrollieren. Schauen ob du über den Lapi Port 8080? (den aus der Inform-Url) am Kontroller erreichen kannst
Wenn das klappt den AP anhängen.
Solltest du im Kontroller "Controller Hostname/IP" gesetzt haben und "Override inform host with controller hostname/IP" aktiviert haben, so muss das DNS diesen Namen auch korrekt auflösen.

Nachträgliche Änderungen bringen nichts, da der App den Kontroller ja nicht kontaktieren kann. Da kannst du nur per SSH mit set-inform-url nachhelfen (das hilft aber nur einmalig, solange du nicht die richtige Konfig abholen lässt.)

Erst wenn das klappt mit der WiFi Konfig beginnen.

Ich würde z.B. 3 Interfaces auf einem Port verwenden:
Igb2 untagged
Igb2_vlan10 für SSID1
Igb2_vlan20 für SSID2

Das Management LAN von dem AP lässt du im Untagged, den das hat das größte Potential zum Aussperren.

Falls du einen Vlan fähigen Switch besitzt, wäre es eventuell sinnvoller die Sense mit einen Trunk Port mit dem Switch zu verbinden. Dann könntest du z.B. SSID1 im gleiche Subnetz wie dein LAN betreiben, ohne dass du Routen (oder eine Bridge einrichten) musst.

- Enable 'DNS Query Forwarding' in unbound
or
- add a domain overwrite for local domains

Code Select Expand

domain.local, _msdcs.domain.local and 1.1.10.in-addr.arpa

Btw. there is a design failure in your planning:
The DNS server in your dc will not know all local entries.

PLZ Check your local domain name and the Domain search list in your DHCP scope.
I guess there is a 'com'  in the DHCP Option 119 or at the manual settings of your nic.

Dns:
First IP shown at nslookup is the resolving DNS server.
The DHCP in your ipfire was configured to push an external DNS server to the Clients.
Your opnsense DHCP pushes itself as DNS resolver to the Clients.
In my opinion it's okay and the better choice as for example it's allowing you to resolver local hostnames.


Portforward: the destination address should be your wan address instead of LAN address.
That should so the job from the outside.

From inside you need either
- split-dns (Host overwriting in unbound): your local DNS resolver gives back the local IP of your webserver
or enable NAT Reflection:
https://docs.opnsense.org/manual/nat.html

Goto System: Settings: Administration
and Change your Port to 444 for example.
And Check "Disable web GUI redirect rule".

I guess your config contains private Data so I recommend to remove it from the Forum.

Install the Plugin again and disable "auto renewal" seems to remove the cron Job.

I guess you have to remove the custom options first and enter private-domains and Forwarder after that.

It generates two config files that are included in the main config:

Code Select Expand


root@gw:/var/unbound/etc # less miscellaneous.conf
server:
private-domain: dbl.spamhaus.org
root@gw:/var/unbound/etc # less dot.conf
server:
  tls-cert-bundle: /etc/ssl/cert.pem
forward-zone:
  name: "."
  forward-ssl-upstream: yes
  forward-addr: 1.1.1.1@853



But there seems to be a bug at the validation of "DNS over TLS Servers".
I'm not able to enter more than one value at the moment.

I would suggest to give it a try to set it to "Disable VLAN Hardware Filtering"

This could solve the dhcp-problems and may help with your other problemes as well.

So you have disabled VLAN Hardware Filtering ?
You find it under. /Interface/ Settings

Ich vermute Mal, dass ionos kein dyndns unterstützt (zumindest war das früher so).

Du könntest:
- wenn ionos cnames in deinem Paket unterstützt:
Irgendwo einen DDNS Account besorgen (z.B.spdns.de) und in Opnsense einrichten.
Bei ionos einen cname einrichten, der z.B. von intern.domain.de auf meinpc.spdns.de zeigt.

- Falls du die Nameserver für die Domain frei konfigurieren kannst, könntest du z.B. auch die Zone bei DNS.he.net hosten, die Nameserver bei ionos umkonfiguriert auf die he.net Nameserver.
Vorteil: bei he.net kannst du aus jedem A-Record einen DDNS fähigen Record mit einer TTL von 5 Minuten machen und diesen direkt mit dem Dynamic DNS Service in der Opnsense aktualisieren.
Die Einrichtung ist allerdings etwas anspruchsvoller. Wenn du da nicht genau weißt was du machst, ist die Domain auch Mal schnell 1-2 Tage nicht erreichbar.

Hier noch mal den Vorgang in Screenshots.
Falls der Zustand im 3ten Bild nicht eintrifft, die Regel aus dem 4. Bild anlegen.

Nicht irritieren lassen:
- meine spontan herbeigezauberte Fritzbox hat eine andere Adresse (also 192.168.2.1 statt 168.192.168.178.1 verwenden)
- mein WAN Interface heißt WAN_7
- meine Netzwerke (die Source Networks) beginnen alle mit LAN_xx_yyyyyy. Wenn du derzeit nur ein Interface im LAN konfiguriert hast heißt das vermutlich einfach nur "LAN_net"



Dazu noch ein paar Anmerkungen:
- Die Portforwardings aus einem deiner Screenshots lösche bitte vorerst
- zusätzlichen Router löschen hatte ich ja schon einmal geschrieben
- Die ganzen Firewallregeln unter "WAN" die du angelegt hast bitte auch wieder löschen - da hat ja schon jemand drauf hingewiesen.


Das Windows "kein Internetzugriff" ignorierst du bitte erst einmal und gehst dass analytisch an.
Sobald du eine externe IP wie 8.8.8.8 aus dem LAN anpingen kannst versucht du einen ping auf einen externen Namen.
Funktioniert das nicht, würde ich
1. Namensauflösung gegen externen Server testen

Code Select Expand


nslookup
Standardserver:  gw.intra.xyz.de
Address:  fd95:96d0:8ff0:1d21::254

> server 8.8.8.8
Standardserver:  dns.google
Address:  8.8.8.8

> heise.de
Server:  dns.google
Address:  8.8.8.8

Nicht autorisierende Antwort:
Name:    heise.de
Addresses:  2a02:2e0:3fe:1001:302::
          193.99.144.80

>


2. Namensauflösung gegen die IP der Firewall testen
Dann entweder den Unbound auf der Sense lauffähig bekommen oder das DHCP im LAN Checken.

EDIT:
Ich habe das gerade mal nachgebaut (PPPOE Modem durch vorgeschaltete Fritzbox ersetzt).
Es entsteht genau das gleiche Bild.
Durch das hinzufügen der folgenden NAt-Outbound Regel komme ich wieder ins Internet
Interface: WAN
Source address:  LAN_net
Den Rest wie vorgegeben belassen.
Du benötigst für jedes Netz im LAN eine eigene Regel, bzw. einen entsprechenden Alias.

Fraglich ist immer noch ob das der Sinn der Erfindung ist oder ob es nicht einen eleganteren Weg gibt.

EDIT2:
Nachdem ich die Regel hinzugefügt habe und von "MANUAL" auf "Automatic outbound NAT rule generation
(no manual rules can be used)" umgestellt habe waren auf einmal die automatischen Regeln auch vorhanden

Da fehlt die Regel für ausgehendes NAT, die sollte eigentlich automatisch angelegt werden.
Ob das jetzt "so soll" (weil die Sense aufgrund der privaten Adressen am WAN davon ausgeht, dass kein Nat benötigt wird) und du die von Hand anlegen musst
oder ob da was im Argen liegt kann ich dir nicht sagen
Ich würde erstmal testweise auf Hybrid umschalten und eine Regel manuell anlegen.

Und dein zweiter Gateway (deaktiviert) ist meines Erachtens nach über.