Messages

Also zunächst mal bedeutet igbX und ixX, dass es sich um unterschiedliche Treiber handelt, was insofern seltsam ist, als das ix der Intel-Treiber für 10 Gbit ist, während igb für die normalen 1 GBit-Anschlüsse wäre. Die Sophos hat aber m.W. keine 10 GBit Ports.

Ich hatte mal eine SG125 rev. 3 und bin da auch drüber gestolpert. Der Grund ist, dass der verbaute Chip ein X5xx Chip ist und es davon auch Sparversionen von Intel gibt. Ich meine Sophos verbaute den X553 in der SG125. Der kann auch Hardwarevirtualisierung, so dass man virtuelle Interfaces erstellen kann, bis zu 63, plus dem ,echten' sind es 64, die intern über einen 10GBit/s Switch verbunden sind. Beim genannten X553 ist der Phy nur für 1GBit/s ausgelegt, so dass nach draußen nicht mehr geht, intern kommunizieren die virtuellen Interfaces mit 10GBit/s

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 Expand


#!/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.

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.

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.

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 Expand

ifconfig bridge0 adds ixv0
hinzu, 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.

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

Many Thanks to Rob_H!

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

Code Select Expand


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


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

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?