Mit VPN-Client durch iptables-Firewall (L2TP)

Beitrag von **feltel** » 26.01.2007 12:17:16

Manchmal sieht man ja den Wald vor lauter Bäumen nicht, so scheints mir gerade zu gehen. :-/

Folgendes Szenario: Auf einem Windows-Rechner soll/muss ein VPN-Clientsoftware ("NCP Secure Client") laufen. Der Rechner hängt hinter einer iptables-Firewall. Theoretisch sollte das kein Problem sein, nur leider werfen weder die iptables-Firewall noch der Client hilfreiche Meldungen. Das einzige was ich weiß ist das die Kommunikation auf Port 1701 UDP laufen soll. Wenns an den Firewall-Regeln hängen sollte, dann müsste man zumindest was im Syslog sehen, da die INPUT und die OUTPUT-chain geloggt werden.

Ich hab mal mit tcpdump die Sequenz mitgeschnitten während der Client versucht sich zu connecten:

Code: Alles auswählen

12:15:58.485903 IP 10.0.1.215.l2f > 194.76.232.149.l2f:  l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) |...
12:16:00.891890 IP 10.0.1.215.l2f > 194.76.232.149.l2f:  l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) |...
12:16:03.891951 IP 10.0.1.215.l2f > 194.76.232.149.l2f:  l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) |...
12:16:07.892008 IP 10.0.1.215.l2f > 194.76.232.149.l2f:  l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) |...
12:16:11.892024 IP 10.0.1.215.l2f > 194.76.232.149.l2f:  l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP(AD) |...

Kann das jemand von euch interpretieren?

mistersixt · Beitrag von **mistersixt** » 26.01.2007 13:52:06

Mmmh, was komisch ist: normalerweise steht ja beim tcpdump hinter der IP die Portnummer, da steht bei Dir l2f, und nicht beispielsweise 1701! Seltsam ...

Gruss, mistersixt.

[edit]Oder steht "l2f" in /etc/services mit 1701?[/edit]

mistersixt · Beitrag von **mistersixt** » 26.01.2007 14:02:50

Habe gerade das hier noch gerade gefunden, um die Pakete durch eine Firewall zu lassen:

Code: Alles auswählen

iptables -t mangle -A PREROUTING -i eth0 -p esp -j MARK --set-mark 1
iptables -A INPUT -i eth0 -m mark --mark 1 -j ACCEPT
 
iptables -A OUTPUT -s a.b.c.d -p udp -m udp --sport 1701 -j ACCEPT 
 
iptables -A INPUT -p esp -j ACCEPT 
iptables -A OUTPUT -p esp -j ACCEPT 
 
iptables -A INPUT -d a.b.c.d -p udp -m udp --dport 500 -j ACCEPT 
iptables -A OUTPUT -s a.b.c.d -p udp -m udp --sport 500 -j ACCEPT

Danach scheint das Protokoll ja irgendwie auf IPSec zu basieren.

Gruss, mistersixt.

Beitrag von **feltel** » 26.01.2007 14:18:06

mistersixt hat geschrieben:[edit]Oder steht "l2f" in /etc/services mit 1701?[/edit]

Jupp.

Wär eth0 in Deinem Codebeispiel das externe oder das interne Interface der Firewall?

mistersixt · Beitrag von **mistersixt** » 26.01.2007 14:38:01

feltel hat geschrieben:
mistersixt hat geschrieben:[edit]Oder steht "l2f" in /etc/services mit 1701?[/edit]
Jupp.

Wär eth0 in Deinem Codebeispiel das externe oder das interne Interface der Firewall?

Ich habe noch nie mit L2TP gearbeitet, aber das scheint dem OpenSwan ähnlich zu sein, da mache ich die MARKs auf dem externen Interface. Schaden kann es auf dem interen Interface auch nicht, da die Regel ja nur die ESP-Pakete zulässt. Früher, bei Kernel-2.4, gab es ja noch das ipsec0-Interface, wo man expliziter irgendwelche Regeln anwenden konnte, bei Kernel-2.6 muss man den Umweg über ESP und MARK gehen.

Gruss, mistersixt.

Beitrag von **feltel** » 29.01.2007 08:02:42

Das mit dem Tagging scheint nicht die Lösung zu sein. Der Windows-Client kann immer noch nicht connecten und es scheint auch kein weiterer Datenverkehr zu herrschen als im tcpdump-Auszug von oben.

123456 · Beitrag von **123456** » 29.01.2007 10:58:12

Hast Du denn mal getestet, ob der Client tun würde, wenn er nicht durch die FW müsste? Vielleicht gibts ja noch ein anderes Problem?

Beitrag von **habakug** » 29.01.2007 12:54:18

Hallo!

Der obige Auszug aus tcpdump ist nur einseitig. Der Client sendet einen

Start-Control-Connection-Request (SCCRQ)

und wartet auf eine Antwort, die aber nicht kommt. Die Antwort wäre ein

Start-Control-Connection-Reply (SCCRP)

Was ist auf der anderen Seite los? Wir wissen bis jetzt nur, das ein Windows-Client (Win3.1, W95, Win98, WinME, W2k, WinXP, Win2003, WindowsVista) eine VPN-Clientsoftware betreibt.
Sollte L2TP/IPsec eingerichtet sein, was ich bevorzugen würde, muß zusätzlich der Port 500/udp verfügbar sein, da hier der Internet Key Exchange (IKE) stattfindet.

Gruß, habakug

Beitrag von **feltel** » 29.01.2007 13:06:09

Der VPN-Server steht im staatlichen Schulamt irgendwo in Brandenburg, und von daher kann ich mit Infos zu dieser Seite des VPNs leider nicht hilfreich sein. Auf unserer Seite ist das System ein WinXP-Client auf dem die NCP SecureClient Software läuft.

123456 · Beitrag von **123456** » 29.01.2007 13:29:32

feltel hat geschrieben:Der VPN-Server steht im staatlichen Schulamt irgendwo in Brandenburg, und von daher kann ich mit Infos zu dieser Seite des VPNs leider nicht hilfreich sein.

Ruf den Admin dort doch einfach mal an...Wenn andere Clients connecten können sollte man ja die notwendigen Porteinstellungen von ihm mitgeteilt bekommen.