firasec
Goto Top

Weigth-based routing?

Hallo,

Folgende Situation ist gegeben:
Ich habe ein funktionierendes Site-To-Site-VPN zwischen Firma (172.16.0.0/12) und AWS (10.1.0.0/16).
Nun müsste eine andere Firma ebenfalls ein Site-To-Site zum gleichen Netz in AWS aufbauen. Das Problem ist, dass deren internes Netz 172.18.0.0/16 hat, wie auch eines unserer Firma.
Traffic geht nur von den beiden Firmen in Richtung AWS, nicht von AWS in irgendein Firmennetz!
Und natürlich auch nicht von Fremdfirma zu Firma vice versa.

verm. Lösung 1:
Ich nehme an, dass man auf der Seite der anderen Firma das Gateway so konfigurieren kann, dass Traffic an das IPsec-Interface genattet wird, z.B. auf die 192.168.1.0/24. Auf AWS-Seite müsste das remote network für die VPN-Verbindung dann vermutlich auf 192.168.1.0/24 konfiguriert werden. Traffic muss nur von Fremdfirma nach AWS fliessen, andersrum ist nicht vorgesehen.

verm. Lösung 2:
Da die Fremdfirma nur ein paar Clients hat, die alle in das Netz 172.18.0.0/24 passen, wäre es doch bestimmt möglich, auf AWS-Seite mit einem Routing zu arbeiten, dass die Route 172.18.0.0/24->AWS-VPN-GW-FREMDFIRMA (2) höher gewichtet ist als die Route 172.16.0.0/12 -> AWS-VPN-GW-FIRMA (1).

Client A von Firma (172.18.60.1/16) greift auf AWS-Datenbank zu (10.1.1.1) -> Rückroute über (1), da Route 172.16.0.0/12 aktiv.
Client AA von Fremdfirma (172.18.0.1/24) greift auf AWS-Datenbank zu (10.1.1.1) -> Rückroute über (2), da Route 172.18.0.0/24 höher gewichtet.

Bei uns gibts keine Clients, die in der Range 172.18.0.1-254 liegen, daher sollte das keine Probleme geben.
Lösung zwei würde ich bevorzugen, wenn das machbar wäre, da dann auf das NAT in der Fremdfirma verzichtet werden könnte.

Kann man das so machen, insb. Lösung 2?
Vielen Dank schon mal!

EDIT: IP-Adressen nach RFC 1918 angepasst

Content-Key: 62346840625

Url: https://administrator.de/contentid/62346840625

Printed on: February 23, 2024 at 06:02 o'clock

Member: SeaStorm
Solution SeaStorm Nov 13, 2023 updated at 13:01:06 (UTC)
Goto Top
Hi

geht beides.
1) wäre 1to1NAT
2) ist einfaches Routing. Die "präziesere" Routinginfo gewinnt. Du routest 172.8.0.0/16 mit eurem Traffic auf euer gewünschtes Interface. Sofern 172.8.0.0/24 bei euch nicht verwendet wird kannst du das stinknormal mit der gleichen Prio/Distance einfach auf "deren" VPN-Interface routen. Das greift dann einfach deshalb weil es mit /24 die "genauere" Definition als das /16er Netz hat.
Alle anderen Netze in dem /16er gehen dennoch weiterhin auf euer Interface
Member: Firasec
Firasec Nov 13, 2023 at 13:54:50 (UTC)
Goto Top
Danke für die schnelle Antwort. Das wollte ich hören!
Member: aqui
aqui Nov 13, 2023 updated at 17:06:41 (UTC)
Goto Top
Öffentliche IP Adressen die dir gar nicht gehören unrechtmäßig aktiv zu nutzen ist aber auch, gelinde gesagt, nicht die feine englische Art.
Wenn, dann solltest du immer die RFC Range 172.16.0.0/12 nutzen. Ansonsten wirst du immer und immer wieder Probleme mit der VPN Adressierung bekommen. Ggf. sogar rechtlich mit dem offiziellen Inhaber dieser Adressrange:
NetRange: 172.0.0.0 - 172.15.255.255
CIDR: 172.0.0.0/12
NetName: SIS-80-8-2012
NetType: Direct Allocation
OriginAS: AS7132
Organization: AT&T Corp. (AC-3280)

Spricht für mehr als schlampiges VPN IP Adressdesign im Vorfeld und hausgemachte Probleme. face-sad
Ob es dann zusätzlich auch noch besonders intelligent ist eine komplette /8er Range eines fremden IP Netzes in einem VPN zu routen obwohl es auch granularer ohne die /16er Range ginge, sei auch mal dahingestellt.
Das dann alles mit 1:1 NAT wieder hinfrickeln zu wollen spricht ebenfalls für sich...aber egal. face-sad
Bei uns gibts keine Clients, die in der Range 172.8.0.1-254 liegen
Warum sparst du dann das 172.8.0.0 /24er Netz dann nicht ganz einfach aus in deiner eigenen VPN Peer Definition und weist es der anderen Firma zu? Problem gelöst und wäre ja noch einfacher.
Sofern man die gruselige IP Adressieung mit unrechtmäßigen IP Adressen grundsätzlich mal außer Acht lässt. face-sad
Mitglied: 8585324113
8585324113 Nov 13, 2023 at 18:07:42 (UTC)
Goto Top
Warum teilt ihr euch nicht 0.0.0.0/0?
Das würde alles viel einfacher machen.

Montag ist heute Freitag.
Member: aqui
aqui Nov 26, 2023 at 14:01:00 (UTC)
Goto Top