Topics

1

German - Deutsch / Zeitgesteuerte MAC-basierte Firewall-Regel

« on: July 22, 2024, 10:14:39 am »

Hallo,

das Kind muss nachts etwas eingeschränkt werden :-D
Ich habe hier daher eine Liste an relevanten MAC-Adresse, die ich gern zeitgesteuert blockieren will. Diese MACs hängen alle in unterschiedlichen VLANs. Gibt es einen einfachen Weg für eine globale Regel, um die zeitgesteuert per DENY zu blockieren oder muss ich in jedem VLAN separat eine Regel anlegen? Geht das vllt. auf dem übergeordneten physischen LAN über das die VLANs letztlich laufen?

VG

2

German - Deutsch / DNS-Verfügbarkeit gewährleisten bei AdGuard auf externem NAS

« on: May 12, 2024, 06:23:46 pm »

Bevor ich mich an die Umsetzung mache, hier eine Frage, ob und wie das technisch lösbar ist. Ich nutze OPNsense 24.1.5 mit Unbound DNS, ganz normal. Ich möchte Adguard Home einsetzen aber ungern ein externes Repository auf der OPNsense integrieren, daher war die Überlegung, Adguard als Docker auf dem permanent aktiven NAS aufzusetzen. Ich benötige Adguard, weil ich bei der Blocklist Ausnahmen für bestimmte Clients machen muss.

Dazu hätte ich für DNS-Anfragen, die *nicht* vom NAS kommen im OPNsense eine Port Forwarding Regel für UDP Port 53 eingerichtet, die auf den Adguard Docker Container auf dem NAS verweist. Und Adguard wiederum soll als Upstream natürlich den Unbound von OPNsense verwenden.

Die Frage ist nun: Wie kann ich da nun die Verfügbarkeit erhöhen. Für den Fall, dass das NAS gerade nicht verfügbar ist, werden dann vermutlich keine DNS Anfragen mehr beantwortet. Gibt es eine Möglichkeit im OPNsense den integrierten Unbound *doch* zu nutzen, falls das Adguard auf dem NAS nicht antwortet oder erreichbar ist?

3

24.1 Legacy Series / Gateway monitoring issue with multiple IPv6 WAN addresses

« on: April 15, 2024, 09:37:18 am »

I have a similar problem to https://forum.opnsense.org/index.php?topic=38757.0 and https://forum.opnsense.org/index.php?topic=39734.0

I have been using OPNsense 24.1.5 with fiber optics from Telekom. IPv4 and IPv6 work perfectly with it. Due to occasional outages, I have retrofitted a 4G modem and now also use LTE from Telekom. The LTE was not very easy to set up, but at least a connection seems to be established for the time being. The current situation is that I receive an IPv4 and an IPv6 address for both fiber optics and LTE. For fiber optics, I also request a /56 prefix.

I now want to store a monitoring IP for the gateways. I use the IPv4 and IPv4 DNS servers from Google for this. The overview shows that the ping also works, but the FIBER_DHCP6 interface is causing problems. If I switch off the LTE interface, the check on the FIBER_DHCP6 also works immediately. Does anyone have any ideas? I have attached the routing table and interface configuration. What is striking is that the IPv6 address on the FIBER_DHCP6 interface has the status "detached". No matter what IPv6 settings I make for fiber and LTE in OPNsense, nothing changes.

BTW: When trying to do a trace route from a connected client to any external IPv6 host, I can see, that the FIBER_DHCP6 interface is going to be used. So it is up and running.

Code: [Select]

pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
        description: FIBER (opt1)
        inet6 fe80::2d0:b4ff:fe01:a913%pppoe0 prefixlen 64 scopeid 0x11
        inet6 fe80::2d0:b4ff:fe01:a914%pppoe0 prefixlen 64 scopeid 0x11
        inet6 2003:a:b:c:2d0:b4ff:fe01:a913 prefixlen 64 detached autoconf
        inet 80.a.b.c --> 80.146.129.38 netmask 0xffffffff
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
ppp1: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
        description: LTE (opt9)
        inet6 fe80::2d0:b4ff:fe01:a913%ppp1 prefixlen 64 scopeid 0x12
        inet6 fe80::48a9:23e0:5266:9e38%ppp1 prefixlen 64 scopeid 0x12
        inet6 2a01:x:y:z:2d0:b4ff:fe01:a913 prefixlen 64 autoconf
        inet 10.x.y.z --> 10.64.64.1 netmask 0xffffffff
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

Code: [Select]

# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            80.146.129.38      UGS      pppoe0
8.8.4.4            10.64.64.1         UGHS       ppp1
8.8.8.8            80.146.129.38      UGHS     pppoe0
10.10.10.0         link#16            UHS         lo0
10.10.10.0/24      link#16            U           wg1
10.10.10.1         link#16            UHS         wg1
10.10.10.2         link#16            UHS         wg1
10.64.64.1         link#18            UH         ppp1
10.x.y.z      link#18            UHS         lo0
80.a.b.c       link#17            UHS         lo0
80.146.129.38      link#17            UH       pppoe0
127.0.0.1          link#5             UH          lo0
192.168.1.0/24     link#2             U          igc1
192.168.1.1        link#2             UHS         lo0
192.168.10.0/24    link#11            U      vlan02.1
192.168.10.1       link#11            UHS         lo0
192.168.20.0/24    link#12            U      vlan02.2
192.168.20.1       link#12            UHS         lo0
192.168.30.0/24    link#13            U      vlan02.3
192.168.30.1       link#13            UHS         lo0
192.168.40.0/24    link#14            U      vlan02.4
192.168.40.1       link#14            UHS         lo0
192.168.50.0/24    link#15            U      vlan02.5
192.168.50.1       link#15            UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
default                           fe80::fe96:43ff:fee9:3fb0%pppoe0 UGS   pppoe0
::1                               link#5                        UHS         lo0
2001:4860:4860::8844              fe80::85f5:6104:e943:f277%ppp1 UGHS      ppp1
2001:4860:4860::8888              fe80::fe96:43ff:fee9:3fb0%pppoe0 UGHS   pppoe0
2003:d:e:f00::/56            ::1                           USB         lo0
2003:d:e:f01::/64            link#2                        U          igc1
2003:d:e:f01:2d0:b4ff:fe01:a914 link#2                     UHS         lo0
2003:d:e:f0a::/64            link#11                       U      vlan02.1
2003:d:e:f0a:2d0:b4ff:fe01:a915 link#11                    UHS         lo0
2003:d:e:f14::/64            link#12                       U      vlan02.2
2003:d:e:f14:2d0:b4ff:fe01:a915 link#12                    UHS         lo0
2003:d:e:f1e::/64            link#13                       U      vlan02.3
2003:d:e:f1e:2d0:b4ff:fe01:a915 link#13                    UHS         lo0
2003:a:b:c:2d0:b4ff:fe01:a913 link#17                     UHS         lo0
2003:180:2::53                    fe80::fe96:43ff:fee9:3fb0%pppoe0 UGHS   pppoe0
2003:180:2:6000::53               fe80::fe96:43ff:fee9:3fb0%pppoe0 UGHS   pppoe0
2a01:598:7ff:0:10:74:210:210      fe80::85f5:6104:e943:f277%ppp1 UGHS      ppp1
2a01:598:7ff:0:10:74:210:211      fe80::85f5:6104:e943:f277%ppp1 UGHS      ppp1
2a01:x:y:z::/64            link#18                       U          ppp1
2a01:x:y:z:2d0:b4ff:fe01:a913 link#18                    UHS         lo0
fe80::%igc1/64                    link#2                        U          igc1
fe80::2d0:b4ff:fe01:a914%igc1     link#2                        UHS         lo0
fe80::%lo0/64                     link#5                        U           lo0
fe80::1%lo0                       link#5                        UHS         lo0
fe80::%vlan02.10/64               link#11                       U      vlan02.1
fe80::2d0:b4ff:fe01:a915%vlan02.10 link#11                      UHS         lo0
fe80::%vlan02.20/64               link#12                       U      vlan02.2
fe80::2d0:b4ff:fe01:a915%vlan02.20 link#12                      UHS         lo0
fe80::%vlan02.30/64               link#13                       U      vlan02.3
fe80::2d0:b4ff:fe01:a915%vlan02.30 link#13                      UHS         lo0
fe80::%pppoe0/64                  link#17                       U        pppoe0
fe80::2d0:b4ff:fe01:a913%pppoe0   link#17                       UHS         lo0
fe80::2d0:b4ff:fe01:a914%pppoe0   link#17                       UHS         lo0
fe80::%ppp1/64                    link#18                       U          ppp1
fe80::2d0:b4ff:fe01:a913%ppp1     link#18                       UHS         lo0
fe80::48a9:23e0:5266:9e38%ppp1    link#18                       UHS         lo0

4

German - Deutsch / Multi WAN IPv6

« on: April 14, 2024, 06:01:04 pm »

Hallo zusammen,

ich muss doch nochmal fragen, ob mein Vorhaben überhaupt noch so möglich ist. Ich lese seit Stunden zu Multi WAN und Dual Stack etc. und drehe mich im Kreis. Also, zum "alten" Setup nochmal:

- OPNsense 24.1.5
- Glasfaser von der Telekom mit IPv4 und IPv6 /56er Präfix
- IPv4 über PPPoE auf dem VLAN7 der Telekom
- IPv6 wird per DHCP6-PD über die IPv4 Verbindung bezogen
- mehrere VLANs im heimischen Netzwerk, mit separaten DHCPv4-Adressen
- einige der VLANs erhalten zusätzlich über das /56er IPv6-Netz eine eigene IPv6 mit Präfix, dazu wird Tracking auf das PPPoE-Interface verwendet

Das läuft alles stabil. Was die Wurzel allen Übels ist: Ich wollte über LTE eine Fallback-Verbindung aufbauen, weil Glasfaser gelegentlich mal ausfällt. Dazu habe ich meinen China-Router um ein Quectel-LTE-Modul erweitert und ein neues PPP-Interface in OPNsense eingerichtet. Das ist mittlerweile so konfiguriert, dass ich von der Telekom über LTE eine IPv4-Adresse und eine /64er IPv6-Adresse erhalte - also auch hier Dual Stack.

Was möchte ich erreichen:
- Verwendung von Glasfaser als Haupt-Gateway
- Fallback auf die LTE-Verbindung, falls Glasfaser ausfällt
- Erhaltung der IPv6-Funktionalität auch in den VLANs bei Wechsel des Gateways

Es gibt aktuell zwei Knackpunkte, falls ich nichts übersehe:

1) Ich habe für alle vier Gateways (IPv4/6 jeweils Glasfaser/LTE) eine dedizierte Monitoring-IP hinterlegt, aber sobald das LTE-Interface mit IPv6 hochfährt, wird die IPv6 vom Glasfaser Interface als detached markiert und kann von dpinger nicht mehr verwendet werden. Das ist mir zu hoch, versuche da gerade im Forum schon Hilfe zu bekommen.

2) Was vermutlich schwieriger ist: IPv6 beim Wechsel des Gateways auf die VLANs bringen. Wie gesagt, Glasfaser bietet zwar ein /56 Präfix, das ist aber nur dynamisch, über LTE bekomme ich nur eine dynamische /64. Außerdem beziehen die VLANs über Tracking vom Glasfaser Interface ihre IPv6.

Hat hier jemand ein solches Setup bereits zum Laufen bekommen und kann mir einen Hinweis geben? Insbesondere zu einer Lösung für die IPv6-Adressen in den VLANs? In IPv6 bin ich nicht wirklich fit, aber das nicht möglich, den VLANs ein ganz eigenes IPv6 Netz zu geben und die OPNsense übersetzt das ins aktive Gateway (quasi ein NAT)?

5

German - Deutsch / IKEv2 läuft mit Windows aber nicht mit Android

« on: March 29, 2024, 08:34:34 pm »

Habe OPNsense 23.7.12 im Einsatz. Es kursieren ja grundsätzlich zwei Methoden ein IPsec mit IKEv2 EAP-MSCHAPv2 aufzusetzen: https://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html und https://docs.opnsense.org/manual/how-tos/ipsec-rw-srv-mschapv2.html

Mein Ziel bei der Aktion ist grundsätzlich die nativen Clients in Windows und Android zu nutzen. Ich habe mit beiden Methoden einen Full-Tunnel unter Windows 11 erfolgreich zum Laufen gebracht. Ich gehe also davon aus, dass ich grundsätzlich auf der Seite von OPNsense alles richtig konfiguriert habe (wie gesagt, habe mich an den Anleitungen orientiert). Es gab zwar ein paar Fallstricke, die ich mir noch nicht erklären kann, aber es lief erstmal.

Mein Problem: Ich kriege es unter Android 13 nicht zum Laufen. Also der Connect funktioniert. Der Android Client baut die Verbindung auf (sehe es auch im IPsec-Plugin im OPNsense-Dashboard). Aber es geht *null* Traffic über die Leitung, kein Ping, keine Namensauflösung, kein HTTP, einfach nichts. Und das kann ich mir nicht erklären - der Windows-Client läuft ja.

Hat jemand eine Idee, in welche Richtung das gehen könnte? Bitte *keine* Tipps, dass ich Strongswan nutzen soll - das will ich nicht. Als Fallback setze ich Wireguard ein, das läuft super, hätte aber trotzdem gern eine Lösung mit den nativen Clients.

6

23.7 Legacy Series / [Solved] High disk writes

« on: January 03, 2024, 08:24:51 pm »

I'm running OPNsense 23.7 on a Intel N100 with 8GB RAM and a 256GB NVMe. The only plugins I've installed additionally are: os-ddclient, os-udpbroadcastrelay and os-wireguard. I've not changed any logging configuration.

S.M.A.R.T. shows me 6GB of "Data Units Written" per day but the disk usage itself doesn't increased (used space it at 21GB constantly). Because of that I've configured the RAM disk for /tmp and /var/log but the "Data Units Written" remains unchanged. Using top for I/O stats I can't see any process that is doing writes continuously.
So my question is: What causes this disk writes and how to stop it?

7

German - Deutsch / Konfigurationsfragen zu IPsec Tunnel

« on: December 28, 2023, 02:10:12 pm »

Hallo,

ich sitze seit Tagen daran meine OPNsense 23.7 und IPsec einzurichten und mir brummt der Schädel. Einiges funktioniert, manches nicht. Habe mittlerweile zwei Varianten gebaut, zu denen sich ein Windows Client erfolgreich verbinden kann:
https://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html (mittels Connections)
https://administrator.de/tutorial/ipsec-ikev2-vpn-fuer-mobile-benutzer-auf-der-pfsense-oder-opnsense-firewall-einrichten-337198.html (mittels Tunnel/Legacy)

Der Client bekommt eine 10.0.0.1 und das VLAN 10 (192.168.10.0) ist erreichbar bzw. ich kann PINGs absetzen, also das gröbste ist erstmal erledigt.

1) Ich habe unter Mobile Clients/IKE Extensions zwar den Domain Name und DNS Split gesetzt (mal nur eins/mal beides), wenn sich aber Windows verbindet, wird der DNS Suffix nicht übermittelt. Ich muss für einen lokalen PING also immer explizit den Suffix an Hostnamen anhängen. Ist das bekannt oder Absicht? Ist der einzige Workaround im Windows-Client unter den IPv4 Einstellungen den verbindungsspezifischen Suffix explizit manuell einzutragen?

2) Sehe ich das richtig, dass IPsec den kompletten Traffic tunnelt, egal ob in der OPNsense nur ein 192.168.10.0/24 als lokales Netz eingetragen ist? Zumindest wird in Windows immer eine Route für 0.0.0.0 in den Tunnel gesetzt. Und so laufen PINGs bspw. an 8.8.8.8 ins Leere, nur das VLAN ist erreichbar. Wie kann das gelöst werden? Muss ich hier auf Seite der OPNsense doch das komplette 0.0.0.0/0 statt dem gewünschten lokalen VLAN eintragen? (Outbound NAT und FW ist dann klar, mir geht es aber darum, dass ich eigentlich vom Client nur das 192.168.10.0 getunnelt haben will und nicht alles)

3) Das Windows-Interface für das VPN erhält keinen DNS-Server bei Verbindungsaufbau. Da das IPsec Netz 10.0.0.0/24 wohl nicht per DHCP an den Client vergeben wird (sondern nur ein IP-Pool ist), muss ich vermutlich ausdrücklich unter Mobile Clients/IKE Extensions die IP der OPNsense als DNS-Server hinterlegen, richtig?

Android zickt noch komplett, aber ich will erstmal den Windows-Client sauber ans Laufen bringen.