VPN / routing möglich?

[r4pt0r]

Ich habe 2 Netze die per VPN verbunden sind. Netz A sei 192.168.0.0/24, Netz B sei 172.16.0.0/24.
Die (Hardware-)VPN-Router kennen _nur_ die Routen für diese Netze und lassen sich leider nicht umkonfigurieren (komplizierte Geschichte...)

Hinter jedem Router soll ein Gateway mit Firewall (shorewall) stehen. Das NET-interface jeweils mit einer IP im Netz das die VPN-Router "vorgeben", z.b. 192.168.0.2 und 172.16.0.2

DMZ und LOC an beiden Gateways sollen jeweils eigene Subnetze bekommen,
LOC.A = 10.10.0.0/24
DMZ.A = 10.10.1.0/24
LOC.B = 10.10.10.0/24
DMZ.B = 10.10.11.0/24

Lässt sich hierbei trotzdem noch ein Routing zwischen den beiden Netzen realisieren? Also z.B. von LOC.B nach DMZ.A?
An den Gatways kann ich ja nur den jeweiligen Router als Gateway eintragen, eine Route ins andere Netz scheitert mangels passender Adresse am Interface. (-> SIOCADDRT: Kein passender Prozess gefunden)
Die Pakete aus LOC.B würden zwar zum Router gelangen, aber da die Zieladresse in DMZ.A liegt, kennt der Router keine passende statische Route für diese IP.
Lassen sich mit Shorewall (oder sonstwie..) die Pakete entsprechend maskieren, dass z.B. von Gateway B alle Pakete an LOC.A und DMZ.A mit der Zieladresse von Gateway A maskiert werden und erst dort wieder in ihre tatsächliche Zieladresse demaskiert?


Eigene VPN-Tunnel (gateway-to-gateway) per OpenVPN an den Gateways konfigurieren wäre zwar eine Möglichkeit, dann hätte ich aber doppelten Overhead durch VPN, da der OpenVPN-Tunnel nochmal durch das Hardware-VPN getunnelt wird...
Oder: Software-VPN direkt durchs Internet tunneln und die Hardware-VPN-Verbindung brach liegen lassen (auch relativ sinnfrei...)

[dufty]

Und wenn Du jetzt die Netze auf
LOC.A = 10.10.0.0/25
DMZ.A = 10.10.0.128/25
verkleinerst (Location B entsprechend), dann würde es ja für ein 1:1-NAT reichen
(wenn wir mal von router- und gateway-IP absehen)

[r4pt0r]

Wäre auch eine Idee...
Die Pakete müssen dann aber noch immer durch die beiden Router die nichts von den 10.10.*.*-Netzen wissen...

[dufty]

Brauchen sie auch nicht, da die gateways das NAT übernehmen,
die Gateways hätten dann alle IPs (außer die des jeweiligen VPN-router) im 192.168.0.0/24 (bzw. 172.16.0.0/24) für sich.
Vielleicht gibt's auch noch eine elegantere Möglichkeit.

[dufty]

Eigene VPN-Tunnel (gateway-to-gateway) per OpenVPN an den Gateways konfigurieren wäre zwar eine Möglichkeit, dann hätte ich aber doppelten Overhead durch VPN, da der OpenVPN-Tunnel nochmal durch das Hardware-VPN getunnelt wird...

Den OpenVPN-Tunnel kann man auch ohne (TLS-)Verschlüsselung betreiben:
# openvpn --remote 192.168.0.2 --dev tun1 --ifconfig 10.9.8.2 10.9.8.1

Wäre vielleicht auch noch eine Möglichkeit.

[r4pt0r]

Welche tatsächlichen Nachteile (ausser etwas umständlichere Fehlersuche) würden sich aus eine Konfiguration mit allen 3 Interfaces (LOC, DMZ und NET) der Gateways im jeweils selben IP-Netz ergeben?
Shorewall ließe ja sogar eine Zonenzuordnung via IP-Bereich zu, pysische Trennung der Netzbereiche wäre auch realisierbar, da die Server in der DMZ in beiden Netzen Virtualisiert sind, sprich an einer Virtuellen Netzwerkbrücke hängen. Alles was zur LOC-Zone gehört hängt wieder über physischen Netzwerkschnittstellen an Switches, die keine direkte Verbindung mehr zu den VPN-Routern haben werden. Somit _muss_ jeglicher Verkehr zwischen LOC <-> DMZ <-> NET über den Gateway...

Somit wäre das Routing auf jeden Fall sichergestellt, da keine IP-Netze geroutet werden müssen die den VPN-Routern unbekannt sind...


Meine Testumgebung beinhaltet leider aktuell nur "ein Ende" (gateway + testserver in DMZ + testclient in LOC), daher müsste ich zum Testen erst nochmal einen gateway + netzserver in der DMZ + client in der LOC-Zone aufsetzen - das verhalten der VPN-Router ist dann aber immer noch fraglich. Jegliche Bemühungen zumindest grundlegende Infos zur Konfiguration zu bekommen liefen bisher immer gegen eine Wand (deshalb sollen die Dinger auch als nicht vertrauenswürdig in der NET-Zone bleiben und werden genauestens überwacht...)

[dufty]

Da das Gateway jetzt nicht mehr routen kann, ist es eine Bridge, genauer eine bridged Firewall mit 3 interfaces.
Was macht das Gateway, wenn es Paket von der anderen Lokation zu einer IP, dessen Mac sie noch nicht gelernt hat, erhält? Nach DMZ oder doch nach LOC schicken?
Hört sich nach einigem Gefummel an ...

[DynaBlaster]

Ich würe auch die VPN-Lösung zwischen den Gateways an LOC.A und LOC.B über das jeweilige NET-Interface empfehlen. Bei einem OpenVPN-Tunnel hättest du auf beiden Gateway ein tun0-Interface und könnetst die entsprechenden Routen in die anderen Netze problemlos über dieses Interface setzen. Mit dem netten Nebeneffekt, das du sogar noch den Verkehr zwischen Endpunkten vor den "nicht vertrauenswürdigen Hardware-Routern" verschlüsselst.

[dufty]

Mit dem netten Nebeneffekt, das du sogar noch den Verkehr zwischen Endpunkten vor den "nicht vertrauenswürdigen Hardware-Routern" verschlüsselst.

Wenn ich den "vpn-Dienstleister" nicht vertraue, sollte ich wechseln oder es selber machen
Was anderes macht kein Sinn, Geld für Leistung auszugeben, die ich eh' nicht benutze.

***

In Anlehnung an http://www.kumanov.com/software/shorewa ... _guide.htm
könnte man wohl auch ein
NET: 192.168.0.2/24
DMZ: 192.168.0.65/26
LOC: 192.168. 0.129/25
mit z. B. proxyarp basteln

[DynaBlaster]

Für mich sieht das eher so aus, das der Aufrtaggeber von r4pt0r seinen Dienstleister gewechselt hat und jetzt r4ptor die HW-VPN-Router an der Backe hat. Dummerweise aber ohne Zugangsdaten/Kennwörter bzw. Dokumentation.vom vorherigen Dienstleister/Administrator ...

[dufty]

Für mich sieht das eher so aus, das der Aufrtaggeber von r4pt0r seinen Dienstleister gewechselt hat und jetzt r4ptor die HW-VPN-Router an der Backe hat. Dummerweise aber ohne Zugangsdaten/Kennwörter bzw. Dokumentation.vom vorherigen Dienstleister/Administrator ...

Wenn dies wäre, wäre es nicht sehr verantwortungsvoll, zwei Kisten zu "betreiben", die dann jederzeit von einem Fremden geändert werden könnnten ...
Jede z. B. Cisco-Schüssel kann man zurücksetzen.
Ist das in diesem Fall nicht möglich, kann man ihnen nicht vertrauen und gehören ersetzt.
IMnsHO.

[r4pt0r]

Hatte den thread ganz vergessen

Ursache ist kein dienstleisterwechsel o.ä. - die VPN-Verwaltung wird von einer externen Firma verwaltet, die auch die bankdienstleistungen betreut die über diese VPN-verbindung laufen. Sprich neben unserne 3 Niederlassungen hängt da auch noch deren Server drin und routet dann die Daten der Bankanwendungen.
Aus dem Grund rücken die nichtmal die kleinsten details zur Konfiguration raus. Angeblich wird "alles" geroutet (ausser natürlich broadcasts), trotzdem gibt es ungereimtheiten wie z.b. dass sich der Router an standort B von A aus anpingen lässt, von C aus aber nicht, alles was hinterm router steht aber auch von C ganz normal erreichbar...
Ich muss unterm Strich also sowieso fast alles per blackboxing ausprobieren: Draufklopfen und schauen obs zuckt...

Vor wenigen Tagen gab es einen Ausfall da einer der router am Hauptsandort (wo auch die betriebskritischen Serveranwendungen laufen..) plötzlich den verschlüsselten Datenverkehr geblockt hatte. Lösung: aus/einschalten des Routers. Da ich aber nichtmal vernünftige Fehleranalyse betreiben kann dauerte die behebung ganze 3h in denen ich nur am Telefonieren war...

Lasse seitdem von allen 3 standorten einen SSH-tunnel zu einem externen server offen halten, sodass ich zukünftig im notfall an alle Standorte rankomme und die VPN-Verbindungen überbrücken kann.

Lange Rede kurzer sinn:
Über die VPN-Hardware soll (auch wenn das zeug hundsgemein teuer war und ca zum damals doppelten marktwert gekauft werden musste...) nur noch das allernötigste laufen, alles andere wird an den Gateways direkt per openvpn übertragen. Da die IPs der 3 standorte dynamisch sind muss das zwar über einen externen server mit fester adresse laufen, aber da ich das monitoring sowieso auch nach aussen legen will passt das...
Nervig wird dann nur wieder, dass die VPN-router die erste route im Netz sein müssen - was mir die konfiguration schon wieder verkompliziert...

[rendegast]

(Läster)

die VPN-Verwaltung wird von einer externen Firma verwaltet, die auch die bankdienstleistungen betreut die über diese VPN-verbindung laufen.

Wir haben hier auch einen solch gestellten "blackbox"-vpn-Router.
Nachdem ich einen Fehler in dessen DNS-Server feststellte,
war nach changelog klar, daß das Ding nie ein firmware-Upgrade gesehen hat.
Auf Nachfrage: "können wir nicht machen, eventuell funktioniert dann etwas nicht"
Hochbezahlte IT-Profis.

[r4pt0r]

Ja, so ähnlich sieht das hier auch aus...
Der Server für die Verkäufer/Bankanwendung eiert noch mit Suse 10.3 durch die Gegend inkl. vollständiger GUI, die Passwörter sind Sicherheitstechnisch ne absolute Katastrophe und da die Anwendung unter Java läuft frisst mir der (mittlerweile virtualisierte) Server mehr CPU-Last als die Win2008 Maschine mit MSSQL2008
Die Hardware war uraltes 08/15 Desktopzeugs ohne RAID und Backups waren auf DVD-RW "vorgesehen" aber nicht eingerichtet/aktiv...

Wenn ich mir dann die monatlichen Summen für den Servicevertrag anschaue mache ich wohl irgendwas falsch


BOT:
Werde wohl die IP-Bereiche für LOC und DMZ in komplett eigene Subnetze schieben - da scheint das Routing und Firewalling von/zu den unsicheren VPN-Routern und Server am einfachsten zu sein und die Router dürften sich am wenigsten daran stören (hoffentlich), wenn das externe interface des Gateways im passenden Subnetz sitzt. Ob alle Anwendungen auch mit NAT sauber laufen wird sich herausstellen...
Davorsetzen kann ich leider nix, da die Router per Telefonleitung die externen IP-Adressen austauschen, somit bleiben die Router leider trotzdem SPOF an allen 3 Netzen...

[rendegast]

(Weiterläster)

Der Server für die Verkäufer/Bankanwendung eiert noch mit Suse 10.3 durch die Gegend inkl. vollständiger GUI,

(selber Zweck) Wurde gerade getauscht,
gegen eine Gerät mit SLES11SP1, in Release-Version! (Upgrades dafür endeten letztes Jahr).
Eine veraltete Java-Anwendung mit veraltetem jdk, mehrere andere veraltete Anwendungen zur (netzbasierten) Klickibunti-Administration, dabei weitere jre. jres und jdk horchen am Netz.
"Bitte nicht upgraden".
Hab das Ding auf SLES11SP2 aktualisiert, jres und mysql getauscht. Dürfte der einzige von hunderten sein.
Mal sehen wie sich das entwickelt.