Hi zusammen,

Falls mal jemand über das Thema fallen sollte: es gibt eine Setting am virtuellen Interface welche sich "Source/dest. check“ nennt und auf true gesetzt ist. Sobald man an der routerinstanz diesen Wert am Interface auf „false“ setzt kommen die Pakete an.

Besten Gruss,

Andreas

Am 06.03.2021 um 19:36 schrieb Andreas Roth andreas+lugdd@schosemail.de:

Hi zusammen,

Ich möchte mein lokales LAN per Wireguard mit einem LAN in AWS verknüpfen. Aufbau:

Lokaler Fuss: 192.168.53.1/24 Lokaler WG: 192.168.26.1/24

AWS WG: 192.168.26.10/24 AWS Fuss: 10.53.1.10/24

Das VPN zwischen den WG Instanzen funktioniert, ip_forward ist aktiviert, iptables deaktiviert. Nun habe ich eine weitere Instanz (10.53.1.20) auf AWS im gleichem Subnet erstellt. Im AWS Routingtable habe ich einen Routingeintrag für 192.168.0.0/16 auf die Wireguard Instanz gesetzt und bekomme sie als „aktiv“ gekennzeichnet. Wenn ich nun von der Instanz 10.53.1.20 das AWS WG Interface versuche zu pingen bekomme ich keine Antwort. Von allen anderen IPs, mit Ausnahme des AWS Fusses der WG Instanz auch nicht. Ein tcpdump auf dem AWS Fuss zeigt mir keine ankommenden Pakete. .

An der VPC ist 10.53.0.0/16 hinterlegt, am Subnet 10.53.1.0/24, networkACLs sind auf „allow all“, Securitygroup ist für ICMP von überall geöffnet. Für mich sieht es dennoch so aus, als wenn AWS irgendwo die Pakete zu 192.168.26.0/24 gehen „frisst“, finde aber nicht die richtige Setting.

Any hints?

Danke im Voraus und Gruss,

Andreas