|
|
Besucher 727663
Ansichten 407
Online 0 |
|
|
IPSEC w/dyndns (server+client): Netgear FVS114 client+racoon
| |
| Thema |
Verfasser |
Letzte Antwort |
| IPSEC w/dyndns (server+client): Netgear FVS114 client+racoon |
cyberlussi ( ---.dip.t-dialin.net) |
20 Oct 2008 20:59 | Hallo,
ich habe mir Hilfe dieser Seite endlich einen IPSEC Tunnel in folgendem Szenario geschaft. Doch irgendwie werden keine Daten transferiert (ping klappt nicht). Erstmal die Umgebung, danach meine Debuggingversuche und mein Problem.
VPN Server:
-------
- Ubuntu mit 2.6.24-19-server kernel
- DSL Modem an einem eth, da der Linuxserver Router und Firewall ist (nicht ideal, ich weiss)
- Dyndns
- Ports udp 500, 4500 offen
- 192.168.48.0/255.255.255.0
- ipsec-tools 0.6.7-1.1ubuntu1.1
- ipsec-tools.conf ist leer, wegen "generate_policy on" in racoon.conf
#
# racoon.conf --- BEGIN
#
path pre_shared_key "/etc/racoon/psk.txt";
remote anonymous
{
exchange_mode aggressive, main;
generate_policy on;
passive on;
lifetime time 28800 seconds;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
sainfo anonymous
{
pfs_group 2;
lifetime time 86400 seconds;
encryption_algorithm 3des, blowfish 448, twofish, rijndael;
authentication_algorithm hmac_sha1, hmac_md5;
compression_algorithm deflate;
}
#
# racoon.conf --- END
#
Client:
-------
- Situation: Netgear FVS114 (als VPN Gateway Switch) hinter einem Speedport W500V (als DSL Router mit Dyndns)
- DSL Router:
# DHCP 192.168.2.x
# Portweiterleitung UDP 500, 4500 zu der VPN GW IP (192.168.2.100)
- VPN GW:
# erhält die 192.168.2.100 per DHCP vom DSL Router
# DHCP 192.168.0.x (= neues VPN LAN)
# IKE entsprechend Serverkonfiguration (Initiator, aggressive mode, local idendity = FQUN, remote identidy = remote WAN IP)
# VPN policies: remote VPN Endpoint = FQDN (dyndns vom Server), local = 192.168.0.0/255.255.255.0, remote = 192.168.48.0/255.255.255.0
So nun ein Tunnel aufbauen:
-------
- VPN Log vom FVS114:
[2008-10-05 00:05:50][==== IKE PHASE 1(to 87.155.199.183) START (initiator) ====]
[2008-10-05 00:05:50]**** SENT OUT FIRST MESSAGE OF AGGR MODE ****
[2008-10-05 00:05:50]<POLICY: thelight> PAYLOADS: SA,PROP,TRANS,KE,NONCE,ID
[2008-10-05 00:05:50]**** RECEIVED SECOND MESSAGE OF AGGR MODE ****
[2008-10-05 00:05:50]<POLICY: thelight> PAYLOADS: SA,PROP,TRANS,KE,NONCE,ID,HASH
[2008-10-05 00:05:50]**** AGGRESSIVE MODE COMPLETED ****
[2008-10-05 00:05:50][==== IKE PHASE 1 ESTABLISHED====]
[2008-10-05 00:05:50][==== IKE PHASE 2(to 87.155.199.183) START (initiator) ====]
[2008-10-05 00:05:50]**** SENT OUT FIRST MESSAGE OF QUICK MODE ****
[2008-10-05 00:05:50]<Initiator IPADDR=192.168.0.0,PORT=0>
[2008-10-05 00:05:50]<Responder IPADDR=192.168.48.0,PORT=0>
[2008-10-05 00:05:50]**** RECEIVED SECOND MESSAGE OF QUICK MODE ****
[2008-10-05 00:05:50]<POLICY: thelight> PAYLOADS: HASH,SA,PROP,TRANS,NONCE,KE,ID,ID
[2008-10-05 00:05:50]**** SENT OUT THIRD MESSAGE OF QUICK MODE ****
[2008-10-05 00:05:50]**** QUICK MODE COMPLETED ****
[2008-10-05 00:05:50][==== IKE PHASE 2 ESTABLISHED====]
Server daemon.log:
-------
Oct 4 23:59:03 door racoon: INFO: @(#)ipsec-tools 0.6.7 (http://ipsec-tools.sourceforge.net)
Oct 4 23:59:03 door racoon: INFO: @(#)This product linked OpenSSL 0.9.8g 19 Oct 2007 (http://www.openssl.org/)
Oct 4 23:59:04 door racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=7)
Oct 4 23:59:04 door racoon: INFO: 127.0.0.1[500] used for NAT-T
Oct 4 23:59:04 door racoon: INFO: 192.168.48.4[500] used as isakmp port (fd=8)
Oct 4 23:59:04 door racoon: INFO: 192.168.48.4[500] used for NAT-T
Oct 4 23:59:04 door racoon: INFO: 87.155.199.183[500] used as isakmp port (fd=10)
Oct 4 23:59:04 door racoon: INFO: 87.155.199.183[500] used for NAT-T
..
Oct 5 00:05:52 door racoon: INFO: respond new phase 1 negotiation: 87.155.199.183[500]<=>84.172.115.154[56412]
Oct 5 00:05:52 door racoon: INFO: begin Aggressive mode.
Oct 5 00:05:54 door racoon: INFO: ISAKMP-SA established 87.155.199.183[500]-84.172.115.154[56412] spi:87c34eb3afc0bbba:77ff36d9ad7354eb
Oct 5 00:05:55 door racoon: INFO: respond new phase 2 negotiation: 87.155.199.183[500]<=>84.172.115.154[56412]
Oct 5 00:05:55 door racoon: INFO: no policy found, try to generate the policy : 192.168.0.0/24[0] 192.168.48.0/24[0] proto=any dir=in
Oct 5 00:05:55 door racoon: INFO: IPsec-SA established: ESP/Tunnel 84.172.115.154[0]->87.155.199.183[0] spi=185265004(0xb0aeb6c)
Oct 5 00:05:55 door racoon: INFO: IPsec-SA established: ESP/Tunnel 87.155.199.183[0]->84.172.115.154[0] spi=2373610801(0x8d7a6d31)
Oct 5 00:05:55 door racoon: ERROR: such policy does not already exist: "192.168.0.0/24[0] 192.168.48.0/24[0] proto=any dir=in"
Oct 5 00:05:55 door racoon: ERROR: such policy does not already exist: "192.168.0.0/24[0] 192.168.48.0/24[0] proto=any dir=fwd"
Oct 5 00:05:55 door racoon: ERROR: such policy does not already exist: "192.168.48.0/24[0] 192.168.0.0/24[0] proto=any dir=out"
->> Sieht ja gut aus ... oder?
PROBLEM:
--------
Ein Ping aus dem VPN Netz findet nichts - ping geht raus, aber keine UDP Pakete kommen beim Server an:
- Client: tcpdump -ni en0 icmp:
00:07:35.179731 IP 192.168.0.2 > 192.168.48.1: ICMP echo request, id 42772, seq 0, length 64
00:07:36.179795 IP 192.168.0.2 > 192.168.48.1: ICMP echo request, id 42772, seq 1, length 64
- Server: tcpdump -ni ppp0 udp -> keine Pakete!
Debugging-Versuch:
----------
- Clientseitiges traceroute findet keinen weg zum 48er Netz
- Leider kann ich nicht gleichzeitig an verschiedenen Netzpunkten tcpdump laufen lassen....
- der VPN Log des FVS114 bestätigt allerdings irgendwie Datenausgang:
# IPSec SA 1 = 185265004, Endpoint = 87.155.199.183, Protocol = ESP, Tx (KBytes) = 13
# IPSec SA 1 = 2373610801, Endpoint = 192.168.2.100, Protocol = ESP, Tx (KBytes) = 0
Fragen:
-------
1) Muss was anders konfiguriert werden?
2) Muss ich irgendwo noch das routing anpassen?
3) Wo kann ich wie am besten debuggen?
... kann man mir noch helfen?
ps. IPs geändert ... |
| ||
| RE: IPSEC w/dyndns (server+client): Netgear FVS114 client+ra... | Ralf ( ---.dip.t-dialin.net) | 14 Oct 2008 06:34 |
Da Du Dich in einer genatteten Situation befindest, würde ich empfehlen, NAT-T zu aktivieren. Ansonsten musst Du mindestens auf dem Speedport noch ESP (Protokoll 50) nach innen weiterleiten. Ob das der Speedport kann, weiss ich nicht.
Ansonsten musst Du auf dem Server mit tcpdump folgendermaßen suchen:
tcpdump -ni ppp0 proto 50
um die ESP-Pakete anzuzeigen. ESP ist kein UDP!
Gruß,
Ralf
| | RE: RE: IPSEC w/dyndns (server+client): Netgear FVS114 clien... | cyberlussi ( ---.dip.t-dialin.net) | 15 Oct 2008 21:19 |
Danke für den Port Tipp ... geht aber noch nicht komplett, aber so halb:
Mache ich ein Ping von einem Rechner aus dem 192.168.0.x Netz so sehe ich als direkte Antwort ESP Pakete auf dem Server:
Client: ping 192.168.48.1
Server: tcpdump -ni ppp0 proto 50
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
23:10:20.990709 IP 84.173.121.71 > 87.165.112.25: ESP(spi=0x051884a5,seq=0x83), length 116
23:10:21.990377 IP 84.173.121.71 > 87.165.112.25: ESP(spi=0x051884a5,seq=0x84), length 116
23:10:22.991740 IP 84.173.121.71 > 87.165.112.25: ESP(spi=0x051884a5,seq=0x85), length 116
23:10:23.990967 IP 84.173.121.71 > 87.165.112.25: ESP(spi=0x051884a5,seq=0x86), length 116
23:10:24.989990 IP 84.173.121.71 > 87.165.112.25: ESP(spi=0x051884a5,seq=0x87), length 116
23:10:25.991839 IP 84.173.121.71 > 87.165.112.25: ESP(spi=0x051884a5,seq=0x88), length 116
23:10:26.991044 IP 84.173.121.71 > 87.165.112.25: ESP(spi=0x051884a5,seq=0x89), length 116
Scheint erstmal zu klappen - ping sagt aber 100% Paketverlust. Umgekert probiere ich vom Server zum Clientnetz ein traceroute habe ich folgendes:
traceroute to 192.168.0.2 (192.168.0.2), 30 hops max, 40 byte packets
1 * * *
2 217.0.78.106 (217.0.78.106) 42.477 ms !H * *
Vom einer Client IP versandet tracerout vollkommen. Vorherige IP gehört, glaube ich zu den Servern der Telekom (whois sagt DTAG-DIAL13). Was geht da falsch? Irgendwas fehlt noch ... oder? | | RE: RE: RE: IPSEC w/dyndns (server+client): Netgear FVS114 c... | Ralf ( ---.dip.t-dialin.net) | 17 Oct 2008 05:52 |
Hallo,
na immerhin kommen auf dem Server die ESP-Pakete an. Schon gut. Allerdings werden sie nicht richtig ausgewertet oder durch eine Firewall nicht akzeptiert? Hast Du iptables auf dem Server aktiv? Lässt der ESP (Proto 50) durch?
Ansonsten hilft möglicherweise auf NAT-T umzustellen.
Das ein Traceroute nicht klappt, kann auch mit Firewalleinstellungen zusammenhängen. Hierfür muss UDP und ICMP entsprechend erlaubt werden.
Gruß,
Ralf
| | RE: RE: RE: RE: IPSEC w/dyndns (server+client): Netgear FVS1... | cyberlussi ( ---.dip.t-dialin.net) | 20 Oct 2008 20:59 |
Ich konnte einen Teilerfolg verbuchen. Ich habe in der setkey.conf alles auskommentiert und somit auch leider folgendes. Wenn ich das wieder aktiviere, erreiche ich zumindest auf das entfernte VPN-Gateway:
ipsec-tools.conf
-----------
flush;
spdflush;
Dann klappt ein ping 192.168.48.4 vom client aus:
(Server) tcpdump -ni ppp0 proto 50
21:42:21.807176 IP 84.173.89.124 > 87.125.216.12: ESP(spi=0x064af949,seq=0xca), length 116
21:42:21.807514 IP 87.125.216.12 > 84.173.89.124: ESP(spi=0xdf55ff77,seq=0x17), length 116
Auch sonst erreiche ich die Dienste des VPN Gatewayrechners. Allerdings keine anderen IPs in dem entferntem Netzwerk. Es folgend ein paar Systeminfos:
route
-----------
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.0.116.243 * 255.255.255.255 UH 0 0 0 ppp0
localnet * 255.255.255.0 U 0 0 0 eth1
default * 0.0.0.0 U 0 0 0 ppp0
Es läuft auch eine Firewall auf dem VPN-Server, die sieht so aus ... ich habe aber das ganze 192.168.0.0/16 "freigeschaltet", ich erwarte daher keine unerwarteten Filtereffekte - oder muss ich noch was besonderes beachten? Das Netz 192.168.0.0/16 und ppp0 stehen per MASQUERADE in Kontakt. IP-forward ist auch aktiv.
iptables -L
-----------
Chain INPUT (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp echo-request
DROP icmp -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:isakmp
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:www
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT udp -- anywhere anywhere udp dpt penvpn << TESTWEISE 
ACCEPT udp -- 192.168.0.0/16 anywhere udp dpt:domain
ACCEPT tcp -- 192.168.0.0/16 anywhere tcp dpt:domain
ACCEPT udp -- 192.168.0.0/16 anywhere udp dpt:domain
ACCEPT tcp -- 192.168.0.0/16 anywhere tcp dpt:domain
ACCEPT tcp -- 192.168.0.0/16 anywhere tcp dpt:smtp
ACCEPT tcp -- 192.168.0.0/16 anywhere tcp dpt:smtp
Chain FORWARD (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Ich habe irgendwie im Verdacht, dass das Routing nicht so hinhaut.
setkey -D
-----------
87.125.216.12 84.173.89.124
esp mode=tunnel spi=3554455503(0xd3dcafcf) reqid=0(0x00000000)
E: 3des-cbc 092dd1e6 d93b4316 451bdf40 2b378290 c2e04da6 83a9c0b2
A: hmac-sha1 b79ed60b 6d245b4b b4b6f763 22a11b24 45ad6589
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Oct 20 22:38:33 2008 current: Oct 20 22:38:42 2008
diff: 9(s) hard: 86400(s) soft: 69120(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=24758 refcnt=0
84.173.89.124 87.125.216.12
esp mode=tunnel spi=213140907(0x0cb445ab) reqid=0(0x00000000)
E: 3des-cbc 72346b26 df47eca0 489984d0 6fcbf820 1024c7b4 f274423b
A: hmac-sha1 c98413bc 80d63c70 61e92554 dab08543 f59e7ce2
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Oct 20 22:38:33 2008 current: Oct 20 22:38:42 2008
diff: 9(s) hard: 86400(s) soft: 69120(s)
last: Oct 20 22:38:35 2008 hard: 0(s) soft: 0(s)
current: 384(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 7 hard: 0 soft: 0
sadb_seq=0 pid=24758 refcnt=0
setkey -DP
-----------
192.168.0.0/24[any] 192.168.0.0/16[any] any
in ipsec
esp/tunnel/84.173.89.124-87.125.216.12/require
created: Oct 20 22:38:33 2008 lastused: Oct 20 22:38:48 2008
lifetime: 86400(s) validtime: 0(s)
spid=3016 seq=1 pid=24766
refcnt=2
192.168.0.0/16[any] 192.168.0.0/24[any] any
out ipsec
esp/tunnel/87.125.216.12-84.173.89.124/require
created: Oct 20 22:38:33 2008 lastused: Oct 20 22:38:48 2008
lifetime: 86400(s) validtime: 0(s)
spid=3033 seq=2 pid=24766
refcnt=2
192.168.0.0/24[any] 192.168.0.0/16[any] any
fwd ipsec
esp/tunnel/84.173.89.124-87.125.216.12/require
created: Oct 20 22:38:33 2008 lastused: Oct 20 22:39:42 2008
lifetime: 86400(s) validtime: 0(s)
spid=3026 seq=3 pid=24766
refcnt=3
(per-socket policy)
in none
created: Oct 20 22:38:18 2008 lastused:
lifetime: 0(s) validtime: 0(s)
spid=3003 seq=4 pid=24766
refcnt=1
Mit NAT-T möchte ich eigentlich nicht arbeiten, da das der Netgear-Router nicht so kann - zumindest habe ich keinen Menupunkt dazu gesehen - oder verstehe ich da was falsch?
Naja, ist auf jeden Fall so, dass ich das Gateway nun erreiche, aber die anderen IPs in dem Subnetz nicht. Wo muss ich denn da ansetzen? Ich sehe ja ESP Pakete auf dem VPN Server eingehen, wenn ich eine Anfrage vom Client aus an andere IPs starte. Jedoch kommt nichts zurück. Was fehlt? Wegen letzterem doch eher nichts im Umfeld IPSEC, sondern vielleicht doch iptables oder routing. Oder?
|
[ Zurück ] Um ein neues Thema hinzu zu fügen müssen sie eingeloggt sein.
|
|
|
|
Welche Distribution verwenden Sie?
| |
|
|
|
17 Oct 2008: