Messages

91

German - Deutsch / Re: Verbindungsabbrüche ins Internet nach 3 minuten

« on: December 02, 2023, 02:10:47 pm »

Das klingt doch eher nach einem Timeout oder Powersafe. Allerdings ist die Fehlerbeschreibung mehr als vage...

Was bedeuted "Ist alles dicht"?
Wie ist Dein Rechner konfiguriert? Per DHCP?

Kannst Du im Fehlerfall die OPNSense per "ping" erreichen? Den Switch? Die FritzBox? Einen Host im Internet?
Bleibe erst mal beim grundsätzlichen ping, dann fummelt da kein DNS oder DHCP rum.

/KNEBB

92

German - Deutsch / Re: zu doof für Vlan?

« on: December 01, 2023, 08:26:04 pm »

Isso. Kannst du hier im Forum ohne Ende nachlesen. Glaub bitte Leuten, die seit 30 Jahren FreeBSD machen ...

Du willst mir also sagen, dass BSD sich nicht an seit 9 Jahren NICHT an die Industriestandards 802.1Q hält? 

Ich kenne solche Erfahrungen grundsätzlich, aber ist das wirklich noch immer so? Kann ich mir nicht vorstellen (und funktioniert hier auch einwandfrei).

/KNEBB

93

German - Deutsch / Re: zu doof für Vlan?

« on: December 01, 2023, 06:47:37 pm »

Neeee.... so wird das nix

Erst mal muss uns klar werden, wie das bei Dir aktuell ist und wie es aussehen soll. Was ist WAN? Was ist LAN? Du willst ein weiteres Netzwerk als VLAN einrichten auf der LAN-Seite, richtig? Dann reicht es, dieses Netz als VLAN zu bauen, das andere LAN bleibt wie es ist.

Nochmal grundsätzlich zur Erklärung (leider verwenden die Switch-Hersteller uneinheitliche Begriffe):
VLAN-Erkennung basiert auf einem sogenannten "VLAN-Tag". Derjenige, der ein NEtzwerkpaket empfängt, kann anhand des Tags erkennen, zu welchem VLAN das Paket gehört. Das gilt eingehend.
Ausgehend ist es so, dass der Switch (bzw. OPNSense) wissen muss, zu welchem VLAN das Paket, was er gerade versenden will gehört. Dementsprechend setzt er das Tag.

Es gibt also bei Switchen normalerweise nur drei mögliche Konfigurationen pro VLAN:
"Untagged" - Das Paket wird ohne ein Tag gesendet, eingehende Pakete bekommen das VLAN-Tag
"Tagged" - Das Paket bekommt ein Tag und wird gesendet, eingehende MÜSSEN das richtige VLAN-Tag haben, sonst wird dieses Paket nicht diesem VLAN zugeordnet.
"Forbidden" - Wenn ein Paket mit Tag reinkommt, wird es verworfen.

Und in dieser Konfiguration können Switch- und OPNSense Port sein.
Ich nehme mal die Glaskugel und vermute, dass Du auf Deiner LAN-Seite drei Netzwerke haben möchtest?
Dann konfigurierts Du eine Schnittstelle als "normal", also ohne VLAN-Konfiguration.
Dann gehst Du bei der OPNSense unter Schnittstellen in "Andere Typen" - "VLAN" und erstellst ein VLAN, vergibst also die Nummer und ordnest dem VLAN ein "Parent" zu, also Deine physikalische LAN-Karte.
Dadurch hast Du dann folgendes:
LAN - kein Tag - eingehende Pakete ohne Tag werden diesem VLAN zugeordnet, ausgehende Pakete bekommen keinen Tag (ist meist VLAN 1).
VLAN200 - Tag 200 - Ausgehende Pakete bekommen Tag 200 - eingehende mit Tag 200 werden akzeptiert
VLAN178 - Tag 178 - Ausgehende Pakete bekommen Tag 178 - eingehende mit Tag 178 werden akzeptiert

Nun muss Dein Switch Port noch passend konfiguriert werden. Also der Port, an dem das Kabel Deiner LAN-Schnittstelle in den Switch geht. Ich vermute Port 31.
Den musst Du so genauso konfigurieren:
Untagged - LAN bzw VLAN1
VLAN200 als Tagged
VLAN178 als Tagged

Das sollte dann schon mal passen (BTW: der Switch muss keine Netzwerkadresse zum Management in diesen VLANs bekommen!)

Und jetzt musst du aufpassen, wie Du die anderen (!) Ports konfigurierst, die Teil der VLANs sein sollen:
Die Ports im LAN:Untagged (VLAN1), die beiden anderen VLANs forbidden
VLAN200 - Untagged 200, VLAN1 und VLAN178 forbidden
VLAN178 - Untagged 178, VLAN1 und VLAN200 forbidden
Idee ist, dass Deine Endgeräte garnicht mitbekommen, dass sie in einem anderne VLAN hängen (und deshalb auch keinen Tag setzen). Das Taggen übernimmt der Switch.

Und jetzt Begrifflichkeiten:
"Trunk" ist oft gemeint, dass der Switch VLANs akzeptiert (die man dann noch definieren muss, welche Tagged und welche Untagged oder Forbidden sidn).
"Access" meint, dass der Switch auf diesem Port nur ein VLAN akzeptiert, die Pakete ungetagged raussendet, eingehende Pakete bekommen aber das konfigurierte VLAN-Tag.

Hilft das?

/KNEBB

94

German - Deutsch / Re: Hilfe: Fritz!Box mit VoIP HINTER OPNsense - VLAN je für Daten und VoIP

« on: November 26, 2023, 02:18:43 pm »

Moin,
auch mal meinen Senf dazu. Dir Fritz! ist ein tolles Teil, aber aufgrund des Zieles der einfachen Konfigurierbarkeit halt auch nur auf "Standard" ausgelegt.
Und der Standard ist, dass die Fritz! eben direkt am Internet hängt, keine OPNSense davor.

Ich vermute, dass Du den WAN-Port der Fritz nicht angeschlossen hast? In dem Fall kenn die Fritz! wahrscheinlich kein Default Gateway (da ja LAN und sie selbst per Default das Gateway ist). Deshalb kommt sie nicht aufs Internet und kann die VoIP-Sachen nicht anmelden. Ergo: Geht nicht!
Hast Du dagegen nur den WAN-Port angeschlossen, macht die Fritz! ja auf ihrem WAN-Interface ein NAT und die VoIP Geräte "verschwinden" für die OPNSense. Letztere kann dann auch kein Portforwarding (SIP/RTP etc.) fürs telefonieren machen. Zusätzlich verschickt die Fritz! das auf ihrem WAN-Interface ins VLAN 201, dass aber auf dieser Seite der OPNSense unbekannt ist. Ergo: Geht nicht!
Hast Du beides angeschlossen, so kann es erst recht nicht gehen,  weill die VoIP Geräte die Fritz! nicht als Gateway nehmen, sondern die OPNSense. Und die Fritz! erneut versucht über ihr WAN (mit NAT und VLAN) zu registrieren. Ergo: Geht erst recht nicht!

Wie könnte eine mögliche Lösung aussehen? Dafür kenne ich die Fritz! zu wenig, aber vielleicht ja so:
In der OPNSense alles, was aus VLAN201 kommt komplett (alle Ports, dedicated Host) auf die lokale IP des Fritz!WAN durchreichen. Auf der Fritz das VLAN auf ein ungenutzes (zB 7 oder 42) VLAN setzen und der OPNSense eben auch dieses VLAN konfigurieren. Und die VoIP Geräte dann in ein weiteres, separates VLAN hinter der Fritz!.

Aber: Das ist Mega-umständlich. In dem Fall würde ich lieber auf die Fritz verzichten und die VoIP Geräte direkt konfigurieren. Wenn Du allerdings die DECt-Funktionalität der Fritz! brauchst, geht es vermutlich nur so. Alternativ kannst Du die Fritz! vielleicht auch direkt zusätzlich noch an das Modem hängen, aber das wird vermutlich nicht klappen.



Grundsätzlich: VLAN=genau ein IP-Adressbereich. Ein Routing innerhalb eines VLANs geht nicht...

Grüße!

/KNEBB

95

German - Deutsch / Re: InterfaceDiag/Ping WTF?

« on: November 26, 2023, 01:49:59 pm »

Moin,

"sendto: Permission denied" :
ich möchte wetten, dass in der Interface- oder Firewall-Konfiguration irgendwetwas komplett daneben konfiguriert ist.
Alles, was man dazu im NEtz findet, geht in diese Richtung.
Schicke uns Deine Konfiguration udn ich bin sicher, da ist etwas "verquer".

/KNEBB

96

Tutorials and FAQs / Hint: Multi-WAN and some IoT vendors

« on: November 23, 2023, 01:25:49 pm »

Hi all,

just as a hint if some of you guys face similar issues.

I have a multi-WAN setup (so two different external IP addresses)My two gateways are configured in a group with same tier and round-robin enabled. It really works fine (despite of the dpinger issue to reset the DSL interface daily).

However, I have two IoT devices from iRobot which live in a separated VLAN but with full Internet access.

Since enabling my multiWAN I had serious connection errors in the app. One device was always connecting while the second one only rarely. I got "no connection" in the app very frequent.

I had a gut it is related to multi-WAN. So I created a second gateway group with my two interfaces but set one to tier1 and the second to tier2. And, tataaaa: my second device get a connection every time.


So there must be some logic on the vendor's side to have both devices on the same IP-address?

I don't know- just in case you have something similar, make sure your two devices use the same gateway.

/KNEBB

97

23.7 Legacy Series / Re: 23.7.8 crashes periodically and unbound reporting becomes inactive. Need assist.

« on: November 23, 2023, 10:53:28 am »

Hi,

I gues you configured something with an static ARP entry. The message you see above comes from arp trying to insert such an entry.

Check if you have something like this configured (and you possibly changed IPs since them).

See this thread, it might be helpful in finding such entries.

/KNEBB

98

23.7 Legacy Series / Re: Alias Name vs. Host Name

« on: November 22, 2023, 12:16:25 pm »

Well, this can be discussed. According to latest RFC (see link in first post) there are no such limitations in DNS!
[Yes, many clients and even servers still implement the "old" limitation but shouldn't we focus on the up-to-date ones?]

Still no answer why such a limitation exists in the alias tables?

/KNEBB

99

23.7 Legacy Series / Re: Alias Name vs. Host Name

« on: November 22, 2023, 12:07:17 pm »

Sorry,

you are right. I mixed it up. It was the other way.
No underscore in Unbound, no Hyphen in Aliases.

Sorry for confusion...
/KNEBB

100

23.7 Legacy Series / Alias Name vs. Host Name

« on: November 22, 2023, 11:34:54 am »

Hi,

in firewall I make use of "Aliases". It is not allowed to use an alias name with an underscore ("_" - for what reason?).

Now I created an alias which points to a hostname. Which is configured in UnboundDNS as overwrite. In Unbound, I can not create a hostname with a Hyphen ("-").

This is at least somehow confusing as I am always getting dizzy of which hostname is now the correct one.

Regarding to RFC 2181 there is no such limitation on the hostname. Hostname can have either "-" or "_".

There should be either in alias more characters be allowed or let unbound allow correct hostnames.

Any thoughts?

/KNEBB

101

23.7 Legacy Series / Re: Dpinger broken

« on: November 17, 2023, 06:16:58 am »

Hi,

is someone going to report a bug for this?

I use 23.7.8_1 and still have to dis- and re-enable the DSL device manually.

Thanks!

/KNEBB

102

23.7 Legacy Series / Re: Dpinger broken

« on: November 12, 2023, 10:19:02 am »

Hi,

just to add another "same for me" to this thread:

I have a MultiWAN setup, too. One line fibre with DHCP and static IP and the other a DSL leased line with periodic reset every 24h.
When the reset of the DLS line appears, my MultiWAN setup will not route any traffic the the DSL line.

I have to manually disable the device and re-enable it. Once reset, the distribution is running fine again.

Someone able to fill a bug report?

/KNEBB

103

23.7 Legacy Series / Multi-WAN and dynamic IP not Compatible?

« on: November 10, 2023, 12:53:12 pm »

Hi,

I have a fixed IP fibre WAN connection (150Mbit) and one DSL dynamic IP WAN connection (100Mbit).

I configured them as Multi-WAN according to the documentation.
I put a weight of "2" to the (slower) DSL connection and a weight of 3 to the fibre line.

Once setup it works pretty fine. But as soon as the DSL line is periodically reset (every day at 5:55am) Opnsense will route only through the fibre line. Even though both gateway appear in "green" state it looks like nothing is send through DSL. Once I disable and re-enable the DSL line it starts again sending traffic through it.

This is the information I get with netflow (scroll to the right) and it shows the traffic being distributed between the two interfaces- until 5.55am. And redistributing when I reset the DSL interface at 12:30pm.


Additional question: why seems all outgoing trafic only going through the DSL line?

Anyone having an idea what might be wrong here?

Thanks
/KNEBB

104

23.7 Legacy Series / Re: Using own CA for certificates within OPNSense . How?

« on: November 06, 2023, 07:20:46 am »

I figured it out meanwhile.

Indeed this was not an issue of OPNSense but MacOS instead.

Since 2020 Apple does not allow server certificates to have a validity of more than 398 days. See here.

So I created another one with 397 days and as SAN "DNS=router.domain.zeroed"

Now it is working like a champ.

Thanks for your input!

/KNEBB

105

23.7 Legacy Series / Re: Using own CA for certificates within OPNSense . How?

« on: November 05, 2023, 09:04:56 pm »

Hi,

I did some search on the warning Safari gives and found thios topic.

So it looks like there has been some misconfiguration in the names of the server certificates which will bring this warning.

Herre I am now unsure. What should I use in my certificate?
So I have:

Code: [Select]

Subject: C = DE, ST = XX, L = XXXXX, O = XXXXXX, emailAddress = admin@domain.zeroed, CN = router.domain.zeroed
[...]
            X509v3 Subject Alternative Name:
                URI:https://router.domain.zeroed
Might be the X509v3 SAN is wrong? But I used the same which is showed in the documentation. What value should I use?

Anyone some further ideas?