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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
strongswan (5.1.0-1) UNRELEASED; urgency=low
Starting with strongSwan 5, the IKEv1 daemon (pluto) is gone, and the charon
daemon is now able to handle both IKEv1 and IKEv2 protocols.
There should be no issue for previous charon users, but for pluto users that
means they need to re-configure strongSwan in order to use charon. Some
migration help can be found on the strongSwan website at
http://wiki.strongswan.org/projects/strongswan/wiki/CharonPlutoIKEv1 and in
some IKEv1 configuration examples at
http://wiki.strongswan.org/projects/strongswan/wiki/IKEv1Examples.
-- Yves-Alexis Perez <corsac@debian.org> Mon, 30 Sep 2013 20:43:03 +0200
strongswan (4.5.0-1) unstable; urgency=low
Starting with strongswan 4.5.0 upstream, the IKEv2 protocol is now the
default. This can easily be changed using the keyexchange=ikev1 config
option (either in the respective "conn" section or by putting it in the
"default" section and therefore applying it to all existing connections).
The IKEv2 protocol has less overhead, more features (e.g. NAT-Traversal by
default, MOBIKE, Mobile IPv6), and provides better error messages in case
the connection can not be established. It is therefore highly recommended
to use it when the other side also supports it.
Addtionally, strongswan 4.5.0-1 now enables support for NAT Traversal in
combination with IPsec transport mode (the support for this has existed
for a long time, but was disabled due to security concerns). This is
required e.g. to let mobile phone clients (notably Android, iPhone)
connect to an L2TP/IPsec gateway using strongswan. The security
implications as described in the original README.NAT-Traversal file from
the openswan distribution are:
* Transport Mode can't be used without NAT in the IPSec layer. Otherwise,
all packets for the NAT device (including all hosts behind it) would be
sent to the NAT-T Client. This would create a sort of blackhole between
the peer which is not behind NAT and the NAT device.
* In Tunnel Mode with roadwarriors, we CAN'T accept any IP address,
otherwise, an evil roadwarrior could redirect all trafic for one host
(including a host on the private network) to himself. That's why, you have
to specify the private IP in the configuration file, use virtual IP
management, or DHCP-over-IPSec.
-- Rene Mayrhofer <rmayr@debian.org> Sun, 28 Nov 2010 13:16:00 +0200
Local variables:
mode: debian-changelog
End:
strongswan (5.1.0-1) unstable; urgency=low
Starting with strongswan 4.5.0 upstream, the IKEv2 protocol is now the
default. This can easily be changed using the keyexchange=ikev1 config
option (either in the respective "conn" section or by putting it in the
"default" section and therefore applying it to all existing connections).
The IKEv2 protocol has less overhead, more features (e.g. NAT-Traversal by
default, MOBIKE, Mobile IPv6), and provides better error messages in case
the connection can not be established. It is therefore highly recommended
to use it when the other side also supports it.
Addtionally, strongswan 4.5.0-1 now enables support for NAT Traversal in
combination with IPsec transport mode (the support for this has existed
for a long time, but was disabled due to security concerns). This is
required e.g. to let mobile phone clients (notably Android, iPhone)
connect to an L2TP/IPsec gateway using strongswan. The security
implications as described in the original README.NAT-Traversal file from
the openswan distribution are:
* Transport Mode can't be used without NAT in the IPSec layer. Otherwise,
all packets for the NAT device (including all hosts behind it) would be
sent to the NAT-T Client. This would create a sort of blackhole between
the peer which is not behind NAT and the NAT device.
* In Tunnel Mode with roadwarriors, we CAN'T accept any IP address,
otherwise, an evil roadwarrior could redirect all trafic for one host
(including a host on the private network) to himself. That's why, you have
to specify the private IP in the configuration file, use virtual IP
management, or DHCP-over-IPSec.
-- Yves-Alexis Perez <corsac@debian.org> Mon, 30 Sep 2013 20:43:03 +0200
|
