VPN Ports ändern

[Gompf]

Hallo,

Ich würde gerne hinter einer FritzBox einen RAS Router betreiben, der L2TP anbietet.

Beide Router brauchen also IKE und NAT-T Ports. Der RAS Router lässt sich nicht verbiegen und soll auch mit Bordmitteln von notebooks erreichbar sein.

Die Fritzboxen betreiben ebenfalls ein VPN, und wenn ich das richtig sehe belegt das die ports 500 IKE und 4500 NAT-T.

Meine Frage lassen sich die Ports bei der FB so verbiegen dass die Fritzboxen (klar alle FBs müssen verbogen werden) nach wie vor ihr VPN aufbauen können und der RAS Router hinter der FB auch noch seine Dienste mit dem standart Ports tut ?

Hat das jemand am laufen ?

Ich habe in der AR7.cfg folgendes gefunden :

ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";

das kann aber n och nicht alles sein oder ?


Grüße


Chris

 

[PCMor]

Ahoi,

ich bin mir gerade nicht 100%ig sicher, was genau du tun willst bzw. tust, aber ich habe das jetzt so aufgefasst:

• du betreibst ein VPN-Netz zwischen diversen FritzBoxen, um gegenseitigen Zugriff zu ermöglichen
• nun soll hinter einer FritzBox eine Client-Einwahl über das Internet mittels L2TP-over-IPSec auf einen RAS-Server erfolgen
• jetzt sorgst du dich, dass es zu Konflikten mit den Ports 500 + 4500 kommen könnte, weil die FBs diese bereits nutzen

Richtig?

Also: wenn ich mich nicht täusche, nutzt L2TP-over-IPSec zum Aufbau der Verbindung den Zielport 1701 (UDP), erst danach kommen IKE und IPSec auf den Plan.
Es sollte also schlichtweg ein Portforwarding in der betroffenen FritzBox dieses Ports auf deinen RAS-Server ausreichen, damit Remote-Einwahl-Requests bei ihm ankommen.
Danach übernimmt dann wieder der Router, da ja nun wieder Punkt-zu-Punkt-Verbindungen bestehen.

In der FritzBox selbst sollte also nichts zu ändern sein, außer eben die Dienstfreigabe für den RAS-Server.

Was meinst du?

 

[Gompf]

Hi,

ich denke dass es nicht mit einem simplen 1701/udp geht, soweit ich weis zerhackt da NAT den IPSEC Header und dann geht da nichts mehr. Dafür gibts ja dann NAT-T auf UDP 4500.

Das Zenario hasst Du allerdings klar erfasst, das ist genau was ich machen will, bin mir nur nicht sicher ob mir das die Fritzbox erlaubt, da es ihre eigenen Ports betrifft.

Grüße

Chris

 

[PCMor]

(...) zerhackt da NAT den IPSEC Header und dann geht da nichts mehr. Dafür gibts ja dann NAT-T auf UDP 4500

Naja, fast: reines IPSec geht zum Verbindungsaufbau (phase 1) direkt via IKE (port 500 zu port 500) zur Gegenstelle; wenn dort genattet wird und es kommt noch eine IPSec-VPN-Anfrage auf Port 500 rein, kann der NAT-Router die Pakete nicht mehr unterscheiden, weil er wegen der Verschlüsselung der Pakete nichts mehr herauslesen kann - das ist dann Datenmüll.

NAT-T setzt da an und kapselt die verschlüsselten Pakete in normale UDP-Datagramme mit bspw. lesbarer Absender- und Empfänger-IP, so dass die Pakete wieder beim richtigen Empfanger ankommen.

Bei L2TP-over-IPSec benutzt der anfragende Client aber nicht port 500, sondern irgendeinen Highport jenseits von 1024 und sendet über diesen seine Anfrage eben an UDP 1701 - wenn hinter diesem Port eine Antwort auf diese Anfrage von deinem RAS-Server zurück geschickt wird, hat sich das Thema für die FB erledigt: sie routet jetzt eine eindeutige PPP, und was da drin passiert, ist ihr wurscht. Den Rest machen der Client und dein Server.

Hast du's denn mal probiert?

 

[Gompf]

Hi,

Also den speziellen setup habe ich noch nicht probiert, den plane ich ja gerade, da ich Hardware einsetzen will, und mich nicht auf einen Server verlassen will, klaere ich das ja gerade im Vorfeld ab ob es geht

Aber wenn ich mir das durchlese dann muesste RRAS L2TP IPSec abenfalls so tun, und das konte ich gleich (habe ich aber schon in der Vergangenheit getan) testen. Ergebnis : Es tut nicht und bleibt bei der aushandlung des Security Layers haengen.

Waere ja auch zu schoen um war zu sein !

Nachgeschaut und folgendes gefunden:

"The UDP 500 receive/send packet filter allows for Internet Key Exchange Protocol (IKE) packets to be received by the ISA Server firewall/VPN server. This packet filter is required for both NAT-T VPN clients and non-NAT-T VPN clients.

The UDP 4500 receive/send packet filter is specific for NAT-T VPN clients. The IPSec ESP header is encapsulated in the UDP port 4500 header. When the Windows Server 2003 ISA Server/VPN server receives the packet, it removes the UDP header and exposes the ESP header. This is how the server determines that the VPN client is a NAT-T client.

The UDP 1701 receive/send packet filter allows the L2TP control channel to be established and maintained. The are a number of different control messages that are sent through the L2TP control channel. The purpose of the control messages is to establish the VPN tunnel, maintain the VPN tunnel, and tear down (close) the tunnel in an orderly fashion when the connection is no longer needed.

The figure below shows the structure of an L2TP/IPSec packet. Notice that the IPSec ESP header is located in front of the L2TP UDP header. The IPSec ESP header does not require an open port. However, it does require that the firewall listen and accept incoming connections to IP Protocol 50. Only the tunnel IP header containing the tunnel endpoint information and the datalink layer header encapsulate the IPSec ESP header."


Ich kann mich erinnern das auch mal gemacht zu haben, und das hat funktioniert. Deswegen bin ich ja darauf gekommen ob man die ports der Fritzboxen verbiegen koennte , da das ja ein geschlossenes system ist und sich nicht mit anderen Geraeten verstehen muss.

/Chris

 

[PCMor]

Hm, da werde ich wohl bei der Schnell-Analyse des Logs des Verbindungsaufbaus eines Clients über L2TP-over-IPSec mit unserer Firmenfirewall etwas deutlich übersehen oder falsch interpretiert haben.

[EDIT] ...aber sowas von... Hatte nur den PPP-Log im Auge, da ist mir der ganze IKE- & IPSec-Kram nicht vor die Augen gekommen... :blonk: [/EDIT]

Sorry dafür :spocht:

Aber wenn diese Aussage hier korrekt ist...

(...) it does require that the firewall listen and accept incoming connections to IP Protocol 50 (...)

...dann sollte in der FritzBox das Forwarding von ESP auf deinen RAS-Server es doch schon tun? IPP50 ist ja ESP, und das kann die FB gezielt forwarden, so wie ja auch GRE (IPP47) für PPTP...

[EDIT2]...und eigentlich sollten ihre eigenen Tunnel davon nicht betroffen sein, da es sich bei der Kopplung zweier FritzBoxen ja um ein Site-to-Site-VPN handelt - sie selbst baut den Tunnel ja direkt über ihre öffentliche IP mit einer anderen öffentlichen IP auf, bzw. es können ja grundsätzlich beide Seiten den Verbindungsaufbau initiieren...[/EDIT2]

 

[Gompf]

Hi Martin,

Das mit dem ESP habe ich schon probiert, klar. Das alleine Tut es nicht. AVM benutzt also kein ESP ? Ich dachte das waere auch IPSec ?

Man kann das Protokol weiterleiten, was bei GRE ohne Probleme tut, tut bei ESP nicht, oder er will dann doch noch IKE (weil steht ja drinnen das IKE sowohl fuer Normal als auch NAT-T benoetigt wird).. Ich habe gelesen (irgentwan einmal) dass genau deswegen das ESP Paket in ein UDP Paket bei NAT-T (4500) gepackt wird, weil bei nat der ESP Header zerstoert wird....

Leider alles nicht so einfach. Aber das aendern der Ports in the AR7.cfg ist wohl auch nicht unbedingt einfach, denn es sind dort nur regeln einetragen, aber irgentein daemon muss ja auf die in den Regeln benannten ports hoeren (deswegen ist ja bei Aenderung der VOIP Ports auch an zwei stellen eine Aenderung noetig)...

/Chris

 

[PCMor]

Hi Chris,

ich habe nur eine Vergleichsreferenz, was das AVM-VPN angeht: Site2Site mit einer Astaro-Firewall (die nutzt intern StrongSWAN), und da läuft das IPSec-VPN standesgemäß... ergo muss die AVM auch das volle Programm nutzen (ESP, IKE, IPSec), sonst würde das nix werden (bisher mit der 7170, 7270 und der 7390 produktiv im Einsatz).

Die für reine IPSec-Verbindungen grundsätzlich zuständigen Protokolle sind ja

• AH (Authentication Header) IP Protocol 51
• ESP (Encapsulating Security Payload) IP Protocol 50
• IKE (Internet Key Exchange) UDP 1:65535 → 500 (hab das gerade noch mal verifiziert, meine Aussage 500 → 500 aus Posting #4 ist also FALSCH!)
• NAT-T (NAT-Traversal to work through NAT devices) UDP 1:65535 → 4500

AH fällt meines Wissens nach bei L2TP raus, NAT-T kommt nur zum Tragen, wenn der verbindende Server nattet - das wird beim IPSec-VPN automatisch ermittelt und eingestellt, kann aber, was die FB-S2S-Verbindungen angeht, abgeschaltet werden (meine VPN-Tunnel zwischen FB und Astaro nutzen kein NAT-T).

Also brauchen die LAN-to-LAN-Connects deiner FBoxen kein NAT-T - aber wohl der RAS-Server hinter der betroffenen FB.

Ich würde also in der Tat einfach in besagter Box forwardings für ESP, IKE und NAT-T auf deinen RAS-Server versuchen.

Meine Situation ist zwar die, dass mein Heim-Fritz einen IPSec-Tunnel auf unsere Firmen-FW aufbaut, aber eine L2TP-Verbindung auf die selbe Firewall kann ich von meinem Rechner hinter der FB trotzdem parallel aufbauen...

 

[Gompf]

Hi Martin,

Dass Du auf die selbe Firewall eine L2tp parallel zum FB IPSec hinbekommst wundert mich ja weniger, es sei denn die Firewall leitet das nach hinten weiter, dann wundert es mich schon, das waere ja dann mein Setup hier.

Was mich wundert, Du sagst AVM braucht ESP aber kein NAT-T da es borderline ist, dem stimm ich dir da zu, aber du sagst auch ESP weiterleiten auf den RAS. Bei NAT-T waere ja das ESP in UDP/4500 eingebaut, und das ESP waere ja schon von der FB blockiert. NAT-T weiterleiten kann ich mir vorstellen, mit Tricks auf der FB, aber bleibt am Schluss immer noch IKE Port 500 uebrig.....Den kann man der Box sicher nicht weg nehmen einfach so ohne in mit einem anderen zu ersetzen....

Oder ?

 

[PCMor]

Wie gesagt, deine Konstellation habe ich nicht - wobei ich am kommenden Wochenende vielleicht in der Lage wäre, das nachzubauen, sollten alle Stricke reissen.

Zum NAT-T: die FB nutzt NAT-T, wenn es in der VPN-config aktiviert ist, ob es nötig ist oder nicht. Sie signalisiert dann dem Endpoint, dass sie NAT-T einsetzt, also stellt sich der Endpoint darauf ein - gehört zur IPSec-VPN-Spezifikation. In meinen Konstellationen brauche ich bei End-to-End NAT-T nicht, bzw. höchstens dann, wenn ich durch den IPSec-Tunnel hinter der FB weitere, nur von der Gegenstelle aus erreichbare Netze ansprechen will. Und spätestens dann wird es eh haarig mit der FB: stabil kann ich diese dann zwangsgenatteten Verbindungen nicht aufziehen...

Ich sehe aber nicht, dass ESP durch die FB blockiert ist: sie selbst (also ein kleiner Client in ihr, welcher Art auch immer) benutzt ESP ja zunächst mal, um ein S2S mit einer anderen FB herzustellen. Wenn die Verbindung steht, sorgt sie ja per DPD durch den IPSec-Tunnel dafür, dass dieser gekappt wird, wenn der Partner-Peer offline geht bzw. wenn die IKE-Lifetime (1h) erreicht ist, den Tunnel mit dem Peer neu auszuhandeln.

Wenn die FB bei gleichzeitig bestehender Portweiterleitung von ESP und IKE auf deinen RAS-Server ihren internen VPN-Client anwirft, gehe ich einfach mal ganz naiv davon aus, dass die FB für diesen Verbindungsaufbau nicht ihr internes LAN-, sondern ihr externes DSL-Interface nutzt. Wozu auch einen Tunnel ins eigene, selbst geroutete Netz aufbauen? Zumal in der VPN-Config sowieso nicht-private Adressen stehen.

Worst-case sollte sein, dass eine externe FB keinen Tunnel mehr zur FB mit dem RAS-Server hinter ihr aufbauen kann, weil die Box dann evt. nicht ihre eigene VPN-Config zu Rate zieht, sondern stumpf die Protokoll-Anfragen intern weiterleitet - aber selbst dann sollte die FB mit dem RAS im Rücken irgendwann von sich aus die Verbindung herstellen, oder?

Poste doch mal, was du noch so ausprobierst, und vielleicht auch deine FB- und Win-Logs als Anhang. Wenn es partout nicht geht, muss man der FB eben nur noch die Rolle eines Modems zugestehen und zumindest für den Standort mit dem RAS dann eine etwas größere Hardwarelösung suchen...

 

[PCMor]

In meinen Konstellationen brauche ich bei End-to-End NAT-T nicht°

°Die VPNs zwischen den Boxen werden nicht genattet, da sich die Peers direkt ansprechen - wenn man der FB aber in der Config explizit sagt

use_nat_t = yes;

dann macht sie eben NAT-T, ob nötig oder nicht.
Haben zumindest meine Tests mit der Astaro als Gegenstelle ergeben.

 

[Gompf]

Hi Martin,

Ja, bei mir ja auch , kein NAT-T im Einsatz. Das heisst gerade nicht, eine meiner Fritzboxen 7170 (die dich ich auf Reisen mitnehme) ist zum Einsatz in Hotels auf NAT-T konfiguriert, damit das auch immer klappt. Das heisst manchmal benutz ich es schon, in wie weit das aber die "Server" Fritzbox betrifft, weis ich jetzt nicht, warscheindlich schon.

Was ich nicht verstehe wie kann die FB gleichzeitig ESP benutzen und es Forwarden. Ein Protokoll mapping ist doch permanent, nicht konditional ? Allerdings hat mich meine FritzBox dieses Mapping einrichten lassen, was mich eh schon gewundert hat....


/Chris

 

[PCMor]

Ich nehme an, dass die FB intern ESP und alle anderen möglichen Protokolle für jedes verfügbare Interface separat verarbeitet, so dass sie ihr eigenens VPN über ihren Locallink oder so ans DSL-Interface jagt und zeitgleich den Dienst auch bei Bedarf ins LAN, das sie zu routen hat, durchreichen kann... :gruebel: