FritzBox Labor. Linux VPN Client

[alturismo]

Hallo,

hat mal jemand shrew getestet auf einer vista x64 plattform ?

ich habe die config gemäß whoopies howto gemacht

http://www.ip-phone-forum.de/showpost.php?p=1068741&postcount=4

stehen bleiben tut das tool bei

bringing up tunnel ...
negotiation timeout occured
tunnel disabled
detached key daemon

client ist shrew 2.1.2

FB Config erstellt mit Fritz Tool

wer ne idee hätte im voraus vielen dank

 

[bob_broker]

Ich komme unter Ubuntu 8.04 und Shrew 2.1.0 leider noch nicht einmal zum Tunnelaufbau. Ich habe mich strikt an die Screenshots gehalten, habe aber Probleme mit den möglichen Einstellungen bei der Authentifizierung ... Könnte vielleicht einer von euch eine anonymisierte Shrew-Config zur Verfügung stellen?

Unter MacOs funktioniert die Verbindung zur Fritbox 7270 ohne Probleme.

 

[pavolmarko]

Diese Fehlermeldung kam bei mir, wenn die E-Mail Adresse, die man an der Fritz!Box angegeben hat, nicht korrekt unter Authentification / Local Identity / User Fully Qualified Domain Name eingetragen war.

Viele Grüße,
Pavol Marko

 

[bdtester]

Routing-Probleme?

Hallo,
ich habe dank diverser Beiträge hier (danke @whoopie) unter WinXP mit Shrew (ike 2.1.3) eine VPN-Verbindung voll funktionstüchtig zu einer FritzBox aufbauen können. Setze ich jedoch die gleiche Konfiguration auf dem gleichen Rechner unter Linux (OpenSuSE 10.3, Kernel 2.6.22.19) ein wird zumeist der Tunnel aufgebaut und dann nach 30-60 Sekunden (unter Windows geht's deutlich schneller) von der Box bestätigt: VPN-Fernzugang hergestellt.
Das war's dann aber auch. Es sind keine pings möglich.
Die FB-Konfig ist mit dem AVM-Tool erstellt und unverändert; die shrew-Konfig nach whoopies Screenshots.
Ich habe mal die Ausgaben von ifconfig, route -n sowie die iked-Log (debug-Modus) angehängt.
Es wäre sehr schön wenn mir jemand Tips geben könnte, wie ich durch meinen offensichtlich stehenden Tunnel Daten bekomme. Ich vermute ein Routing-Problem, obwohl route -n ja erstmal vielversprechend aussieht.
Vielen Dank für Hilfe jedweder Art!

 

[wuesten.fuchs]

Also ich melde mich mal von der ZyXEL-Front. Hab hier eine ZyWALL 2 Plus und bekomme sowohl unter Intrepid (Version 2.1.0) als auch unter *hüstel* Vista (Version 2.1.4) den Tunnel korrekt hergestellt ("tunnel enabled"). Der Tunnel steht stabil auch über einen längeren Zeitraum hinweg.

So weit so gut. Dummerweise kann ich ebenfalls keine Daten durch den Tunnel übertragen, nicht einmal ein einziges, winziges PING will durch. Testweise wurde die Firewall der ZyWALL komplett deaktiviert, aber auch ohne Firewall klappt es nicht.

Ein kommerzieller Client (TheGreenBow) unter Vista funktioniert hingegen tadellos mit denselben Einstellungen.

Hat jemand eine Idee, woran das liegen könnte? Ist ja nicht nur bei mir so, sondern auch auf der FritzBox, weshalb ich mal stark vermute, dass es mit dem Shrew Soft VPN Client zu tun hat.

Btw, gibt es alternative VPN-Clients für Linux?

 

[thymythos]

Das selbe Problem hatte ich auch. Hör mal mit Wireshark was über die Leitung geht. Bei mir war es so, dass ich für den Ping sogar Antworten bekam, aber die konnten offensichtlich nicht zugeordnet werden.

 

[wuesten.fuchs]

Du hast recht, laut Wireshark geht der Ping durch und sogar wieder zurück.

Hier das Protokoll:

No.     Time           Source                Destination           Protocol Info
      1 0.000000000    192.168.4.21          195.50.140.178        DNS      Standard query A test.test.org
      2 0.045366000    195.50.140.178        192.168.4.21          DNS      Standard query response A xxx.xxx.xxx.xxx
      3 0.051782000    192.168.4.21          xxx.xxx.xxx.xxx         IP       Fragmented IP protocol (proto=UDP 0x11, off=0) [Reassembled in #5]
      4 0.051895000    192.168.4.21          xxx.xxx.xxx.xxx         IP       Fragmented IP protocol (proto=UDP 0x11, off=1480) [Reassembled in #5]
      5 0.051978000    192.168.4.21          xxx.xxx.xxx.xxx         ISAKMP   Identity Protection (Main Mode)
      6 0.318704000    xxx.xxx.xxx.xxx         192.168.4.21          ISAKMP   Identity Protection (Main Mode)
      7 0.321210000    192.168.4.21          xxx.xxx.xxx.xxx         ISAKMP   Identity Protection (Main Mode)
      8 0.642135000    xxx.xxx.xxx.xxx         192.168.4.21          ISAKMP   Identity Protection (Main Mode)
      9 0.644574000    192.168.4.21          xxx.xxx.xxx.xxx         ISAKMP   Identity Protection (Main Mode)
     10 0.650715000    xxx.xxx.xxx.xxx         192.168.4.21          ISAKMP   Identity Protection (Main Mode)
     11 0.651175000    192.168.4.21          xxx.xxx.xxx.xxx         ISAKMP   Informational
     12 0.654660000    192.168.4.21          xxx.xxx.xxx.xxx         ISAKMP   Quick Mode
     13 0.663614000    xxx.xxx.xxx.xxx         192.168.4.21          ISAKMP   Quick Mode
     14 0.664228000    192.168.4.21          xxx.xxx.xxx.xxx         ISAKMP   Quick Mode
     15 4.998746000    Intel_9d:0a:e9        ZyxelCom_8e:ac:ec     ARP      Who has 192.168.4.1?  Tell 192.168.4.21
     16 5.000644000    ZyxelCom_8e:ac:ec     Intel_9d:0a:e9        ARP      192.168.4.1 is at 00:19:22:8e:15:45
     17 9.440687000    192.168.4.1           192.168.4.255         RIPv1    Response
     18 15.441148000   192.168.4.1           192.168.5.9           TCP      http > 49685 [RST] Seq=1 Win=5360 Len=0
     19 20.331952000   192.168.4.21          xxx.xxx.xxx.xxx         ESP      ESP (SPI=0xf1134490)
     20 20.337875000   xxx.xxx.xxx.xxx         192.168.4.21          ESP      ESP (SPI=0x0e0f01de)
     21 20.337875000   192.168.4.1           192.168.4.9           ICMP     Echo (ping) reply
     22 21.345838000   192.168.4.21          xxx.xxx.xxx.xxx         ESP      ESP (SPI=0xf1134490)
     23 21.351116000   xxx.xxx.xxx.xxx         192.168.4.21          ESP      ESP (SPI=0x0e0f01de)

Die 192.168.4.21 kommt übrigens daher, dass ich gerade im Zielnetz bin und praktisch von innerhalb eine VPN-Verbindung aufbaue. Aber auch von außerhalb geht es nicht, mit genau den gleichen Symptomen.
xxx.xxx.xxx.xxx ist die öffentliche statische IP unseres Firmennetzwerks.


Falls es von Interesse ist, hier die Einstellungen an der ZyWALL und am Shrew Soft Client (nein, ich erwarte nicht, dass jemand die Einstellungen durchgeht, aber vielleicht helfen sie ja dem einen oder anderen):

### AN DER ZYWALL ###
*** Property ***
[ ] Nailed-up
[x] Allow NetBIOS broadcast Traffic Through IPSec Tunnel
[ ] Check IPSec Tunnel Connectivity

*** Virtual Addres Mapping Rule ***
[ ] Active

*** Local Network ***
Adress Type: Subnet Address
Starting IP Address: 192.168.4.0
Ending IP Address / Subnet Mask: 255.255.255.0
Local Port: 0 to 0

*** Remote Network ***
Address Type: Single Address
Starting IP Address: 0.0.0.0
Local Port: 0 to 0

*** IPSec Proposal ***
Encapsulation Mode: Tunnel
Active Protocol: ESP
Encryption Algorithm: AES128
Authentication Algorithm: SHA1
SA Life Time (Seconds): 28800
Perfect Forward Secrecy (PFS): None
[x] Enable Replay Detection
[x] Enable Multiple Proposals


### SHREW SOFT VPN CLIENT ###
*** General ***
Host Name or IP Address: ...
Port: 500
Auto Configuration: disabled
Address Method: Use a virtual adapter and assigned address
MTU: 1380
Address: 192.168.4.9
Netmask: 255.255.255.0

*** Client ***
NAT Traversal: disable
IKE Fragmentation: enable
Maximum packet size: 540 Bytes
[x] Enable Dead Peer Detection
[x] Enable ISAKMP Failure Notifications

[...]

*** Phase 2 ***
Transform Algorithm: auto
HMAC Algorithm: auto
PFS Exchange: disabled
Compress Algorithm: disabled
Key Life Time limit: 28800 Secs
Key Life Data limit: 0 Kbytes

*** Policy ***
[x] Maintain Persistent Security Associations
[ ] Obtain Topology Automatically or Tunnel All
Remote Network Resource:
Include 192.168.4.0 / 255.255.255.0

 

[meiser79]

Hi,

alle, die Probleme mit Pings haben, sollten mal schauen, ob der folgende sysctl-Wert gesetzt ist:

net.ipv4.conf.all.rp_filter

Weitere Infos gibt's hier.

Beste Grüße,
Whoopie

 

[bdtester]

tjo, mit net.ipv4.conf.all.rp_filter = 0 in /etc/sysctl.conf geht's jetzt bei mir. Mann, das ist ja zu geil ;-)
Vielen Dank, whoopie, für den Tip und auch die ganze andere Vorarbeit, die Du geleistet hast!!!



Edit: Für OpenSuSE sind weitere Anpassungen erforderlich: Ich habe herausgefunden, dass bei mir (Susi 10.3) der rp_filter-Parameter nicht nur vom Skript boot.sysctl, sondern auch von der SuSEfirewall2 gesetzt wird. Diese wird beim Booten deutlich nach dem sysctl-Script geladen, sodass sie die sysctl-Werte ggfs überschreibt. Daher muss in diesen Fällen auch die Firewall-Config angepasst werden:
a) entweder unter /etc/sysconfig/SuSEfirewall2 den Parameter FW_KERNEL_SECURITY auf "no" setzen. Dadurch werden jedoch weitere Sicherheitsfeatures des Kernels mit abgeschaltet
b) Das Firewall-Script /sbin/SuSEfirewall2 selbst ändern und den Eintrag setproc 1 $i/rp_filter deaktivieren. Sollte dann aber ein Update reinkommen war das für die Katz'.
c) eine entsprechende custom-Rule hinzufügen: in der /etc/sysconfig/SuSEfirewall2 den Eintrag FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom hinzufügen und in dieser Datei, z.B. in der Sektion "fw_custom_before_antispoofing" so etwas einfügen wie echo "0" > /proc/sys/net/ipv4/conf/ethdev/rp_filter, wobei ethdev die "echte" Netzwerkschnittstelle ist, über die der Tunnel aufgebaut ist.

Ich habe alle drei Varianten ausprobiert und verfahre nun nach Variante c), da somit die Updatesicherheit gegeben ist und die übrigen, nicht weiter störenden Sicherheitsfeatures aktiv bleiben können.

 

[thymythos]

Is ja echt super. So funktionierts bei mir auch. Ich führe einfache bei Bedarf "echo 0 > /proc/sys/net..." aus. Ich denke wir sollten im Wiki einen Artikel anlegen:
http://wiki.ip-phone-forum.de/gateways:avm:howtos:start#remote_administration_vpn

 

[wuesten.fuchs]

Ich glaube, ich habe mich etwas zu vorschnell gefreut... der Hinweis von Whoopie hilft mir leider nicht weiter, und ich muss meine obige Aussage korrigieren: Es kommen keine Pings durch den Tunnel zurück.

Jetzt bin ich wieder da, wo ich am Anfang war...

Soll ich einen eigenen Thread aufmachen, nachdem die Probleme einiger Threadschreiber gelöst zu sein scheinen?

 

[thymythos]

Nenn doch erst mal deine (nicht funktionierende) Konfiguration. Distribution, Shrew, Methode rp_filter zu setzen...

 

[FlyWord]

Hallo,
so wie es scheint steh ich nicht alleine da.

Bei mir baut sich der Tunnel via Shrew beim ersten mal erfolgreich auf, nach einem Disconnecten und erneut Connecten baut er den Tunnel zwar auf jedoch geht da keinen Ping raus/rein. Nach einem kompletten Restart vom Computer funktioniert die erste Verbindung dann wieder erneut ohne Probleme.

Kann mir jemand weiterhelfen weshalb die Verbindung beim zweiten mal nicht funktioniert? An den Einstellungen kann es ja nicht liegen, da es beim ersten mal ja funktioniert!

--------------

Ein zweites Problem, nach dem ein Client über ein Hotspot im Hotel Verbinden wollte kam folgende Meldung:
Bringing up tunnel...
Invalid message from gateway
Tunnel disabled
Detached from key daemon….

Vielleicht kann mir hier auch noch jemand weiterhelfen.

 

[wuesten.fuchs]

Hier ist die aktuelle Konfiguration. Die ersten beiden Bilder sind die Screenshots der VPN-Gateway-Konfiguration, die restlichen sind die Einstellungen vom Shrew Soft VPN Client.

Den rp_filter habe ich genauso gesetzt wie bdtester, d.h. manuelles Editieren der /etc/sysctl.conf.

Die Konfiguration vom VPN Gateway und vom VPN Client müsste doch stimmen, oder? Mittlerweile zweifle ich wirklich langsam an mir selbst *seufz*

 

[FlyWord]

[Edit frank_m24: Fullquote auf das Notwendige beschränkt. Lies noch mal die Forumregeln.]

Ein zweites Problem, nach dem ein Client über ein Hotspot im Hotel Verbinden wollte kam folgende Meldung:
Bringing up tunnel...
Invalid message from gateway
Tunnel disabled
Detached from key daemon….

Dieses Problem hat sich bei mir erledigt, hab den Port 4500 noch weitergeleitet und dann ging es.. juhee!!! Stabile Sache nun.

 

[FlyWord]

Hy,

ändere hier folgendes:
http://www.ip-phone-forum.de/attachment.php?attachmentid=30940&d=1228905398

auto zu AES256
auto zu SHA1
auto zu DH2

----

http://www.ip-phone-forum.de/attachment.php?attachmentid=30941&d=1228905429

auto zu ESP
auto zu AES128
auto zu SHA

----
http://www.ip-phone-forum.de/attachment.php?attachmentid=30933&d=1228905208

Enable Multiple Proposals "deaktivieren"

----

http://www.ip-phone-forum.de/attachment.php?attachmentid=30934&d=1228905208

Virtuelle IP ändern auf eine die nicht mit 192.168.4.xx lautet, z.b. 192.168.5.xx

----

http://www.ip-phone-forum.de/attachment.php?attachmentid=30935&d=1228905237

Enable Dead Peer Detection "aktivieren"
Enable IKSAMP Failure Notifications "aktivieren"

----

In der Zywall bitte die Ports IKE:500 und VPN NAT: 4500 auf die Zywall leiten, spricht WAN to WAN

----

Jetzte sollte es gehen, bei mir funktioniert es mit meiner Zywal 35 stabil!

Viel Spass

 

[wuesten.fuchs]

Hi FlyWord,
danke, dass du dir die Mühe genommen hast, meine Screenshots durchzuarbeiten! Eine bzw. zwei Fragen hab ich aber noch:

Virtuelle IP ändern auf eine die nicht mit 192.168.4.xx lautet, z.b. 192.168.5.xx

D.h. ich stelle im VPN Client die virtuelle IP auf z.B. 192.168.5.1 ein (und nicht 192.168.5.0)?

In der Zywall bitte die Ports IKE:500 und VPN NAT: 4500 auf die Zywall leiten, spricht WAN to WAN

Brauche ich denn ein Port Forwarding? Die ZyWall, die gleichzeitig der VPN-Gateway ist, hat ja die IP 192.168.4.1. Ein Port Forwarding auf ebendiese IP bringt ja nix, oder?
Ansonsten habe ich in den Firewall-Einstellungen die entsprechenden Services (500,4500) für WAN to WAN freigeschaltet - siehe Screenshot.

 

[FlyWord]

Hallo, ich helfe gerne, ich hoffe die antworten stimmen auch ;-)

Die IP 192.168.5.0 kannst du nicht verwenden da dies die Host Adresse ist, ja du könntest die 192.168.5.1 verwenden.

So viel mir bekannt ist (wenn falsch, bitte korrigieren) kannst du nicht mit der gleichen virtuellen IP in dein VPN Netz wählen welches das gleiche IP Subnet enthält.

Sprich:
Dein Zywall Netzwerk ist 192.168.4.0
Dein VPN Client hast du mit einer Virtuellen IP von 192.168.4.0 eingetragen (geht sowieso nicht, da hättest du 4.1 - 254 machen müssen)

Somit sind beide im gleiche Netz, dein Zywall kann aber die IP routen, d.h. du kannst beim Virtuellen Adapter irgend eine IP eintragen, jedoch würde ich eine nehmen die nicht im gleichen Zywall Subnet liegt und sicher nicht mit 0 endet.

Die IP 192.168.4.0 mit der Subnetzmaske 255.255.255.0 ist die erste IP im Subnet, diese kann nicht verwendet werden.

Ich würde Vorschlagen gebe beim Virtuellen Adapter einfach mal folgende Adresse an:
IP: 192.168.5.1 - .254
Subnetzmaske: 255.255.255.0

Zu deinem Printscreen, sofern es bei WAN to WAN eingestellt ist - ist es richtig!

Ich hoffe es klappt?

 

[wuesten.fuchs]

Aaaaah... ja mit der IP war ich mir nicht sicher. Danke für die Erklärung! Ich werd mal die IP 192.168.5.1 mit der Maske 255.255.255.0 nehmen und dann heute Abend ausprobieren und auf jeden Fall im Forum berichten!

Vielen, vielen Dank bisher!

 

[hansfritz]

Perlscript zum erstellen einer ike configuration an Hand der fritzbox.conf

das Skript erstellt aus dem mit FRITZ!Box-Fernzugang einrichten.exe erstellten Dateien vpnuser.conf oder fritzbox.conf
eine IKE SHREW Konfiguration unter Ubuntu getestet mit SHREW 2.1.4 unter ibex wodurch die Einrichtung noch einfacher ist.
Download vpnseter.txt
umbenennen

mv vpnseter.txt  vpnseter.pl

recht vergeben

chmode 744 vpnseter.pl

./vpnseter.pl vpnuser.conf 
oder 
./vpnseter.pl fritbox.conf

die Konfiguration liegt jetzt in ~/.ike/sites/

jetzt

vim /etc/sysctl.d/10-network-security.conf

# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

ändern

sudo reboot

und alles sollte laufen wie es soll :spocht: