Ik ben bezig met het opzetten van een IPsec VPN tussen 2 linux hosts, beide met kernel 2.6.5, gebruik makende van de native 2.6.x IPSec implementatie en racoon voor de keyuitwisseling.
De configuratie is als volgt:
waarbij 80.126.200.96 het externe ip aan de ene kant is, en 130.89.144.226 het ip van de andere kant van de tunnel.
nu wil ik een VPN opzetten tussen de subnets 172.16.1.0/24, en 172.16.2.0/24. Hiervoor heeft de host 10.0.0.2 een interface met als IP 172.16.1.1, en host 130.89.144.226 heeft een interface met adres 172.16.2.1, beide met een netmask van 255.255.255.0.
Als ik de boel volgens de configuratie onderaan deze post configureer kan ik racoon starten. Als ik dan vanaf host 10.0.0.2/172.16.1.1 ping naar 172.16.2.1 wordt de tunnel opgezet. Racoon meldt dat de tunnel er is:
Maar ping meldt geen ping replies. Als ik de ping packets met ethereal analyseer op 10.0.0.2, zie ik per ping request/reply 3 packets:
Zoals te zien lijkt de tunnel te werken, alleen komt het reply packet niet meer aan bij ping. Weet iemand wat hiervan de oorzaak kan zijn?
--------- configuratie -----------
De setkey security policies:
op host 10.0.0.2:
op host 130.89.144.226:
Vervolgens de racoon configuratie, op beide hosts hetzelfde:
De routing table op 10.0.0.2:
De routing table op 130.89.144.226
(172.16.2.1 zit op eth0:0, vandaar dat alles op dezelfde interface zit)
De iptables policies staan allemaal open op beide systemen, uiteraard is ipv4 forwarding in de kernel enabled:
De configuratie is als volgt:
code:
1
| 10.0.0.2 <-> [10.0.0.138 - 80.126.200.96 NAT] <->130.89.144.226 |
waarbij 80.126.200.96 het externe ip aan de ene kant is, en 130.89.144.226 het ip van de andere kant van de tunnel.
nu wil ik een VPN opzetten tussen de subnets 172.16.1.0/24, en 172.16.2.0/24. Hiervoor heeft de host 10.0.0.2 een interface met als IP 172.16.1.1, en host 130.89.144.226 heeft een interface met adres 172.16.2.1, beide met een netmask van 255.255.255.0.
Als ik de boel volgens de configuratie onderaan deze post configureer kan ik racoon starten. Als ik dan vanaf host 10.0.0.2/172.16.1.1 ping naar 172.16.2.1 wordt de tunnel opgezet. Racoon meldt dat de tunnel er is:
code:
1
2
3
4
| 2004-05-01 13:48:04: INFO: pfkey.c:1185:pk_recvupdate(): IPsec-SA established: ESP/Tunnel 130.89.144.226->10.0.0.2 spi=207284167(0xc5ae7c7) 2004-05-01 13:48:04: INFO: pfkey.c:1425:pk_recvadd(): IPsec-SA established: ESP/Tunnel 10.0.0.2->130.89.144.226 spi=168420393(0xa09e429) |
Maar ping meldt geen ping replies. Als ik de ping packets met ethereal analyseer op 10.0.0.2, zie ik per ping request/reply 3 packets:
code:
1
2
3
| 10.0.0.2 -> 130.89.144.226 ESP [het request in IPsec verpakt] 130.89.144.226 -> 10.0.0.2 ESP [ping reply in IPsec] 172.16.2.1 -> 172.16.1.1 ICMP [het decrypted ICMP reply packet] |
Zoals te zien lijkt de tunnel te werken, alleen komt het reply packet niet meer aan bij ping. Weet iemand wat hiervan de oorzaak kan zijn?
--------- configuratie -----------
De setkey security policies:
op host 10.0.0.2:
code:
1
2
| spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec esp/tunnel/10.0.0.2-130.89.144.226/require; spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec esp/tunnel/130.89.144.226-10.0.0.2/require; |
op host 130.89.144.226:
code:
1
2
| spdadd 172.16.1.0/24 172.16.2.0/24 any -P in ipsec esp/tunnel/80.126.200.96-130.89.144.226/require; spdadd 172.16.2.0/24 172.16.1.0/24 any -P out ipsec esp/tunnel/130.89.144.226-80.126.200.96/require; |
Vervolgens de racoon configuratie, op beide hosts hetzelfde:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
| path certificate "/etc/racoon/certs";
path pre_shared_key "/etc/racoon/psk.txt";
listen {
# gewone poort
isakmp 0.0.0.0[500];
# NAT-T poort
isakmp_natt 0.0.0.0[4500];
}
timer {
natt_keepalive 20 sec;
}
remote anonymous {
exchange_mode main,base,aggressive;
nat_traversal force;
proposal {
# tijdelijk pre-shared-key totdat het werkt
# de pre-shared-keys zijn voor alle betrokken ip's gelijk
authentication_method pre_shared_key;
hash_algorithm sha1;
encryption_algorithm 3des;
dh_group modp1024;
}
proposal_check obey;
}
# Phase 2 proposal (for IPsec SA)
sainfo anonymous {
pfs_group modp768;
lifetime time 12 hour;
encryption_algorithm 3des, rijndael;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
} |
De routing table op 10.0.0.2:
code:
1
2
3
4
5
6
| Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.2.0 172.16.1.1 255.255.255.0 UG 0 0 0 eth1 172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 10.0.0.138 0.0.0.0 UG 0 0 0 eth0 |
De routing table op 130.89.144.226
code:
1
2
3
4
5
6
| Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.2.0 * 255.255.255.0 U 0 0 0 eth0 172.16.1.0 172.16.2.1 255.255.255.0 UG 0 0 0 eth0 130.89.144.0 * 255.255.254.0 U 0 0 0 eth0 default 130.89.144.225 0.0.0.0 UG 0 0 0 eth0 |
(172.16.2.1 zit op eth0:0, vandaar dat alles op dezelfde interface zit)
De iptables policies staan allemaal open op beide systemen, uiteraard is ipv4 forwarding in de kernel enabled:
code:
1
2
3
4
5
6
7
8
| 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 |
[ Voor 21% gewijzigd door Verwijderd op 01-05-2004 15:10 ]
:strip_icc():strip_exif()/u/40949/polarwolf.jpg?f=community)
:strip_icc():strip_exif()/u/37670/crop6511c4e77432d_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/4167/bacall8.jpg?f=community)
