Messages

Die X520 ist nur PciE 2.0, d.h. du brauchst 8 lanes, um die vernünftig zu betreiben.

Ansonsten gibt es eine breite Auswahl an verschiedenen Karten und Herstellern - persönlich mag ich Mellanox, die sind verhältnismäßig effizient (lies: kühl), und kompatibel, und es gibt sie billig auf ebay - was eher für Privatanwender ein Kriterium ist.

To a more general point - are you sure that you need a transparent bridge? We have that discussion comparably often, and it's not a recommended setup.

By Dave, the OP ment Dave Plummer.
Basically a legend of a developer that worked on Early versions of windows and is the creator of the task manager If I remember correctly.

I'm sure a Microsoft programmer gives the best advice on networking. A general rule of mine is not to let software developers mess with the network, if possible.

Nobody I know including myself with experience in firewalls and networks runs a transparent bridge. It's incredibly difficult, error prone, and unreliable. So I cannot give any advice but "don't".

That Dave guy on youtube made a video about transparent bridging in which he claims it to be the best thing since sliced bread. Unfortunately.

Sure, but why?

Hallo zusammen,

ich habe heute auf meiner Synology im Docker einen Vaultwarden aufgesetzt. Nun wollte ich aber nicht den Reserve Proxy und die SSL Abhandlung von der Synology nutzen, sondern das meiner Firewall und nginx überlassen. Also habe ich heute selbiges frisch installiert auf der Opnsense und wollte es einrichten.

Aber nach einem gesamten Tag konfigurieren und wirklich so gar keinem Erfolg (ausser beim Synology mit SSL Zertifikat von meiner Domain und Reverse Proxy inklusive NAT und Outbound NAT auf Opnsense vollkommen funktional) fiel mir auf, dass im Dashboard ständig im Live Log "WARNING: failed to setup nginx" auftaucht. Eine Reinstallation half nichts und zu dem Fehler finde ich auch nicht vernünftiges.

Hat dazu jemand eine Idee?

Normalerweise würde der nicht starten, weil die Konfiguration ein Problem hat.

If it's site2site, use a suitably long PSK.

IPSec is bad enough without using certificates, unfortunately.

Speaking as the one who does the level 3 ipsec support at my employer.

spanning-tree portfast?

Pretty much, but I would like to add the following:

2001:db8:ffff:ff00:0000:0000:0000:0000/56 != 2001:db8:ffff:ff::0/56
2001:db8:ffff:ff00:0000:0000:0000:0000/56 == 2001:db8:ffff:ff00::0/56

I just migrated from legacy to instances, and I used to have a TAP based tunnel routed via BGP.

server: 172.28.1.1, clients: 172.28.1.2 and 172.28.1.6

The configuration for that was client specific overrides for the clients, and a network of 172.28.1.0/28, of which the server automatically got the .1 .

So I migrated that 1:1, and the server interface would not get an IP, so that didn't work.

Switched to TUN, everything seemed fine, client can ping server, BGP session is active, but no traffic seems to be routed through the tunnel. TCPDUMP on the client says, packets are sent, TCPDUMP on the server, nothing except the unrouted traffic.

Then I switched to DCO just for the hell of it, and it works.

Any ideas? Could this be the dreaded openvpn builtin packet filter?

EDIT: On second thought, must have been the packet filter - but the question remains, why did the TAP interface not get an IP address?

This might best be solved by dynamic routing.

Wie funktioniert das denn auf dem Gateway, woher bekommt das die Empfänger Datenbank?

Es macht während des SMTP-Dialogs mit dem sendenden Server für jedes RCPT TO, bei dem die Domain mal prinzipiell in Ordnung ist, über eine zweiter Verbindung ein VRFY mit dem tatsächlichen Ziel-Server.

Alles vorgesehen im Protokoll.

Das funktioniert mit Exchange nicht, ich habe da vor einiger Zeit mal was für den Eigengebrauch gebastelt, das sich die Empfänger aus dem LDAP holt.

https://github.com/bimbar/os-ldap2postfix

Kann noch funktionieren, muss aber nicht.

I basically agree with Patrick, but if you want to do it, there are rules I would activate without too much problems - for example the abuse.ch rules. You should definitely not activate all the rules.

You should be aware that that video has serious flaws and will lead to an unreachable appliance.

In my opinion the setup as transparent filtering bridge should also only be used in very specific circumstances and is not recommended.

ISC ist abgekündigt, geht aber auch damit.