Messages

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.

Ok, KEA DHCP:

Der Control Agent sollte aktiv sein, auf Port 127.0.0.1:8000 .
DHCP Peer konfiguriert mit primary und secondary mit IP Adressen und auch auf Port 8000 .

DHCP hat nichts mit CARP zu tun, das wird unabhängig davon geclustert.

That seems reasonable. I'd go for the MS-01.

Or you can check out things like private VLANs or port isolation.

But the IP standard assumes that devices in the same subnet can communicate with each other via layer 2.

I-226V works very well for me.

It works when Router Advertisements are set to unmanaged.

I'm fairly sure hat DHCPv6 can not advertise more than one address range.