BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Das schwierige Thema VPN!
Post Reply
puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by puls » May 24th, 2019, 12:29 pm

Hallöle,

ch habe ein ähnliches Problem wie in [1] beschrieben, allerdings wechsle ich von einer Sonicwall zu IPfire. Auf der Sonicwall sind zwei VPN eingerichtet die netmapping nutzen. Dort wird unser internes Netz mit einer anderen Adresse angesprochen. Das heisst, für die Gegenstelle sind wir als 192.168.116.0/24 sichtbar, während unser Netz die 192.168.1.0/24 ist (ich weiss, eines der beliebtesten Netze der Welt, aber das ist irgendwann vor Jahren mal schnell eingerichtet worden und ein Wechsel wäre jetzt ein irrsinniger Aufwand). Die IP-Adressen werden durch eine NAT-Regel 1:1 zwischen den Netzen umgesetzt.
Allerdings nutzen wir nicht OpenVPN sondern IPsec und haben demnach weder ein eigenes interface noch einen Routingeintrag zur Verfügung. Die in [2] genannten iptables Regeln allein funktionieren leider nicht.

Folgende Regeln habe ich getestet (in verschiedenen Varianten):

Code: Select all

iptables -t nat -A CUSTOMPREROUTING -d 192.168.116.0/24 -j NETMAP --to 192.168.1.0/24
iptables -t nat -A CUSTOMPOSTROUTING -s 192.168.1.0/24 -d 10.0.0.0/24 -j NETMAP --to 192.168.116.0/24
Die erste Regel sollte mE jeden ankommenden Traffic, der an das Netz 192.168.116.0 gerichtet ist, auf die Adresse 192.168.1.0. umschreiben, egal woher der Traffic kommt. Die zweite Regel soll bei ausgehendem Traffic, der an das Netz 10.0.0.0 gerichtet ist, die Absender-IP von ...1.x nach ...116.x umschreiben. Letzteres funktioniert offenbar, da ich ohne die Einschränkung des Zielnetzes meinen Traffic in alle anderen VPN blockiere (falsche Absender-IP). Jetzt habe ich allerdings das Problem, dass offenbar kein System den Weg in das 10.0.0.0-er Netz kennt. Auch IPfire sagt mir:

Code: Select all

[root@ipfire ~]# ping 10.0.0.31
PING 10.0.0.31 (10.0.0.31) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Net Unreachable
Bei einem Ping von der Gegenseite sieht es so aus:

Code: Select all

ping 192.168.116.245
PING 192.168.116.245 (192.168.116.245) 56(84) bytes of data.
^C
--- 192.168.116.245 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11534ms
Auf IPfire sehe ich das hier:

Code: Select all

[root@ipfire ~]# tcpdump -i any net 10.0.0.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:30:23.475487 IP 10.0.0.31 > 192.168.116.245: ICMP echo request, id 13893, seq 13, length 64
13:30:24.476793 IP 10.0.0.31 > 192.168.116.245: ICMP echo request, id 13893, seq 14, length 64
13:30:25.478141 IP 10.0.0.31 > 192.168.116.245: ICMP echo request, id 13893, seq 15, length 64
13:30:26.452277 IP 10.0.0.31 > 192.168.116.245: ICMP echo request, id 13893, seq 16, length 64
Erwartet hätte ich hier eine bereits umgeschriebene Empfängeradresse und dass die Pakete zumindest an den Zielhost weitergeleitet werden. Doch dort passiert dies:

Code: Select all

tcpdump -i any net 10.0.0.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
^C
0 packets captured
11 packets received by filter
4 packets dropped by kernel
Irgendwie muss ich iptables also beibringen, dass Pakete aus dem IPsec Tunnel kommen und durch die NAT-Regel laufen sollen. Hat jemand eine Idee, was ich hier noch machen kann? So langsam bin ich am Ende meiner Weisheit. Für jeden Schubser in die ŕichtige Richtung bin ich echt dankbar!

Hier noch die Konfig des betreffenden VPN:

Code: Select all

conn GEGENSTELLE1
	left=%defaultroute
	leftsubnet=192.168.116.0/24
	leftfirewall=yes
	lefthostaccess=yes
	right=a.b.c.d
	rightsubnet=10.0.0.0/24
	leftid="z.y.x.w"
	rightid="a.b.c.d"
	type=tunnel
	ike=aes256-sha2_256-modp4096
	esp=aes256-sha2_256-modp4096
	keyexchange=ikev1
	ikelifetime=2h
	keylife=1h
	dpdaction=restart
	dpddelay=30
	dpdtimeout=120
	authby=secret
	auto=start
	fragmentation=yes

[1] viewtopic.php?f=22&t=21833
[2] https://backreference.org/2012/03/20/bi ... nat-bleah/

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by puls » May 27th, 2019, 5:06 am

Hat tatsächlich niemand eine Idee?
Ich fürchte, ich verstehe die Reihenfolge der Paketverarbeitung nicht richtig. Was passiert mit Paketen, die aus dem IPsec Tunnel herauskommen? Von wo kommen die, von IPfire aus betrachtet? Bzw von wo kommen sie aus Sicht des netfilter? Und an welcher Stelle der Filterregeln muss ich die Umschreibung einfügen, damit sie wirksam wird? Da es keine eigenen Interfaces gibt wie bei OpenVPN (tunX), müssten die Pakete doch von dem Interface kommen, dem RED zugewiesen ist. Ich bin mir recht sicher, dass ich nur einen Denkfehler mache und die Lösung relativ trivial ist, nur komme ich nicht drauf.
Diese zwei VPN, die noch genatted werden müssen, sind die einzigen offenen Baustellen nach dem Wechsel der Firewall. Aber extrem wichtige. Sollten diese VPN nicht funktionstüchtig werden, müsste ich von IPfire auf ein anderes System umsteigen, was uns nochmal um Wochen zurückwerfen würde. Das wäre, harmlos ausgedrückt, extrem ärgerlich.

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8516
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by Arne.F » May 27th, 2019, 5:18 am

Hast du ne Firewall Regel erstellt die das 10.x.x.x Netz erlaubt? Es gibt nämlich eine die diese Netze nach Red verbietet. (Außer es gibt passende Vpn Tunnel)
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by puls » May 27th, 2019, 5:26 am

Von wo nach wo müsste ich das denn zulassen? Von GREEN nach RED?
Letztlich soll der Traffic ja aus dem VPN kommen. Doch wenn ich das mit ping teste, kommen in IPfire nur Pakete mit der "falschen" Zieladresse an. Sie erreichen also IPfire, werden aber nicht umgeschrieben. An genau diesem Punkt hänge ich derzeit.

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8516
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by Arne.F » May 27th, 2019, 8:56 am

Ich würd das Interface mal rauslassen und erstmal reine IP Regeln erstellen.

192.168.1.0/24 -> 10.0.0.0/24
10.0.0.0/24 -> 192.168.116.0/24

Normal sollte er im Firewall log auch anzeigen was er verwirft...
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by puls » May 27th, 2019, 11:53 am

Diese Regeln entsprechen doch der Erlaubnis, von GREEN nach VPN X bzw von VPN X nach GREEN zugreifen zu dürfen. Diese Regeln existieren. Ausgehend auch implizit, da der Standard auf Allow gesetzt ist. GREEN darf nach überall. Im Logfile sehe ich aber nichts, was diese Pakete betrifft. Die Firewall, zumindest das was IPfire sieht, verwirft sie also nicht explizit.
Ich probiere das ganze jetzt mal mit einem IP Alias und einem SNAT in der ausgehenden Regel, vielleicht komme ich so weiter.

EDIT sagt: Dumm gelaufen
Da wir eine Dialup-Verbindung haben und die Schnittstelle ppp0 ist, kann ich keine IP Aliase anlegen. Zumindest nicht in der Oberfläche. Klappt also nicht. Dafür habe ich mal geschaut, welche offenen Verbindungen angezeigt werden (Status=>Connections). Ein eingehender ping aus dem 10.0.0.0-er Netz wird als Verbindung angezeigt aber eben mit Zieladresse 192.168.116.X. Ein ping aus unserem Netz in das 10.0.0.0-er Netz wird nicht angezeigt, was auch nicht verwunderlich ist, da der pingende Host sagt, das Netz wäre nicht erreichbar (Destination Net Unreachable). Es gehen vermutlich gar keine Pakete auf die Reise.

Der gescheiterte Versuch mit der Alias Adresse hat mich aber auf eine Idee gebracht: Wenn IPfire nicht in der Lage ist das NAT auszuführen, dann muss es eben jemand anderes machen. Jetzt versuche ich mal, die Kommunikation über einen anderen Host zu leiten. Der bekommt a) zwei Adressen zugewiesen, eine davon aus dem 192.168.116.0-er Netz und fungiert als eine Art Proxy oder b) es wird nur eine Route angelegt, die Traffic für das 10.0.0.0-er und das 192.168.116.0-er Netz dorthin leitet und der Host schreibt stur die Adressen um. In dem Fall müsste ich eigtl mit interface, source und destination arbeiten können.

ummeegge
Community Developer
Community Developer
Posts: 4986
Joined: October 9th, 2010, 10:00 am

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by ummeegge » May 28th, 2019, 7:18 am

Hi puls,
im Forum --> viewtopic.php?f=16&t=17313&start=15#p102802 wurde das mal mit dem NETMAP Target ohne Interfaces soweit positiv getestet. Der Thread wird da noch ausführlicher (kennst du event. schon) aber die Vorraussetzungen sind denke ich auch andere. Also fast die selbe Regel wie du oben schon probiert hast allerdings nur mit -d (destination) und ohne source.

Beispiel findest du so auch bei OpenVPN --> https://openvpn.net/faq/remap-local-add ... ess-range/ .

Mal als Idee.

Grüsse,

UE
Image
Image

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by puls » May 28th, 2019, 10:06 am

Moin,
den verlinkten Thread kenne ich natürlich schon und hatte anfangs gehofft, dass diese beiden einfachen Regeln das ganze Mapping schon übernehmen, Aber es klappt einfach nicht. Kurioserweise auch nicht auf einem zweiten System, über welches ich die Verbindungen testweise laufen lasse. Meine Idee war jetzt, eine Route einzurichten, die Traffic an 10.0.0.0 in unserem Netz an einen bestimmten Rechner leitet, ich nenne ihn mal LB , welcher die Absender-IP umschreibt und diese Pakete dann an IPfire (LA) übergibt. der zu erreichende HOST auf der Gegenseite sei mal RC.

Erster Anlauf: Ich weise dem Netzwerkinterface auf LB eine zweite IP zu (192.168.116.242 mit Gateway LA) und lege die iptabels Regeln an. Ich setze einen ping nach RC ab und monitore das ganze auf LA und RC mit tcpdump.

LB sagt:

Code: Select all

PING 10.0.0.31 (10.0.0.31) 56(84) bytes of data.
^C
--- 10.0.0.31 ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 10224ms
LA sagt:

Code: Select all

11:41:11.876891 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 1, length 64
11:41:12.885371 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 2, length 64
11:41:13.909326 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 3, length 64
11:41:14.933329 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 4, length 64
11:41:15.957329 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 5, length 64
11:41:16.981304 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 6, length 64
11:41:18.005347 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 7, length 64
11:41:19.029435 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 8, length 64
11:41:20.053290 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 9, length 64
11:41:21.077217 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 10, length 64
11:41:22.101278 IP 192.168.166.242 > 10.0.0.31: ICMP echo request, id 2228, seq 11, length 64
Bei RC kommt gar nichts an.

Soweit ich es sehe, kommen die Pakete mit korrekter Absender-IP bei IPfire an (LA), gehen aber nicht in den Tunnel. Warum auch immer IPfire hier so rumzickt, aber das sieht mir nach einem internen Problem uf IPfire aus. Das System scheint selbst nicht zu wissen, dass das Ziel für 10.0.0.0 am anderen Ende des Tunnels liegt.

Zweiter Anlauf: Auf meinem PC setze ich eine extra Route mit Ziel 10.0.0.0 und Gateway LB, damit dieser die Pakete umschreiben kann. Jetzt sehe ich auf LB die Pakete ankommen, aber sie scheinen weder umgeschrieben zu werden noch den Host wieder zu verlassen. :-\ Schon auf LA kommt nichts mehr an.

Langsam wird das echt frustrierend :'(

Jetzt erst mal Mittagessen, dann teste ich mit einer eigenen Gegenstelle um zu prüfen, ob umgeschriebene Pakete vielleicht doch aus dem Tunnel herauskommen und dort nicht korrekt geroutet werden. Das löst dann aber auch nicht das Problem, dass mein LB weder umschreiben noch weiterleiten mag.

ummeegge
Community Developer
Community Developer
Posts: 4986
Joined: October 9th, 2010, 10:00 am

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by ummeegge » May 28th, 2019, 10:26 am

Mmhh,
ich nutze leider kein IPSec kann dir von daher auch nicht mit Trail&Error zur Seite stehen... Es gab aber immer mal wieder Fragen bezüglich dem IPSECBLOCK (SNAT von OpenVPN in IPSec ging nicht mehr) z.b. --> viewtopic.php?t=16647 . Ich glaube das ist mittlerweile die IPSEC-Policy (IPSec FW) --> https://git.ipfire.org/?p=ipfire-2.x.gi ... ds/core132 als Anhaltspunkt mal. Wegen Routen setzen bieten sich da glaube ich die "Statischen Routen" an da sie auch über die ipsec-interfaces eingelesen werden --> https://git.ipfire.org/?p=ipfire-2.x.gi ... re132#l268 , ist leider alles sehr wage...

Sorry. Vielleicht hat der Arne ja auch noch eine Idee...

Grüsse,

UE
Image
Image

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by puls » May 28th, 2019, 10:57 am

Ich bin für jede Anregung dankbar! :)
Das mit den statischen Routen hatte ich auch mal getestet, alleine schon um ggf den DHCP-Clients die Route zum LB zuzuweisen. Das hätte dann aber diesen Effekt:
Statische Route auf IPfire sagt: Pakete an 10.0.0.0/24 gehen über 192.168.1.242
Dann müsste IPfire ankommende Pakete statt in den Tunnel wieder zurück an LB senden. Uncool!

Oder ich setze eine Route, die "auf die andere Seite des Tunnels" zeigt, aber das klappt rein logisch nicht. Denn die müsste ja bspw lauten:
Pakete an 10.0.0.0/24 gehen über 10.0.0.1. Doch um 10.0.0.1 zu erreichen muss IPfire immer noch wissen, wie der Weg dorthin aussieht. Der Schwanz beisst sich in den Hund ;) Oder ich bin ganz clever und gebe als Gateway die öffentliche IP des VPN Endpunkts an, dann würde IPfire die Pakete entweder über das Internet routen (womit spätestens beim Router der Telekom Schluss ist, denn private Adressbereiche werden "draussen" nicht geroutet) oder sie selbst verwerfen, weil die Firewall merkt, dass das Routing großer Blödsinn ist. So komme ich leider auch nicht weiter.

Mir kam jetzt noch die Idee, dass es vielleicht irgendeine Kerneleinstelung sein könnte, die noch geändert werden muss. Ähnlich wie beim forwarding, was im Kernel erst aktiviert werden muss. Das könnte bspw das Problem auf dem LB lösen. Ich teste gleich mal .... ;D

Ganz nebenbei: IPsec VPN an sich funktionieren hervorragend! Wir haben aktuell 5 Stück aktiv und alle lassen sich problemlos nutzen. IPfire weiss grundsätzlich schon, wo der Eingang zum Tunnel ist, nur nicht bei diesem speziellen VPN :(

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by puls » May 28th, 2019, 11:37 am

Yes Baby, da lag der erste Hase im Pfeffer! Auf meinem LB musste ich noch im Kernel das forwarding einschalten. Jetzt sieht der Ping von meinem PC dort so aus:

Code: Select all

tcpdump -i any net 10.0.0.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:26:17.084221 IP 192.168.1.245 > 10.0.0.31: ICMP echo request, id 27967, seq 1, length 64
13:26:17.084275 IP 192.168.166.245 > 10.0.0.31: ICMP echo request, id 27967, seq 1, length 64
13:26:18.109071 IP 192.168.1.245 > 10.0.0.31: ICMP echo request, id 27967, seq 2, length 64
13:26:18.109145 IP 192.168.166.245 > 10.0.0.31: ICMP echo request, id 27967, seq 2, length 64
13:26:19.132967 IP 192.168.1.245 > 10.0.0.31: ICMP echo request, id 27967, seq 3, length 64
13:26:19.133044 IP 192.168.166.245 > 10.0.0.31: ICMP echo request, id 27967, seq 3, length 64
13:26:20.156746 IP 192.168.1.245 > 10.0.0.31: ICMP echo request, id 27967, seq 4, length 64
13:26:20.156818 IP 192.168.166.245 > 10.0.0.31: ICMP echo request, id 27967, seq 4, length 64
13:26:21.180842 IP 192.168.1.245 > 10.0.0.31: ICMP echo request, id 27967, seq 5, length 64
13:26:21.180890 IP 192.168.166.245 > 10.0.0.31: ICMP echo request, id 27967, seq 5, length 64
Auf LA kommt wieder dieses:

Code: Select all

13:26:17.738134 IP 192.168.166.245 > 10.0.0.31: ICMP echo request, id 27967, seq 2, length 64
13:26:18.762007 IP 192.168.166.245 > 10.0.0.31: ICMP echo request, id 27967, seq 3, length 64
13:26:19.785777 IP 192.168.166.245 > 10.0.0.31: ICMP echo request, id 27967, seq 4, length 64
13:26:20.809823 IP 192.168.166.245 > 10.0.0.31: ICMP echo request, id 27967, seq 5, length 64
Auf dem Zielsystem kommt mal wieder nichts an.

Die Pakete kommen also von einem Host im Netz 192.168.1.0, gehen an LB, werden dort umgeschrieben auf das Netz 192.168.116.0 und gehen dann weiter an LA. Dort ist aber wieder Schluss.

Jetzt würde ich das ganze gerne mit einer Gegenstelle probieren, die ich vollständig untersuchen kann, um Routingfehler auf der Gegenseite ausschließen zu können. Dafür muss ich allerdings ein neues VPN einrichten zu einer Gegenstelle zu der schon ein VPN besteht. Ob das so klappt :-\

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: BINAT / 1:1 NAT / NETMAP mit IPsec -- wie?

Post by puls » May 29th, 2019, 12:38 pm

Alles großer Mist! >:(
Nochmal ein neuer Ansatz. Wir haben ein Cluster in einem anderen Rechenzentrum, welches bereits ein VPN zu dieser einen Gegenstelle hat (10.0.0.0/24). In das Cluster wiederum haben wir von hier aus ein VPN laufen. Jetzt müsste ich also nur eine Route setzen, die Traffic aus unserem Netz an eine bestimmte VM im Cluster sendet. Dort wird ein Masquerading durchgeführt und die Pakete gehen mit der IP der VM über das VPN in das Zielnetz.

Leider funktioniert auch das bisher nicht, pings kommen nicht auf der VM an. Vermutlich ein Routingfehler. Hier stehe ich schon wieder auf dem Schlauch. Aber das Thema ist vermutlich hier im VPN Bereich fehlplatziert. Ich fange mal einen neuen Strang an.

Post Reply