enzephalon
Oct 01, 2018
view4420
view8
0
Goto Top

VPN mit Libreswan verbindet, aber kein Datenverkehr

GermanQuestionLinux NetworkLinux
Hallo

Ich versuche mit Linux mich zu einem VPN-Server zu verbinden. Mit Windows funktioniert das wunderbar (hier nutze ich den ShrewSoft Client).
Mit Linux habe ich Probleme. Hier benutze ich Libreswan auf Debian (und auch mit einem Xubuntu-PC).

Fologende Konfiguration:

config setup
protostack  =   netkey

conn Office1
authby      =   secret
right       =   some.domain.tld
rightid     =   @Office_admin
rightnexthop    =   %defaultroute
left        =   192.168.42.91
leftsubnet  =   192.168.92.0/24
leftvti     =   192.168.92.234/24
leftid      =   @Office
keyexchange =   ike
ike     =   aes256-sha2;modp2048
esp     =   aes256-sha2;modp2048
ikelifetime =   4h
keylife     =   8h
auto        =   add
aggrmode    =   yes
vti-interface = vti0
vti-routing =   yes
mark        =   5/0xffffffff

Verbindung wird aufgebaut und virtuelles Netzwerkgerät vti0 eingerichtet mit IP 192.168.92.234 (eine IP aus dem entfernten Netzwerk).

Ich habe dann noch ausgeführt:

sudo ip route add 192.168.92.0/24 dev vti0

ip address show liefert:

vti0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1332 qdisc noqueue state UNKNOWN group default qlen 1000
link/ipip 192.168.42.91 peer xx.yyy.zzz.vv
inet 192.168.92.234/24 scope global vti0
   valid_lft forever preferred_lft forever

ip tunnel show liefert:

vti0: ip/ip remote xx.yyy.zzz.vv local 192.168.42.91 ttl inherit key 5
ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0

ip route show liefert:

default via 192.168.42.129 dev enp0s12u2 proto dhcp metric 100
xx.yyy.zzz.v dev vti0 scope link 
169.254.0.0/16 dev enp0s12u2 scope link metric 1000 
192.168.42.0/24 dev enp0s12u2 proto kernel scope link src 
192.168.42.91 metric 100 
192.168.92.0/24 dev vti0 proto kernel scope link src 192.168.92.234

Aber versuche ich zB ein Ping auf einen Server im entfernten Netzwerk, dann kommen keine Pakete zurück

tcpdump -i vti0 -n liefert:

13:45:31.577013 IP 192.168.92.234  > 192.168.92.10: ICMP echo request, id 4654, seq 1, length 64

Weiß jemand was hier ggf. noch fehlt? Muß ich ggf noch eine Route hinzufügen?
Ich wäre echt dankbar für Hilfe. Das kann doch nicht sein daß das so kompliziert ist - so n bissl VPN. Ich hab schon andere VPNs eingerichtet (zB zu ner Fritzbox) und das funktionierte einfach.

Vielen Dank
Johannes
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 388188

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

Printed on: April 19, 2024 at 05:04 o'clock

8 Comments
Latest comment
Goto Top
Member: aqui
aqui Oct 01, 2018 updated at 08:07:46 (UTC)
Goto Top
Ich versuche mit Linux mich zu einem VPN-Server zu verbinden.
Wir können aus dem Kontext ja nur raten, aber WELCHES VPN Protokoll nutzt du ??
Vermutlich native IPsec mit IKE Ver. 1, oder ?
Ich habe dann noch ausgeführt:
Das ist in der Regel Blödsinn, denn die SA Negotiation von IPsec erledigt das automatisch. Da du ja schon mehrere IPsec VPNs eingerichtet hast solltest du das eigentlich auch wissen. face-wink
Ein netstat -r -n oder ip route show auf deinem Ubuntu bei aktivem VPN Client (Routing Tabelle) sollte dir das dann auch zeigen das es auch OHNE diese statische Route geht.

Beunruhigen tut einen der show address Output, der hier von einer IP in IP Encapsulation spricht was dann nicht kompatibel wäre mit native IPsec. (IP in IP via native IPsec)
Ansonsten kann man nur vermuten das auf dem remoten VPN Server eine Firewall oder sowas aktiv ist.
Kannst du mit dem Windows Rechner pingen (ICMP) ?
Wenn ja wird es dann kein ICMP Filter sein.

Was man sich ernsthaft fragt ist warum du so einen Exoten wie Libreswan nimmst und nicht den Klassiker Strongswan ?
Und überhaupt... Wenn du schon weisst das es mit dem Shrew Client unter Windows sauber funktioniert WARUM dann bitte nimmst du nicht auch den Shrew Client für Linux ??
Mit apt get install ike kannst du den aus dem Repository installieren oder du nimmst den Code von der Website:
https://www.shrew.net/download/ike
Wenn du das machst achte darauf das keine 2 IPsec Clients auf dem Rechner aktiv oder installiert sind ! Das fürht in der Regel immer zum nicht Funktionieren des VPNs.
Sehr viel hilfreicher wären hier übrigens die Log Auszüge des VPN Servers und deines Libreswan Clients gewesen als die wenig hilfreichen Adress Outputs ! In den Logs sieht man meistens sofort warum es kneift.

Generell sind IPsec VPNs natürlich eine sehr einfache Sache. Siehe auch HIER und mit wenigen Mausklicks oder Konfig Zeilen installiert. Vorausgesetzt man weiss was man macht... face-wink
Member: EnzephaloN
EnzephaloN Oct 01, 2018 updated at 11:27:20 (UTC)
Goto Top
Hallo aqui

Ich nutze IPSEC mit IKEv1 und ich nutze Libreswan, da Strongswan und Debian sich nicht sooo gut mögen. Libreswan ist definitiv kein Exot, sondern die konsequente Fortentwicklung von OpenSwan.
Die Frage warum ich nicht den ShrewSoft-Client für Linux benutze lässt sich ganz einfach damit begründen, daß dieser mit aktuellen Linuxen nicht mehr funktioniert (siehe https://lists.shrew.net/pipermail/vpn-devel/2013-May/000626.html). Wäre mir auch lieber gewesen als in die tiefen von *Swan einzutauchen.
Wenn ich mit ShrewSoft unter Windows verbinden kann ich Pingen, RDPen, SMBen - alles so wie es sein soll. Wenn ich mit *Swan unter linux verbinde geht kein ping, kein RDP, kein ssh, nix.
Leider kann ich von der Server-Seite keine Logs präsentieren, da müsste ich erstmal schauen wie ich der "Box" ein anständiges Log entlocke.

Der IPSEC-Client auf Linux schreibt Folgendes

003 "Office1": IKEv1 Aggressive Mode with PSK is vulnerable to dictionary attacks and is cracked on large scale by TLA's  
002 "Office1" #1: initiating Aggressive Mode  
112 "Office1" #1: STATE_AGGR_I1: initiate  
010 "Office1" #1: STATE_AGGR_I1: retransmission; will wait 0.5 seconds for response  
010 "Office1" #1: STATE_AGGR_I1: retransmission; will wait 1 seconds for response  
003 "Office1" #1: ignoring unknown Vendor ID payload [0048e2270bea8395ed778d343cc2a076]  
003 "Office1" #1: ignoring unknown Vendor ID payload [5cbeb399eb835a7d7a2eb495905db061]  
003 "Office1" #1: ignoring unknown Vendor ID payload [810fa565f8ab14369105d706fbd57279]  
002 "Office1" #1: Peer ID is ID_FQDN: '@Office'  
002 "Office1" #1: WARNING: connection Office1 PSK length of 13 bytes is too short for sha2_256 PRF in FIPS mode (16 bytes required)  
002 "Office1" #1: Peer ID is ID_FQDN: '@Office'  
004 "Office1" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha2_256 group=MODP2048}  
002 "Office1" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+AGGRESSIVE+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:f067a0d5 proposal=AES_CBC_256-HMAC_SHA2_256_128-MODP2048 pfsgroup=MODP2048}  
117 "Office1" #2: STATE_QUICK_I1: initiate  
010 "Office1" #2: STATE_QUICK_I1: retransmission; will wait 0.5 seconds for response  
002 "Office1" #2: prepare-client output: net.ipv4.conf.vti0.disable_policy = 1  
002 "Office1" #2: prepare-client output: net.ipv4.conf.vti0.rp_filter = 0  
002 "Office1" #2: prepare-client output: net.ipv4.conf.vti0.forwarding = 1  
002 "Office1" #2: route-client output: done ip route  
004 "Office1" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP/NAT=>0x7ab81f99 <0xa80c1c82 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=xx.yyy.zzz.vv:4500 DPD=passive}

Konnte dem Server zB Folgendes entlocken:

cat /var/log/syslog | grep IPSEC
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is 'draft-ietf-ipsec-nat-t-ike-00'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is '16f6ca16e4a4066d83821a0f0aeaa862'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is 'draft-ietf-ipsec-nat-t-ike-02'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is 'draft-ietf-ipsec-nat-t-ike-03'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is '4a131c81070358455c5728f20e95452f'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is '4048b7d56ebce88525e7de7f00d6c2d380000000'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is 'Dead Peer Detection (DPD, RFC 3706)'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is '3b9031dce4fcf88b489a923963dd0c49'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is 'f14b94b7bff1fef02773b8c49feded26'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is '166f932d55eb64d8e4df4fd37e2313f0d0fd8451'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is '8404adf9cda05760b2ca292e4bff537b'  
Oct  1 09:06:49 Mon Oct  1  9:06:26 2018 IPSEC: P1: peer 0 () sa 330 (R): Vendor ID: aaa.bbb.ccc.ddd:50831 (No Id) is '12f5f28c457168a9702d9fe274cc0100'  
Oct  1 09:06:50 Mon Oct  1  9:06:27 2018 IPSEC: P1: peer 1 (VPN Admin Zugang) sa 330 (R): done id fqdn(any:0,[0..8]=Office) <- id fqdn(any:0,[0..13]=Office_admin) AG[0ff532d9 3796c80e : bbb77425 97dfbd64]
Oct  1 09:06:50 Mon Oct  1  9:06:27 2018 IPSEC: CFG: peer 1 (VPN Admin Zugang) sa 330 (R): request for ip address received
Oct  1 09:06:50 Mon Oct  1  9:06:27 2018 IPSEC: CFG: peer 1 (VPN Admin Zugang) sa 330 (R): ip address 192.168.92.125 assigned
Oct  1 09:06:54 Mon Oct  1  9:06:31 2018 IPSEC: P2: peer 1 (VPN Admin Zugang) traf 0 bundle 127 (R): created ::/0:0 < any > ::/0:0 rekeyed 0
Oct  1 09:06:55 Mon Oct  1  9:06:32 2018 IPSEC: Activate Bundle 127 (Peer 1 Traffic -1)
Oct  1 09:06:55 Mon Oct  1  9:06:32 2018 IPSEC: P2: peer 1 (VPN Admin Zugang) traf 0 bundle 127 (R): established  (xx.yyy.zzz.vv<->aaa.bbb.ccc.ddd) with 2 SAs life 7200 Sec/0 Kb rekey 6480 Sec/0 Kb Hb none PMTU
Oct  1 09:13:17 Mon Oct  1  9:12:54 2018 IPSEC: P1: peer 1 (VPN Admin Zugang) sa 330 (R): delete ip xx.yyy.zzz.vv <- ip aaa.bbb.ccc.ddd: Received delete

EDIT:
Starte ipsec Verbindung ohne route anzulegen:
sudo ipsec auto --up Office1
netstat -r -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
0.0.0.0         192.168.42.129  0.0.0.0         UG        0 0          0 enp0s12u2
xx.yyy.zzz.vv   0.0.0.0         255.255.255.255 UH        0 0          0 vti0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp0s12u2
192.168.42.0    0.0.0.0         255.255.255.0   U         0 0          0 enp0s12u2
192.168.92.0    0.0.0.0         255.255.255.0   U         0 0          0 vti0
ping 192.168.92.10
PING 192.168.92.10 (192.168.92.10) 56(84) bytes of data.
From 192.168.92.234 icmp_seq=1 Destination Host Unreachable
geht also leider auch nicht.

Viele Grüße
Johannes
Member: aqui
aqui Oct 01, 2018 at 15:14:35 (UTC)
Goto Top
geht also leider auch nicht.
Da stimmt dann was mit deiner Konfig nicht. Auf jeder Seite gibst du ja immer jeweils das remote Netzwerk an. Das wird dann im Rahmen der SA Negotiation beim Tunnelaufbau in die Routing Tabelle übernommen. Statische Routen sind dann überflüssig.
Macht ja auch Sinn das das so ist, denn der Routing Eintrag soll ja nur solange aktiv sein wie der VPN Client oder das VPN aktiv ist.
Bei dir scheint das schief zu laufen irgendwie. Du solltest dir also noichmal genau die SA Konfig ansehen und die Masken der Netze die du propagierst.
Übrigens funktioniert der Shrew Client auf einem aktuellen Raspian mit AES 256 und SHA256 als Hash vollkommen problemlos mit diversen IPsec Servern face-wink
Member: EnzephaloN
EnzephaloN Oct 01, 2018 at 16:35:56 (UTC)
Goto Top
Hallo aqui

An der Konfig habe ich nun wirklich in jedweder Richtung rumgespielt. Meiner Meinung nach ist sie so wie oben gelistet schlüssig und sollte so stimmen. Die Verbindung wird ja auch korrekt aufgebaut, dem virtuellen Device die IP zugeordnet, etc. .
Deinen Hinweis zu ShrewSoft muß ich für mich verneinen. Ich habe den Client sowohl auf Debian Testing, als auch auf Xubuntu (aktuelles LTS) mehrfach installiert und ihm dann die Konfig gegeben, die unter Windows funktioniert. Damit konnte ich mich auf den VPN-Server ebenfalls (also wie bei Libreswan) verbinden, doch es kam kein Traffic durch die Verbindung - siehe hierzu zB meine Frage ShrewSoft VPN-Client unter Linux keine Daten .

Ich weiß da nun echt nicht weiter: Ich setze ein nacktes Xubuntu oder Debian auf und installiere Libreswan bzw. ShrewSoft und bekomme mit der Konfig die unter Windows tadellos funktioniert hier keine Daten durch den Tunnel.

Der Client hat die IP 192.168.42.91 und geht über den 192.168.42.129 ins Netz. Der Server soll dann Zugriff auf ein Netzwerk mit dem IP-Raum 192.168.92.x bieten.

Ich kann mir echt nicht vorstellen was da so kompliziert sein soll...
Member: aqui
aqui Oct 02, 2018 updated at 11:52:04 (UTC)
Goto Top
Wenn die IPsec Verbindung zustande kommt dann ist VPN seitig auch alles richtig ! Ein kleiner Fehler dort in den Credentials würde das sofortige Aus für die VPN Verbindung bedeuten. Das kann man dann sicher als Fehler ausschliessen.
Dann bleibt eigentlich nur übrig das dort eine Firewall (iptables etc.) aktiv ist. Viel was anderes kann es ja nicht mehr sein...
Member: EnzephaloN
EnzephaloN Oct 02, 2018 updated at 12:04:32 (UTC)
Goto Top
Zitat von @aqui:

Dann bleibt eigentlich nur übrig das dort eine Firewall (iptables etc.) aktiv ist. Viel was anderes kann es ja nicht mehr sein...

Hi aqui

Das widerspricht aber dem, daß ich mit einem ShrewSoft unter Windows und der exakt gleichen Konfiguration Zugriff auf das entfernte Netzwerk bekomme, unter Linux aber nicht. Am Server kann es somit auch nicht liegen. Es muß irgendwo im Linux-Client Probleme geben...
Member: aqui
aqui Oct 02, 2018 at 12:05:59 (UTC)
Goto Top
Firewalls gibt es auch auf den Clients !!!
Member: EnzephaloN
EnzephaloN Oct 02, 2018 at 12:54:42 (UTC)
Goto Top
Das ist mir schon klar, aber da habe ich nichts konfiguriert.

 sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
GermanQuestionLinux NetworkLinux
Hotly discussed
AlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsjstrickerWIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 2 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment