| Thema |
Verfasser |
Letzte Antwort |
| VPN Tunnel okay,beide Gateways pingbar, Clients nicht erreic |
christianj ( ---.a1.net) |
16 Feb 2010 11:27 |
Hallo Ich habe folgendes Problem !
Ich habe ein VPN Netzwerk zwischen einem Ubuntu Server 8.04 und einer Phion Netfence. Der Tunnel zwischen beiden Systemen steht und funktioniert. Ich kann vom Ubuntu Server Clients im VPN Partnernetz pingen und umgekehrt geht auch.Der ping von Client zu Client geht jedoch nicht. Wenn ich mit tcpdump einen Ping vom Client1 zu Client2 verfolge geht er über VPN2 korrekt zum Ziel bleibt aber auf dem Retourweg am VPN1 hängen
Netzaufbau links
Client1-eth1(VPN1)eth0-DSL Router-Internet-----VPN2--Client2
Client1 IP:192.168.200.200
VPN eth1 IP:192.168.200.20
VPN eth0 IP:88.117.168.126
DSL Router IP:88.117.168.125 -->routet alles durch
Client2 IP:10.221.1.1
Routing Tabelle
88.117.168.124/30 dev eth0 proto kernel scope link src 88.117.168.126
192.168.200.0/24 dev eth1 proto kernel scope link src 192.168.200.20
10.0.0.0/8 dev eth0 scope link src 192.168.200.20
default via 88.117.168.125 dev eth0 metric 100
/proc/sys/net/ipv4/ip_foward ist auf 1
Das seltsame daran ist das dieselbe Konfiguration mit SLES9 als VPN Gateway funktioniert hat. Kann es sein das mir eine zusätzliche Route fehlt.
Bin für alle Vorschläge dankbar
Christian
|
| ||
| RE: VPN Tunnel okay,beide Gateways pingbar, Clients nicht er... | Ralf ( ---.dip.t-dialin.net) | 16 Feb 2009 09:23 |
Hallo,
mir fehlen ein paar Informationen. Ist VPN1 die Linux-Maschine? Befindet sich hier eine Firewall und wie ist die konfiguriert?
Gruß,
Ralf |
| RE: RE: VPN Tunnel okay,beide Gateways pingbar, Clients nich... | christianj ( ---.121.206.190) | 16 Feb 2009 09:34 |
Hallo Ralf
VPN1 ist der Ubuntu Server, wenn ich von einem client aus dem 192er netz auf einen client in das 10er Netz pinge sehe ich mit tcpdump die icmp anfrage am 10er client und die Antwort kommt retour bis zur externen NIC(eth0) des VPN1 an, wird aber nicht an die interne NIC(eth1) weitergeleitet
das FW Script
INTDEV="eth1"
EXTDEV="eth0"
LAN1="10.0.0.0/8"
LAN2="192.168.0.0/16"
IPTABLES="/usr/sbin/iptables"
case "$1" in
'start')
# vorhandene regeln löschen
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -F INPUT
# alles sperren
$IPTABLES -P FORWARD DROP
$IPTABLES -P INPUT DROP
# input kette
# udp port 500 + esp protokoll auf wan seite öffnen
$IPTABLES -A INPUT -i $EXTDEV -p udp --sport 500 --dport 500 -m state --state NEW -j ACCEPT
$IPTABLES -A INPUT -i $EXTDEV -p esp -m state --state NEW -j ACCEPT
$IPTABLES -A INPUT -i $EXTDEV -p tcp --dport 22 -m state --state NEW -j ACCEPT
#dhcp anfragen erlauben
$IPTABLES -A INPUT -i $INTDEV -p udp --sport bootpc --dport bootps -m state --state NEW -j ACCEPT
#lan öffnen
# 10 --> 192
$IPTABLES -A INPUT -s $LAN1 -d $LAN2 -m state --state NEW -j ACCEPT
# 192 -->10
$IPTABLES -A INPUT -s $LAN2 -d $LAN1 -m state --state NEW -j ACCEPT
# 192 --> 10
$IPTABLES -A INPUT -s $LAN2 -d $LAN2 -m state --state NEW -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# output kette
#$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Forward Kette
# vpn verkehr forwarden
$IPTABLES -A FORWARD -m policy --dir in --mode tunnel --pol ipsec --proto esp -j ACCEPT
$IPTABLES -A FORWARD -m policy --dir out --mode tunnel --pol ipsec --proto esp -j ACCEPT
# lokalen verkehr erlauben (loopback device)
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT
sg christian |
| RE: RE: RE: VPN Tunnel okay,beide Gateways pingbar, Clients... | Ralf ( ---.dip.t-dialin.net) | 16 Feb 2009 09:53 |
Hallo Christian,
das sieht erstmal gut aus. Firewall sollte nicht stören.
Erste Anmerkung, die ich habe: ESP solltest Du nicht zustandsorientiert filtern, sondern grundsätzlich zulassen. Die Linux-Implementierung vergisst ESP-Verbindungen nach 10 Minuten Inaktivität. Das kann dann schon mal zu Problemen führen, aber nicht hier.
Zweite Anmerkung: Was sollten die Regeln, die mit 10-->192 und umgekehrt benannt wurden? Für das VPN ist alles Forwarding.
Zur Sicherheit: Wenn Du pingst, kannst Du dann nachvollziehen, welche Regel aktiviert wird? Hierzu kann man die Zähler der Regeln beobachten (iptables -vnL). Das funktioniert aber nicht gut mit SSH und bei gleichzeitigen weiteren Netzwerkverkehr.
Neue Fragen:
Wie sehen denn die Policies aus (setkey -DP)? Welchen Kernel verwendest Du? Womit baust Du das VPN auf (racoon, openswan, strongswan)?
Gruß,
Ralf
|
| RE: RE: RE: VPN Tunnel okay,beide Gateways pingbar, Clients... | christianj ( ---.121.206.190) | 16 Feb 2009 10:15 |
Kernelversion:2.6.24-23-server
Der Tunnelaufbau erfolgt mit dem isakmpd Dämon
---------------------------------------
setkey -DP
10.0.0.0/8[any] 192.168.200.0/24[any] any
in ipsec
esp/tunnel/80.120.254.147-88.117.168.126/use
created: Feb 16 11:02:38 2009 lastused: Feb 16 11:03:17 2009
lifetime: 0(s) validtime: 0(s)
spid=184 seq=1 pid=8317
refcnt=3
192.168.200.0/24[any] 10.0.0.0/8[any] any
out ipsec
esp/tunnel/88.117.168.126-80.120.254.147/require
created: Feb 16 11:02:38 2009 lastused: Feb 16 11:05:56 2009
lifetime: 0(s) validtime: 0(s)
spid=177 seq=2 pid=8317
refcnt=29
(per-socket policy)
in none
created: Feb 16 11:02:38 2009 lastused:
lifetime: 0(s) validtime: 0(s)
spid=163 seq=3 pid=8317
refcnt=1
(per-socket policy)
in none
created: Feb 16 11:02:38 2009 lastused: Feb 16 11:05:49 2009
lifetime: 0(s) validtime: 0(s)
spid=147 seq=4 pid=8317
refcnt=1
(per-socket policy)
out none
created: Feb 16 11:02:38 2009 lastused:
lifetime: 0(s) validtime: 0(s)
spid=172 seq=5 pid=8317
refcnt=1
(per-socket policy)
out none
created: Feb 16 11:02:38 2009 lastused: Feb 16 11:05:49 2009
lifetime: 0(s) validtime: 0(s)
spid=156 seq=0 pid=8317
refcnt=1
--------------------------------
Firewall iptables -vnL
Chain INPUT (policy DROP 6 packets, 272 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spt:500 dpt:500 state NEW
0 0 ACCEPT esp -- eth0 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW
4 1312 ACCEPT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67 state NEW
1 60 ACCEPT all -- * * 10.0.0.0/8 192.168.0.0/16 state NEW
0 0 ACCEPT all -- * * 192.168.0.0/16 10.0.0.0/8 state NEW
8 1009 ACCEPT all -- * * 192.168.0.0/16 192.168.0.0/16 state NEW
630 249K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 120 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir in pol ipsec proto 50 mode tunnel
380 30305 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec proto 50 mode tunnel
Chain OUTPUT (policy ACCEPT 527 packets, 64613 bytes)
pkts bytes target prot opt in out source destination
4 200 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
Chain L (0 references)
pkts bytes target prot opt in out source destination
-----------------
sg
|
| RE: RE: RE: RE: VPN Tunnel okay,beide Gateways pingbar, Clie... | Ralf ( ---.dip.t-dialin.net) | 16 Feb 2009 10:52 |
Da haben wir das Problem. Ich habe schon ewig nicht mehr mit dem Isakmpd gearbeitet, weiss daher nicht ob er eine Lösung bietet:
Ab Kernel 2.6.10 werden drei Policies für einen Tunnel benötigt:
in, out und fwd!
Die fwd Policy fehlt. Diese muss eine Kopie der in-Policy darstellen. Fehlt diese werden keine ankommenden Pakete weitergeleitet.
Die Werkzeuge setkey und Racoon, *swan erzeugen diese Policy per Default als Kopie. Ohne geht es nicht.
Zum Test kannst Du mit setkey versuchen die IN-Policy als FWD-Policy zu kopieren.
Gruß,
Ralf |
| RE: RE: RE: RE: RE: VPN Tunnel okay,beide Gateways pingbar,... | christianj ( ---.121.206.190) | 16 Feb 2009 13:30 |
Hallo Ralf !
Vielen Dank für die Hilfe
Sg christian |
| RE: RE: RE: RE: RE: RE: VPN Tunnel okay,beide Gateways pingb... | monday ( ---.static.qsc.de) | 1 Feb 2010 11:03 |
Hallo, ich habe ein ähnliches Problem, ich benutze ein Linux auf Debian Basis und habe bereits einen Tunnel etabliert und kann auch von dem Linux-System ins Zielnetzwerk pingen und arbeiten, allerdings wenn ich ein Windows-Client den Linux-Server (Tunnelpoint) nutzen soll, geht die Anfrage nicht wie gewünscht in den Tunnel sondern an den Standard-Gateway. Die IPv4 Weiterleitung ist auch aktiviert, allerdings kann ich mir keinen Reim drauf geben, wieso die Anfrage auf die Default-Route geht und nicht vorher in den Tunnel abbiegt.
Kann mir jemand helfen?
lg
monday |
| RE: RE: RE: RE: RE: RE: RE: VPN Tunnel okay,beide Gateways p... | monday ( ---.static.qsc.de) | 2 Feb 2010 11:16 |
On 1 Feb 2010 11:03 'monday' wrote:
> Hallo, ich habe ein ähnliches Problem, ich benutze ein Linux auf Debian Basis und habe bereits einen Tunnel etabliert und kann auch von dem Linux-System ins Zielnetzwerk pingen und arbeiten, allerdings wenn ich ein Windows-Client den Linux-Server (Tunnelpoint) nutzen soll, geht die Anfrage nicht wie gewünscht in den Tunnel sondern an den Standard-Gateway. Die IPv4 Weiterleitung ist auch aktiviert, allerdings kann ich mir keinen Reim drauf geben, wieso die Anfrage auf die Default-Route geht und nicht vorher in den Tunnel abbiegt.
>
> Kann mir jemand helfen?
>
> lg
> monday
Weiß jemand, ob OpenSWAN eine Access List pflegt? Der bestimmt, wer diesen Tunnel nutzen darf. |
| RE: RE: RE: RE: RE: RE: RE: VPN Tunnel okay,beide Gateways p... | monday ( ---.static.qsc.de) | 2 Feb 2010 11:16 |
On 1 Feb 2010 11:03 'monday' wrote:
> Hallo, ich habe ein ähnliches Problem, ich benutze ein Linux auf Debian Basis und habe bereits einen Tunnel etabliert und kann auch von dem Linux-System ins Zielnetzwerk pingen und arbeiten, allerdings wenn ich ein Windows-Client den Linux-Server (Tunnelpoint) nutzen soll, geht die Anfrage nicht wie gewünscht in den Tunnel sondern an den Standard-Gateway. Die IPv4 Weiterleitung ist auch aktiviert, allerdings kann ich mir keinen Reim drauf geben, wieso die Anfrage auf die Default-Route geht und nicht vorher in den Tunnel abbiegt.
>
> Kann mir jemand helfen?
>
> lg
> monday
Weiß jemand, ob OpenSWAN eine Access List pflegt? Der bestimmt, wer diesen Tunnel nutzen darf. |
| RE: RE: RE: RE: RE: RE: RE: VPN Tunnel okay,beide Gateways p... | Ralf ( ---.dip.t-dialin.net) | 2 Feb 2010 15:56 |
Äh, was heisst denn abbiegt?
Also, ich verstehe Dich so, dass Du einen Linux-Rechner hast, der selbst einen VPN-Tunnel aufbaut. Dieser Rechner ist nicht das Default-Gateway. Dieser kann dann aber auch den VPN-Tunnel nutzen, richtig?
Jetzt hast Du einen zweiten Rechner, der auch den VPN-Tunnel nutzen soll (Windows) richtig?
Dann muss dieser Rechner natürlich wissen, dass er für den VPN-Tunnel das Paket zu dem Linux-Rechner schickt und nicht an das Default-GW. Dazu sind zunächst einmal Routen da.
Oder gibt es die Route und das Paket wird tatsächlich an den richtigen Linux-VPN-Gateway geschickt und dieser schickt es an das Default-Gateway weiter? Dann stimmt wahrscheinlich mit Deinen leftsubnet/rightsubnet Einstellungen etwas nicht.
Gruß,
Ralf
|
| RE: VPN Tunnel okay,beide Gateways pingbar, Clients nicht er... | monday ( ---.static.qsc.de) | 3 Feb 2010 14:05 |
Danke für deine Antwort bzw. Hilfe und
enschuldige bitte, die lockerer Umgangssprache von mir.
Der Linux-VPN-Server hat natürlich auch einen eigenen Default-Gateway und zusätzlich verwaltet er die VPN-Tunnels. Ja, die Windows Clients haben einen entsprechenden Route, damit sie den Linux-VPN-Server benutzen bei der entsprechenden IP. Diese funktioniert auch soweit (tcpdump) zeigt auf der lokalen Netzwerkseite die Anfragen der Clients.
Diese Anfragen schickt der Linux-VPN-Server aber nicht in den entsprechenden Tunnel sondern, an seinen Default-Gateway, was allerdings die gleiche Schnittstelle ist.
Das Leftsubnet und die LeftSourceIP habe angepasst, weil der Kunde im Ziel-VPN eine bestimmte Absender-IP benötigt, welche die Pakete haben sollen, wenn sie durch den Tunnel kommen. Ist dies dann problematisch fürs Routing?
Was mich allerdings wundert, ist dass man vom Terminal des Linux-VPN-Servers ins Ziel-VPN Netzwerk arbeiten kann (Ping, FTP, etc.).
Ändere ich das Leftsubnet auf das Subnetz unserer Firma ab, wird der Tunnel nicht mehr etabliert. :-( |
| RE: RE: VPN Tunnel okay,beide Gateways pingbar, Clients nich... | Ralf ( ---.dip.t-dialin.net) | 3 Feb 2010 17:16 |
Ok.
Zur Erklärung:
IPsec schützt nicht nur die Pakete im Tunnel vor den Blicken von außen, sondern auch den Tunnel vor nicht erlaubten Paketen. Sprich, wenn ein Paket die falsche Absenderadresse hat, darf das Paket nicht in den Tunnel und wird dann an das Default-GW weitergeleitet.
Wenn die Anpassung von leftsubnet den nicht-Aufbau des Tunnels erzeugt, kann man sich nur mit NAT helfen.
Das das GW selbst das kann, hängt mit der leftsourceip zusammen. Diese gilt aber nur für das GW selbst und nicht für die clients dahinter.
Gruß,
Ralf
|
| RE: RE: RE: VPN Tunnel okay,beide Gateways pingbar, Clients... | monday ( ---.static.qsc.de) | 15 Feb 2010 10:12 |
Vielen Dank Ralf für die Informationen.
Leider bin ich erst jetzt zur Umsetzung eines NATs gekommen.
Allerdings habe ich da noch meine Problemchen und vielleicht könntest du oder andere Forumuser helfen.
Zielnetzwerk sei mal: 111.0.0.0/8
Quellnetzwerk sei mal: 10.2.3.0/24
nötige IP-Adresse (leftsubnet): 1.2.3.4/32
Ich versuche nun mit iptables eine Maskierung meiner Quell-IP vorzunehmen, damit meine Pakete in den Tunnel weitergeleitet werden. Diese MAskierung sollte dann aber vor dem eigentlichen Routing des Kernels passieren, deswegen "PREROUTING".
Also könnte der Anfang so aussehen:
"iptables -t nat -A PREROUTING .."
Die entsprechende Synatax ist mir noch nicht ganz geläufig. |
| RE: RE: RE: RE: VPN Tunnel okay,beide Gateways pingbar, Clie... | Ralf ( ---.dip.t-dialin.net) | 15 Feb 2010 12:20 |
Hallo,
Du willst ein SNAT, das geht nur in POSTROUTING. Sollte aber auch gehen, wenn Du einen einigermaßen aktuellen Kernel hast. Dann werden die Pakete komplett einmal den Kernel unverschlüsselt durchlaufen und genattet und anschließend dann verschlüsselt und geroutet.
Gruß,
Ralf |
| RE: RE: RE: RE: RE: VPN Tunnel okay,beide Gateways pingbar,... | monday ( ---.static.qsc.de) | 15 Feb 2010 14:14 |
Danke für deine schnelle Hilfe Ralf, aber irgendwie läuft es noch immer nicht ... hab nun ein Postrouting angelegt, aber was mich wundert ist ... dass er unter "iptables -L -t nat" nicht das zielnetzwerk anzeigt (also nicht als IP), sondern eine DNS-Auflösung vornimmt und zwar die für die entsprechende IP-Adresse, ist das ein Problem, dass das Zielnetzwerk des Kunden eine 126.x.x.x hat?
Also anstatt 126.0.0.0 steht nun unter Destination "softbank126000000000.bbtec.net", sehr merkwürdig. |
| RE: RE: RE: RE: RE: RE: VPN Tunnel okay,beide Gateways pingb... | Ralf ( ---.61.58.54.host.de.colt.net) | 16 Feb 2010 11:27 |
Das macht der iptables Befehl. Um das zu unterdrücken zusätzlich ein -n angeben:
iptables -vnL -t nat
Gruß,
Ralf
|
17 Oct 2008: