Messages

1

German - Deutsch / Re: einer Bridge zugewiesenes Interface fehlt

« on: October 20, 2023, 08:57:43 pm »

Ich antworte mir mal selbst. Das Problem habe ich nun umschifft, gelöst ist es noch nicht.

Ich habe in /usr/local/etc/rc.syshook.d/start folgendes Script mit dem Namen 99-add-missing-bridge-ifaces
abgelegt und ausführbar gemacht:

Code: [Select]

#!/bin/sh

bridges="bridge0"
bridge0="ixv0 vlan01 vlan02 vlan03"

for BR in ${bridges}; do
BRI=$(eval "echo \${$BR}")
for IF in ${BRI}; do
ALREADY_ADDED=$(/sbin/ifconfig ${BR} | grep ${IF})
if [ -z "${ALREADY_ADDED}" ]; then
echo "adding ${IF} to ${BR}"
/sbin/ifconfig ${BR} addm ${IF}
fi
done
done
In bridges trage ich die Netzwerkbrücken ein, die nicht so wollen, wie ich es will. Und in der Variable für jede Brücke die Interfaces, die zu der Brücke gehören sollen.

Grüße rookie.

2

German - Deutsch / Re: MacOs/IOS update cachen

« on: October 19, 2023, 02:46:59 pm »

Du kannst es mal probieren mit einem Squid-Proxy.

Da würde ich mir nicht allzu viele Hoffnungen machen. In iOS, iPadOS und ich gehe mal auch von macOS aus, ist die ausstellende CA fest verdrahtet. Wenn man da mit SSL Interception eingreift, geht so ziemlich nichts mehr, kein App Store, keine OS Updates, keine iCloud. Ich hatte das mal testweise in einem WLAN ausprobiert.

3

German - Deutsch / Re: UPnP Anfragen über VLan hinweg

« on: October 19, 2023, 08:56:46 am »

Das klingt fast nach einem Fall für den mdns repeater. Das Plugin nach installieren, wenn es nicht bereits installiert ist und anschließend unter Services -> mdns repeater die Interfaces wählen, auf denen er nach Bonjour Nachrichten lauschen und weiterreichen soll. Danach müssen zw. den Netzen/Interfaces noch Regeln erstellt werden, damit z.B. ein iPad auf den Drucker u.ä. in einem anderen Netz zugreifen kann.

4

German - Deutsch / einer Bridge zugewiesenes Interface fehlt

« on: October 18, 2023, 09:31:44 pm »

Hallo in die Runde,

ich habe folgendes komisches Phänomen unter OPNsense 23.7.6 und brauche bei der Lösung Hilfe,
da ich es trotz Foren Suche und Google bisher nicht lösen konnte.

OPNsense läuft in einer VM auf einem Proxmox Host. Auf dem Host ist SR-IOV aktiviert.
Es werden 5 igb- und 3 ix-Interfaces per passthrough in die OPNsense VM durchgereicht.
Da das vierte ix Interface mit dem Durchreichen als Ganzes Probleme macht, sind auf diesem Interface 5 virtual functions (ixv) konfiguriert, die ebenfalls in die OPNsense VM durchgereicht werden.

Auf jedem der 3 ix Interfaces ix0 bis ix2 ist in der OPNsense VM ein vlan mit der VID 10 eingerichtet.
Bei den vf Interfaces sind die vlans auf dem Proxmox Host eingerichtet, u.a. auch eins mit der VID 10, das in OPNsense den Namen ixv0 hat.

In OPNsense habe ich eine Bridge aus ix0, ix1, ix2 und ixv0 erstellt, dieser Bridge die Mac Adresse des vf Interfaces gegeben und anschließend diese Bridge als mein LAN Interface zugewiesen, sowie die VM neugestartet.
Die Zuteilung der Mac Adresse hängt mit dem vf Interface zusammen.

Nach dem Neustart kann ich mich auf den Interfaces ix0 bis ix2 mit der VM verbinden. Auf dem Port an dem das vf Interface ixv0 hängt klappt dies nicht.
Im ersten Screenshot sieht man auch, dass mein Rechner dort keine IP-Adresse erhält. Logge ich mich über Proxmox auf der Konsole der VM ein, sehe ich, dass das Interface ixv0 in der Bridge fehlt.
Füge ich das Interface händisch der Bridge mit:

Code: [Select]

ifconfig bridge0 adds ixv0hinzu, erhalte ich kurz darauf eine IP-Adresse und kann auf das Webinterface der OPNsense zu greifen.

Nun die Frage. Warum fehlt das Interface ixv0 in der Bridge und wie kann ich das abstellen?

Danke schon mal für's Lesen.

5

22.1 Legacy Series / Re: [Solved] Clients don't get an IPv6 address

« on: January 26, 2023, 09:23:17 pm »

I had this issue too and enabled link-local address on all my bridge interfaces. That solved the issue.

Many Thanks to Rob_H!

6

19.1 Legacy Series / [SOLVED] ssl handshake errors between unbound and DNSoverTLS enabled forwarders

« on: March 08, 2019, 10:24:43 pm »

I found a solution for my issue. I added following line to a server block and afterwards the name resolution works.

Code: [Select]

tls-cert-bundle: /etc/ssl/cert.pem


7

19.1 Legacy Series / Re: ssl handshake errors between unbound and DNSoverTLS enabled forwarders

« on: March 08, 2019, 09:05:16 pm »

Thanks for your answer but it didn't help. The system clock is in sync.

8

19.1 Legacy Series / [SOLVED] ssl handshake errors between unbound and DNSoverTLS enabled forwarders

« on: March 07, 2019, 08:10:15 pm »

I upgraded my firewall from 18.7.10 to 19.1.2. Now I have an issue with unbound and forwarders via DNSoverTLS.
Unbound starts and is listening on all ips but doesn't resolv any requested names. The unbound log has entries like this:

[1551968079] unbound[33902:1] debug: iterator[module 1] operate: extstate:module_state_initial event:module_event_pass         
[1551968079] unbound[33902:1] info: resolving 0.freebsd.pool.ntp.org. AAAA IN                                                   
[1551968079] unbound[33902:1] info: processQueryTargets: 0.freebsd.pool.ntp.org. AAAA IN                                       
[1551968079] unbound[33902:1] info: sending query: 0.freebsd.pool.ntp.org. AAAA IN                                             
[1551968079] unbound[33902:1] debug: sending to target: <.> 9.9.9.9#853                                                         
[1551968079] unbound[33902:1] debug: cache memory msg=132120 rrset=132120 infra=10617 val=132336                               
[1551968079] unbound[33902:1] error: ssl handshake failed crypto error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed                                                                                                             
[1551968079] unbound[33902:1] notice: ssl handshake failed 9.9.9.9 port 853                                                     
[1551968079] unbound[33902:1] debug: outnettcp got tcp error -1                                                                 
[1551968079] unbound[33902:1] debug: tcp error for address 9.9.9.9 port 853                                                     
[1551968079] unbound[33902:1] debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_noreply

The happens with flavour default and OpenSSL. I didn't try LibreSSL, because I had problems with it under FreeBSD in the past and switched back to OpenSSL.

I reinstalled the ca_root_nss package without luck.

Any ideas how can I solve this issue?