PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : openvpn tunnel steht - routingproblem



Gordon
03.08.04, 09:16
Hallo,
ich weiss dieses Thema wurde schon öfter durchgekaut,
aber ich komme mit meinem VPN einfach nicht weiter...

Ich habe einen Server mit fester ip, der als VPN-Server und Firewall dient (IP extern eth0 62.138.123.174 IP LAN 192.168.5.220, tap IP 192.168.5.220 ). Zugreifen möchte ich mit Windowsclients mit openvpn als Roadwarrior (Also meistens DSL und kein Router mehr dazwischen). Den Openvpntunnel habe ich schon zustande gebracht. Auf dem Tap Device des Servers kommen auch Broadcasts der 137-139er Windows Ports an, wenn ich mich mit einem Win XP Client auf dem Server verbinde. Ins LAN komme ich aber nicht. Pingen geht auch nicht. Ich kann nicht mal die Tap0 IP anpingen (in beide Richtungen).
Iptables habe ich am Laufen, habe Port 5000 Input auf accept gesetzt und für die tap und tundevices input und forward auf accept gesetzt.

Ich denke, dass wird ein Routingproblem sein, aber ich blicke grade nicht durch.

Anbei meine Routingtables des Servers, WinXPClients und meine openvpnconfigfiles.

Nochmal ein kurzer Netzwerkaufbau

Server IP ex 62.138.123.174 --------Client IP extern DSL
Server IP Lan 195.168.5.220 ------- Client IP VPN 192.168.5.252

Der Server hängt an einem Netopia router mit der ip 62.138.123.160
und der Winclient an einem DSL Router mit der internen ip 192.168.0.1 (daher hat der Client die reale ip 192.168.0.2 (sind aber komplett auf forwarding gestellt).

Danke und Gruesse Gordon

Schärple
03.08.04, 10:30
Hi,

das hört sich für mich danach an, dass Du TCP Port 5000 freigegeben hast und nicht den benötigten UDP Port. Die Routen scheinen zu stimmen.


Gruß

Gordon
03.08.04, 10:41
Halllo Schärple,
anbei meine Iptablerules. Sowie ich weiss habe ich nur den udp-port 5000 freigegeben und nicht tcp. Aber eine Tunnelverbindung kommt auch zustande. Denn das sagt mir das Logfile des Servers.

Gruesse Gordon

# Alte Rules loeschen
iptables -t filter -F
iptables -t nat -F

#Allow client to route through via NAT (Network Address Translation)
iptables -t nat -A POSTROUTING -s 192.168.5.0/255.255.255.0 -o $OINTERFACE -j MASQUERADE


# Neue Rules
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

# Ungewoehnliche Pakete loeschen
iptables -A FORWARD -m unclean -j DROP
iptables -A INPUT -m unclean -j DROP

#Creating states chain
iptables -N allowed-connection
iptables -F allowed-connection
iptables -A allowed-connection -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j allowed-connection
iptables -A FORWARD -j allowed-connection
iptables -A OUTPUT -j allowed-connection

# SSH
#Creating incoming ssh traffic chain"
iptables -N allow-ssh-traffic-in
iptables -F allow-ssh-traffic-in
#Flood protection
iptables -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags ALL RST --dport ssh -j ACCEPT
iptables -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags ALL FIN --dport ssh -j ACCEPT
iptables -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags ALL SYN --dport ssh -j ACCEPT
iptables -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT
#Creating outgoing ssh traffic chain"
iptables -N allow-ssh-traffic-out
iptables -F allow-ssh-traffic-out
iptables -A allow-ssh-traffic-out -p tcp --dport ssh -j ACCEPT

iptables -A INPUT -j allow-ssh-traffic-in
iptables -A OUTPUT -j allow-ssh-traffic-out
iptables -A FORWARD -j allow-ssh-traffic-in


#Catch portscanners
#Creating portscan detection chain"
iptables -N check-flags
iptables -F check-flags
iptables -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -m limit --limit 5/minute -j LOG --log-level alert --log-prefix "NMAP-XMAS:"
iptables -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
iptables -A check-flags -p tcp --tcp-flags ALL ALL -m limit --limit 5/minute -j LOG --log-level 1 --log-prefix "XMAS:"
iptables -A check-flags -p tcp --tcp-flags ALL ALL -j DROP
iptables -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -m limit --limit 5/minute -j LOG --log-level 1 --log-prefix "XMAS-PSH:"
iptables -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
iptables -A check-flags -p tcp --tcp-flags ALL NONE -m limit --limit 5/minute -j LOG --log-level 1 --log-prefix "NULL_SCAN:"
iptables -A check-flags -p tcp --tcp-flags ALL NONE -j DROP
iptables -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -m limit --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/RST:"
iptables -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/FIN:"
iptables -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

iptables -A INPUT -i $OINTERFACE -j check-flags


# HTTP/S
iptables -A OUTPUT -p TCP --dport 80 -j ACCEPT
iptables -A OUTPUT -p TCP --dport 443 -j ACCEPT
iptables -A FORWARD -p TCP --dport 80 -j ACCEPT
iptables -A FORWARD -p TCP --dport 443 -j ACCEPT

# DNS-Abfragen nach draussen offen
iptables -A OUTPUT -p UDP --sport 53 -j ACCEPT
iptables -A OUTPUT -p UDP --dport 53 -j ACCEPT

# PING extern kill/intern yes
iptables -A INPUT -i $OINTERFACE -p ICMP --icmp-type ping -j DROP
iptables -A INPUT -i $IINTERFACE -p ICMP --icmp-type ping -j ACCEPT



# Block outgoing Net-Bios
iptables -A FORWARD -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A FORWARD -p udp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p udp --sport 137:139 -o eth0 -j DROP

#VPN
iptables -A INPUT -p udp --dport 5000 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A INPUT -i tap+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT

#XTEN Voice over IP
iptables -A INPUT -p udp --dport 5060 -j ACCEPT
iptables -A INPUT -p udp --dport 8000 -j ACCEPT
iptables -A INPUT -p udp --dport 8001 -j ACCEPT
iptables -A FORWARD -p udp --dport 5060 -j ACCEPT
iptables -A FORWARD -p udp --dport 8000 -j ACCEPT
iptables -A FORWARD -p udp --dport 8001 -j ACCEPT




#Loopback darf alles
iptables -A INPUT -i lo -j ACCEPT
iptables -A FORWARD -o lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT


#Destination NAT fuer LAN erlauben
# iptables -A FORWARD -i $OINTERFACE -d 192.168.5.0/24 -j ACCEPT

#Rest killen bzw. loggen
iptables -A FORWARD -i $OINTERFACE -m state --state NEW,INVALID -j LOG
iptables -A FORWARD -i $OINTERFACE -m state --state NEW,INVALID -j DROP
iptables -A INPUT -i $OINTERFACE -m state --state NEW,INVALID -j LOG
iptables -A INPUT -i $OINTERFACE -m state --state NEW,INVALID -j DROP
# iptables -A OUTPUT -m state --state NEW,INVALID -j LOG

Gordon
03.08.04, 11:31
Hi, nochmal
wenn ich versuche den VPN-Server anzupingen vom Windowsclient bekomme
ich über einen tcpdump auf tap0 des Servers folgende Ausgabe:

11:27:48.167756 arp who-has 192.168.5.220 tell 192.168.5.251
11:27:48.167783 arp reply 192.168.5.220 is-at 00:ff:fe:16:e6:8f
11:27:53.452418 arp who-has 192.168.5.220 tell 192.168.5.251
11:27:53.452438 arp reply 192.168.5.220 is-at 00:ff:fe:16:e6:8f
11:27:56.066126 arp who-has 192.168.5.220 tell 192.168.5.251
11:27:56.066148 arp reply 192.168.5.220 is-at 00:ff:fe:16:e6:8f
11:28:01.462524 arp who-has 192.168.5.220 tell 192.168.5.251
11:28:01.462544 arp reply 192.168.5.220 is-at 00:ff:fe:16:e6:8f

Der Ping gibt keine Rückantwort.
Weiss jetzt keinen Rat mehr

Gordon

Gordon
03.08.04, 13:49
Hallo,
ich bin immer noch am Basteln und komme der Lösung nicht näher.
Ein Arp-request auf dem Server zeigt wohl die IP des Clients an, kann aber keine MAC Adresse dazu finden...

Address HWtype HWaddress Flags Mask Iface
192.168.5.251 incomlete eth1
62.138.123.161 ether 00:00:C5:8C:31:E8 C eth0
192.168.5.189 ether 00:0E:A6:09:70:01 C eth1
192.168.5.166 ether 00:0C:6E:CE:95:77 C eth1

Gordon
03.08.04, 16:57
Hallo,
vielleicht kann mir ja doch jemand helfen.... :)

Ich bin weitergekommen.

Wenn ich virtuelle IP-Adressen für die VPN-Verbindung vergebe, die nicht identisch mit der realen sind und auch ein anderes Subnet haben, dann klappt es mit dem pingen.
Auf der Serverseite habe ich ja auf eth1 mit 192.168.5.220.
Wenn ich jetzt für tap0 192.168.100.220 nehme klappt es mit dem pingen und der CLient mit der ip 192.168.100.246 bekommt eine Antwort.

Ist die IP von tap0 identisch mit der ip von eth1 also 192.168.5.220 kommen die Pakete laut tcpdump an, aber gehen scheinbar dann ins Nirvana.

Folglich habe ich wohl ein Serverseitiges Routingproblem.

Die Daten die an tap0 gehen scheinen nicht an eth1 zu gehen...

Irgentwie fehlt mir grade der Durchblick.
Vielleicht kann mir ja mal jemand einen Tip geben.... ;)


Gruss Gordon

mbo
03.08.04, 17:22
Wenn ich virtuelle IP-Adressen für die VPN-Verbindung vergebe, die nicht identisch mit der realen sind und auch ein anderes Subnet haben, dann klappt es mit dem pingen.
Auf der Serverseite habe ich ja auf eth1 mit 192.168.5.220.
Wenn ich jetzt für tap0 192.168.100.220 nehme klappt es mit dem pingen und der CLient mit der ip 192.168.100.246 bekommt eine Antwort.


Hm, wolltest Du jetzt das Routing mit Deinem Willen erschlagen, oder hattest Du Angst, Du wärst erschlagen, wenn Dir jemand das Routing-Howto um die Ohren schlägt? ;)

Erstmal: für ein sauberes Routing nimmt man unterschiedliche Netze, alles andere ist nicht wirklich trivial, um es im produktiven Umfeld einfach mal so zu probieren.
Zweitens: Wenn Du unterschiedliche Netze machst, und VPN-Netze sind nun ein anderes Netz, als Deine LAN, dann nutze auch unterschiedliche Subnetze in der Adressierung.

Das


192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0

ist fast schon Routingvergewaltigung ... Oder würdest Du den Weg kennen, wenn jemand zu Dir sagt: Nach Osten gelangen Sie über den Westflügel, aber nach Osten gelangen Sie über den Nordflügel.

Und für das Routing im VPN-Netz würde ich für den GW-Adressen auch andere SubNetze nehmen, dann bleibt es auch bei zukünftigen Änderungen skalier- und routebar - das trifft aber erst zu, wenn Du mehr als zwei Netze per VPN verbinden willst.

cu/2 iae


PS: Bei Bedarf stelle ich Dir gerne eine Routingtable für drei VPN-Netz mit openVPN zur Verfügung ...

Gordon
03.08.04, 17:43
Hallo,



ist fast schon Routingvergewaltigung ... Oder würdest Du den Weg kennen, wenn jemand zu Dir sagt: Nach Osten gelangen Sie über den Westflügel, aber nach Osten gelangen Sie über den Nordflügel.


sorry, manchmal sieht man vor lauter Bäumen den Wald nicht mehr.

Habe die VPN-Verbindung jetzt in ein anderes Subnet gelegt. Pingen klappt.

Ich habe aber immer noch das Problem den Traffic nach eth1 ins andere subnet zu leiten...

Gruesse Gordon

mbo
03.08.04, 17:58
Ich habe aber immer noch das Problem den Traffic nach eth1 ins andere subnet zu leiten...


Ich muß es mal für mich aufmalen ...
eth1 (DSL) 62.138.123.174
<Router>
eth0 (LAN) 192.168.0.1/24
tap0 (VPN) 192.168.5.1/24 (peer 192.168.5.2)

tap0 (VPN) 192.168.5.2/24 (peer 192.168.5.1)
NIC (Client) 192.168.0.2/24
<Client>

Oder geht das VPN über den Router zu einem VPN-Server irgendwo im Internet?

cu/2 iae

Gordon
03.08.04, 18:13
Hi nochmal,

also der Server:

Feste IP im Inet eth0 62.138.123.174
Interne IP 192.168.5.220
tap0 192.168.6.1


Roadwarrior:
mit DSL hinter DSL Router 192.168.0.1 (ohne VPN)
ip 192.168.0.2
tap0 IP 192.168.6.100

Im Prinzip so wie Du das geschrieben hast, nur dass ich den VPNtunnel
über die xxx.xxx.6.xxx laufen lasse.

Danke für Deine Hilfe...

Gruesse Gordon

mbo
03.08.04, 18:29
Hi nochmal,

also der Server:

Feste IP im Inet eth0 62.138.123.174
Interne IP 192.168.5.220
tap0 192.168.6.1


Roadwarrior:
mit DSL hinter DSL Router 192.168.0.1 (ohne VPN)
ip 192.168.0.2
tap0 IP 192.168.6.100

Im Prinzip so wie Du das geschrieben hast, nur dass ich den VPNtunnel
über die xxx.xxx.6.xxx laufen lasse.

Danke für Deine Hilfe...

Gruesse Gordon
Hm, ich fang wohl mal mit den routingtables an, vielleicht hilft es dir auf die sprünge, wenn du es "siehst"

Client im eigenen LAN 192.168.0.24/24 mit Defaultgateway 192.168.0.1

Gateway mit LAN 192.168.0.1/24 und DMZ mit 10.7.3.2/24 mit Defaultgateway 10.7.3.1/24

Firewall mit DMZ 10.7.3.1/24 und PPPoE und tun0 10.7.1.2 (peer 10.7.1.1)

Server mit tun0 10.7.1.1 (peer 10.7.1.2)

Am Client habe ich gar nichts gemacht, außer der Defaultgateway, ergo zu vernachlässigen.

Der Gateway:


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.7.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.7.3.1 0.0.0.0 UG 0 0 0 eth1

Auch hier nur die Defaultroute 0.0.0.0 10.7.3.1 0.0.0.0 UG 0 0 0 eth1

Der/Die/Das Firewall:


Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
145.253.4.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.7.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.7.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 145.253.4.2 0.0.0.0 UG 0 0 0 ppp0

Wäre hinter dem Server noch ein Netz (10.7.2.0/24), welches ich erreichen möchte, würde die route


10.7.2.0 10.7.1.1 255.255.255.0 UH 0 0 0 tun0

hinzukommen. Ein Auszug aus der Route für das zweite VPN zur Ansicht:


10.7.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun2
10.7.2.0 10.7.1.1 255.255.255.0 UG 0 0 0 tun2


Da mein Client und der Gateway bei dem zu erreichenden Server immer die öffentlichen IP-Adresse auflösen würde, sofern ich nicht meinen DNS dementsprechend konfigurieren würde (was mir zuviel Aufwand ist), habe ich auf der Firewall DNAT eingesetzt:


iptables -t nat -A PREROUTING -p tcp -d ip.des.ser.ver -j DNAT --to-destination $VPN
iptables -t nat -A PREROUTING -p icmp -d ip.des.ser.ver -j DNAT --to-destination $VPN

Übrigens, lokale Verbindungen von der Firewall auf die VPN-Adresse umbiegen lassen sich leider nur durch neukompilieren der Distributions-Standardkernel erledigen :(

Ich hoffe, daß ist verständlicher, als eine rein theoretische routingdarlegung.

cu/2 iae

Gordon
03.08.04, 19:25
Hallo nochmal,


Wäre hinter dem Server noch ein Netz (10.7.2.0/24), welches ich erreichen möchte, würde die route

10.7.2.0 10.7.1.1 255.255.255.0 UH 0 0 0 tun0

hinzukommen.


also vom Prinzip her habe ich das alles verstanden..

Ich müsste also nur auf dem VPN-Server den Routingeintrag für das tap device ändern.
Also:
192.168.5.0 192.168.6.1 255.255.248.0 UH 0 0 0 tap0

Dann müsste ich die route für eth1 aber auch ändern, da sonst die Pakete
wieder ins Nirwana gehen, oder?

Also:
192.168.5.0 192.168.6.1 255.255.248.0 UH 0 0 0 eth1

Was bedeuten würde, dass ein surfen über diesen Server/Firewall nicht mehr
möglich ist.

Na ja vielleicht auch nur zu warm hier....


Danke erst mal für Deine Mühe..

Werde mich morgen noch mal dran setzen

Gruss Gordon

Gordon
04.08.04, 13:04
Hallo,
also ich habe endlich das VPN am Laufen....

Wen es interessiert, hier meine Lösung:

Hier mein Netzaufbau:

Der VPN Tunnel läuft über das Virtuelle Netz 192.168.6.0
Mein Heimnetz hinter meinem DSL Router hat das Netz 192.168.0.0
Das Netz in der Firma hat die LAN Adresse 192.168.5.0 und eine externe statische IP 62.xxx.xxxx.xxx

Erst mal zum Client bei mir zuhause:

meine local.conf

dev tap # device
port 5000 # Port
remote 62.xxx.xxx.xxx #IP des Tunnel-Endpunktes (Rechner mit statischer IP)
ifconfig 192.168.6.100 255.255.255.0 # Virtuelle IP für den VPN Tunnel
secret key.txt # static key
tun-mtu 1500
tun-mtu-extra 32

Jetzt muss ich noch einen Routingeintrag setzen, damit das 192.168.5.xxx Netz von mir zuhause aus gefunden werden kann.

Da ich einen Windows Rechner habe hier: route add 192.168.5.0 mask 255.255.255.0 192.168.6.1

Die 192.168.6.1 ist die virtuelle Adresse des Servers mit statische IP!

Das wars....


Zum Server:
(Linux Gentoo Box)

dev tap
ifconfig 192.168.6.1 255.255.255.0 #Virtuelle IP für den VPN Tunnel
port 5000
secret static.key
verb 3
tun-mtu 1500
tun-mtu-extra 32
route-gateway 192.168.6.1
route 192.168.6.0 255.255.255.0 # Damit die Pakete auch wieder ins 6.er Subnet kommen hier der Routingeintrag..

Das wars im Prinzip schon....
Allerdings muss man natürlich auch beachten, dass die Rechner im Firmennetz
das 6.er Subnet kennen (Das war mein Fehler). Also auch hier einen Routingeintrag setzen..
route add 192.168.6.0 mask 255.255.255.0 192.168.5.220 # Die 5.220 ist die reale Netzwerkadresse des Servers zum LAN...

Jetzt klappt auch die Suche in der Netzwerkumgebung, allerdings nur nach IP adressen. Will man nach Namen auflösen, braucht man noch einen WINs Server...

Viel Spass Gordon

mbo
04.08.04, 13:08
Jetzt klappt auch die Suche in der Netzwerkumgebung, allerdings nur nach IP adressen. Will man nach Namen auflösen, braucht man noch einen WINs Server...


Oder einen DNS. Wir haben bei uns dafür die tld vpn verwendet. Allerdings funktioniert das erst ab W2K wirklich. Aber ein Sambaserver mit WINS-Support ist ja schnell aufgesetzt.

cu/2 iae