Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - meyergru

#4246
Google Authenticator ist nur eine Möglichkeit für die Authentifizierung per TOTP (RFC 4226), es gibt einige andere Software-Lösungen:

https://www.kaspersky.de/blog/best-authenticator-apps-2022/27947/

Und natürlich gibt es auch Hardware-Lösungen dafür, z.B: von Reiner SCT, Token2, Protectimus und anderen, suche einfach nach "TOTP Hardware". Die Einrichtung erfolgt genauso wie mit der App, wenn das Gerät eine Kamera hat, an sich ist der Seed aber nur ein String, der auch anders eingebracht werden könnte.

#4247
As I expected. Ethernet MTU is 1500 or 1460 bytes and PPP takes another 8 bytes, so the calculated MTU of 1452 seems about right.

Same thing here, except that my physical ethernet interface can do >=1500 bytes minus PPP, so my calculated value is 1492.
#4248
I just tried and any MTU that was larger than the physical interface cannot accomodate is overruled.

Your hardware probably has an MTU of 1460 and there is a VLAN oder PPPoE around it (or a VPN tunnel).
#4249
Quote from: Flamez on May 03, 2022, 02:28:50 AM
My fiber ONT is a 10-gig model # 621 XGS-PON ONT.  It has a 10 Gbps ethernet port.

To benefit from the additional speed, I would need to upgrade my current USW-24-G1 switch and add 10-gig card to my OPNsense box and any additional computers in my house.

Any suggestions on what equipment to purchase?   What about 2.5 gig cards?  How about only adding the 10-gig card to my OPNsense box, NAS and one computer.

I am looking for any suggestions.

First, a few comments:

1. I envy you.
2. 10 GbE over RJ45 has a serious problem: it draws 1 Watt per port or 2 Watts per connection. That is why whenever possible, you should use DAC cables with SFP+, altough that can only support 10 GBit/s. Alas, Adtran's 621 does not offer that and it seems to have 10 GbE only with no support for 2.5 or 5 GBit/s.
3. 2.5 GbE technology has much less power draw, is cheaper, is supported by more and more common equipment and can be run over existing CAT.5 cabling (unlike 10 GbE). Been there - done that.

You could go with a Mikrotik CRS309-1G-8S+IN and use SFP+ Modules that can support 1, 2.5, 5 and 10 GBit/s.
Considering your internet plan at 2 GBit/s, I would prefer a Ubiquiti USW-Enterprise-24-PoE for obvious reasons.

However, that does not solve the problem you have with the OpnSense machine itself. That must be capable to connect at 10 GbE over RJ45 to the Adtran and to transport it over at (preferably) 10 GbE to the switch.
The machine in question must have a lot of punch to be able to route / firewall at 2 GBit/s and preferably has a small power draw.
You could use a Deciso DEC 7x0 or 8x0 for that, it has to be a machine that offers at least 2 SFP+ ports, one with a DAC cable to the switch and one with an SFP+ module for RJ45 to the Adtran.

#4250
There is a default rule that allows anything coming from the LAN that is automatically created on install, did you disable that?

If not, do you have an (automatic or specific) outbound NAT rule for your LAN being too general?
#4251
I do not let the system DNS servers be served to local interfaces via DHCP, but instead present only the firewall IP there. And when I uncheck the box, I can see that on my OpnSense, /etc/resolv.conf does contain my ISPs name servers.

The first line is 127.0.0.1, but that is expected for local name resolution. I do not use unbound, however, but dnsmasq.

If you are sure that this is a bug, you can file a bug report on github.
#4252
Uncheck System->Settings->General->"Allow DNS server list to be overridden by DHCP/PPP on WAN".
#4253
For example, radvd needs a MAC to assign an EUI-64, because the lower 64 bits are made up based on that.
Since bridges do not have a MAC per default, that assignment cannot be made.
#4254
Du hast Deine Zugangsnummer ja teilweise verschleiert, ich erkenne aber, dass sie mit "H1un1" beginnt.
Sind die 1&1-Zugangsdaten nicht immer "H1und1/<login>@online.de"?

#4255
The IPv6 selection for outgoing connections is very simple: Use the outgoing interface's address if available, otherwise choose a "preferred" address (in OpnSense you can select that, but not with a dynamic prefix) or, as a last resort, choose the lowest routable IPv6 address in the system.

That way, you can actually use the LAN address by just choosing a "track6" prefix for the LAN address as the lowest one for all local interfaces. The lower 64 bits can be chosen via the MAC address.

That is how I do it. Also, I use a DynDNS service that only updates the /56 prefix of the entry with the dynamic prefix. I already know the lower 72 Bits set that manually. Together with dynamic IPv6 prefix aliases in OpnSense, I can reach whatever I like - even LAN clients, the only thing that is different there is the lower 72 Bits.
 
#4256
Letztlich läuft es darauf hinaus, welche Form der Anbindung, also physisch: GPON, DSL o.ä. und logisch (z.B. PPPoE oder DHCP) der Provider anbietet.

Da in Deutschland grundsätzlich "Routerfreiheit" besteht (tatsächlich meint das so sogar das Recht auf passiven Netzwerkübergabepunkt), sind die Provider verpflichtet, eine technische Schnittstellenbeschreibung herauszugeben, aus der hervorgeht, wie Du den Anschluss machen kannst. Danach solltest Du fragen.

Andererseits ist das für den Einsatz von OpnSense letztlich egal, weil es die üblichen Anschlussarten "kann".
Eine Fritzbox benötigt man selbst bei DSL nicht, es gibt ja reine DSL-Modems. Auch muss man den GPON-ONT des Providers nicht akzeptieren, nur wüsste ich nicht, weshalb nicht, wenn der gratis zur Verfügung gestellt wird.
#4258
An die Geschichte mit dem Routing hatte ich noch gar nicht gedacht, mein Verdacht für den out-of-state traffic war eher eine fehlerhafte/unvollständige Implementierung des TCP-Stacks auf Embedded Hardware, so was kommt bei MQTT ja schon mal vor.

Könnte es sein, dass da eine zu weit greifende NAT-Regel feuert und die Absenderadressen vom VLAN 20 ins LAN verbiegt?
#4259
In der Theorie könnte jemand jetzt TCP-Pakete vom VLAN 20 (vermutlich IoT-Netz?) ins LAN außer der Reihe senden, aber wie wahrscheinlich ist das schon?

Man könnte durch Paket-Traces nachvollziehen, was die MQTT-Clients genau falsch machen und nur dies zulassen, um das weiter einzugrenzen, aber das Risiko ist doch sehr begrenzt.
#4260
Ich würde mal mit "state type" spielen...