[strongSwan] Can strongswan tnc be used with TPM 2.0 ?
Hi all, I am interested to use the strongswan tnc, specifically the PTS (IMV/IMC) mode. I went to this following pages : https://wiki.strongswan.org/projects/strongswan/wiki/IMA https://wiki.strongswan.org/projects/strongswan/wiki/TrustedNetworkConnect https://wiki.strongswan.org/projects/strongswan/wiki/PTS-IMV https://wiki.strongswan.org/projects/strongswan/wiki/PTS-IMC Pages are talking about TPM 1.2, but TPM 2.0 is never described. I am mainly looking for a way to verify if a client is trusted or not. And what is described at https://wiki.strongswan.org/projects/strongswan/wiki/IMA can match my requirements. But I would like to have something compliant TPM 1.2 and TPM 2.0 Is strongswan TNC/PTS feature compliant with TPM 1.2 and TPM 2.0 ? Thanks
Re: [strongSwan] IPAD via NATed firewall doesn't work
Hello, You'll find more information on this INVALID_HASH_INFORMATION in the links I provided earlier on this thread, see at this link: https://lists.strongswan.org/pipermail/users/2011-February/005863.html Basically, it seems the error is caused by a bug in raccoon OS X/iOS implementation. I was able to get passed it by hacking strongSwan's code but ran into another issue. I didn't get further time to investigate this or report the raccoon issue to Apple... Benoit. Le 12 avr. 2011 à 15:41, Florian Wolters a écrit : Hello Martin, I am currently working on the same problem. The problem seems to ly with strongSwan and the IPad computing hash values on different information. The log of my strongSwan tells me: --- 8 snip --- | received encrypted packet from 80.187.98.129:59786 | decrypting 48 bytes using algorithm AES_CBC | decrypted: | 0b 00 00 18 b7 1d 29 01 54 a8 d4 3e 34 83 34 7b | 6e 56 9a d4 ea 41 c4 d8 00 00 00 0c 00 00 00 01 | 01 00 00 17 00 00 00 00 00 00 00 00 00 00 00 0c | next IV: 73 7b 61 b4 66 c6 c1 60 dc 0c b0 a0 d4 d2 a9 73 | ***parse ISAKMP Hash Payload: |next payload type: ISAKMP_NEXT_N |length: 24 | ***parse ISAKMP Notification Payload: |next payload type: ISAKMP_NEXT_NONE |length: 12 |DOI: ISAKMP_DOI_IPSEC |protocol ID: 1 |SPI size: 0 |Notify Message Type: INVALID_HASH_INFORMATION | removing 12 bytes of padding iPad_psk[1] 80.187.98.129:59786 #1: ignoring informational payload, type INVALID_HASH_INFORMATION --- 8 snap --- In my configuration both the iPad and the strongSwan Server are NATed. The iPad is one of the first edition but with the latest iOS. So NAT does not seems to cause the problem but instead the calculation of hashes. AFAIK there is no configuration option to change this behavior on strongSwan side. Best regards Florian Von meinem iPad gesendet Am 04.04.2011 um 20:23 schrieb Martin Kellermann kellerm...@sk-datentechnik.com: hello andreas, yes, you are right, but this still doesn't solve the problem. i am still stuck... reading some current posts on APPLEs discussion forum (for ex: http://discussions.apple.com/thread.jspa?threadID=2778039) maybe this is a general problem with iOS 4.3 ? so i'm very interested if anyone has managed to get the iPad 2 (iOS 4.3.1) connect to strongswan with one or both sides being NATed? or maybe someone has managed to connect to open-/freeSWAN ? (server is on debian 6) any help is really appreciated! thank you Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongswan/L2TP and NAT-T transport with both NATed
Hi Victor,
I found a workaround for this INVALID_HASH_INFORMATION error by hacking
strongSwan's code but I doubt it's really correct (and I'm running into another
issue after :(). The problem is that raccoon and strongSwan don't compute the
HASH on the same data (raccoon doesn't includes NAT-OA in the hash computation
whereas strongSwan does).
See:
https://lists.strongswan.org/pipermail/users/2010-December/005712.html
It would be good to figure out whether or not this is a strongSwan or raccoon
issue. If it's the later I'll submit a bug where appropriate.
Cheers,
Benoit
On Dec 14, 2010, at 9:24 AM, Ulysse 31 wrote:
2010/11/24 Ulysse 31 ulyss...@gmail.com:
2010/11/22 Ulysse 31 ulyss...@gmail.com:
Hi all,
I have a strongswan with L2TP working with XP roadwarrior clients/ osx
clients and iphone on one gateway with a public IP.Had to enable
--enable-nat-transport but it works great.
Now I have a second configuration, which is like :
client
|
NAT Gateway
|
Internet
|
NAT Gateway (cisco ASA 5505)
|
Strongswan Server
|
LAN
It is the almost the same configuration, the main big difference comes
from the strongswan server that is NATed. The cisco ASA as no VPN
feature enable, it is used like a simple NAT gateway, redirecting one
public IP to the internal IP using a static NAT. all IP (TCP/UDP), esp
and AH protocol is allowed. here is the first example of configuration
used :
config setup
plutodebug=control
strictcrlpolicy=no
overridemtu=1410
nat_traversal=yes
charonstart=no
plutostart=yes
conn L2TP
authby=psk
pfs=no
auto=add
rekey=no
type=tunnel
left=yy.yy.yy.yy # Internal private IP
leftnexthop=XX.XX.XX.XX # External IP address
leftprotoport=17/1701
leftfirewall=yes
right=%any
rightprotoport=17/%any
rightsubnetwithin=0.0.0.0/0
rightfirewall=yes
esp=aes128-sha1
ike=aes128-sha-modp1024
forceencaps=yes
Here is what I got in the logs (the aa.aa.aa.aa is the IP public
address of the client, and bb.bb.bb.bb is its private address) :
---
Nov 20 11:51:35 src@stronswanserv pluto[26142]: L2TP[2]
aa.aa.aa.aa:4500 #4: cannot respond to IPsec SA request because no
connection is known for
XX.XX.XX.XX/32===yy.yy.yy.yy:4500:17/1701…aa.aa.aa.aa:4500[bb.bb.bb.bb]:17/%any==={bb.bb.bb.bb/32}
Nov 20 11:51:38 src@stronswanserv pluto[26142]: L2TP[2]
aa.aa.aa.aa:4500 #4: Quick Mode I1 message is unacceptable because it
uses a previously used Message ID 0xfb7bef8d (perhaps this is a
duplicated packet)
Nov 20 11:51:38 src@stronswanserv pluto[26142]: L2TP[2]
aa.aa.aa.aa:4500 #4: sending encrypted notification INVALID_MESSAGE_ID
to aa.aa.aa.aa:4500
Nov 20 11:51:38 src@stronswanserv pluto[26142]: | next event
EVENT_NAT_T_KEEPALIVE in 13 seconds
The Quick Mode I1 message is unacceptable is repeated several times
( retries from client ) and the ISAKMP is never established, then it
times out.
---
So next I tried with adding leftsubnet=XX.XX.XX.XX/32 on the conn
L2TP config. which allowed me to establish ISAKMP, but then I have on
the logs :
---
Nov 20 11:52:58 src@stronswanserv pluto[26339]: |
preparse_isakmp_policy: peer requests PSK authentication
...
Nov 20 11:52:58 src@stronswanserv pluto[26339]: L2TP[1]
aa.aa.aa.aa #4: responding to Main Mode from unknown peer aa.aa.aa.aa
Nov 20 11:52:59 src@stronswanserv pluto[26339]: L2TP[1]
aa.aa.aa.aa #4: NAT-Traversal: Result using RFC 3947: both are NATed
Nov 20 11:52:59 src@stronswanserv pluto[26339]: L2TP[1]
aa.aa.aa.aa #4: Peer ID is ID_IPV4_ADDR: 'bb.bb.bb.bb'
Nov 20 11:52:59 src@stronswanserv pluto[26339]: L2TP[2]
aa.aa.aa.aa #4: deleting connection L2TP instance with peer
aa.aa.aa.aa {isakmp=#0/ipsec=#0}
Nov 20 11:52:59 src@stronswanserv pluto[26339]: L2TP[2]
aa.aa.aa.aa:4500 #4: sent MR3, ISAKMP SA established
Nov 20 11:52:59 src@stronswanserv pluto[26339]: L2TP[2]
aa.aa.aa.aa:4500 #4: ignoring informational payload, type
IPSEC_INITIAL_CONTACT
Nov 20 11:53:00 src@stronswanserv pluto[26339]: L2TP[2]
aa.aa.aa.aa:4500 #5: NAT-Traversal: received 2 NAT-OA. using first,
ignoring others
Nov 20 11:53:00 src@stronswanserv pluto[26339]: L2TP[2]
aa.aa.aa.aa:4500 #5: responding to Quick Mode
Nov 20 11:53:00 src@stronswanserv pluto[26339]: |
kernel_alg_esp_auth_keylen(auth=2, sadb_aalg=3): a_keylen=20
Nov 20 11:53:00 src@stronswanserv pluto[26339]: |
install_inbound_ipsec_sa() checking if we can route
Nov 20 11:53:00 src@stronswanserv pluto[26339]: | route owner of
L2TP[2] aa.aa.aa.aa:4500 unrouted: NULL; eroute owner: NULL
Nov 20 11:53:00 src@stronswanserv pluto[26339]: | add inbound eroute
aa.aa.aa.aa/32:57947 - XX.XX.XX.XX/32:1701 =
tun.10...@yy.yy.yy.yy:17
Nov 20 11:53:00 src@stronswanserv pluto[26339]: | inserting event
EVENT_RETRANSMIT, timeout in 10 seconds for #5
Nov 20 11:53:00 src
[strongSwan] routing issue with IKEv1 tunnels after upgrade to 4.5.0
Hi, I still have an issue with my IKEv1 tunnels after upgrading from 4.4.1 to 4.5.0. Depending on the connection establishment order the packets from one tunnel are not correctly routed. Here's the setup of the 2 tunnels (striped down of the certs config): conn %default keyexchange=ikev1 left=%defaultroute leftsourceip=192.168.128.1 leftsubnet=192.168.0.0/16 right=%any conn t1 rightsubnet=192.168.5.0/24 auto=add conn defaultTunnel rightsubnet=192.168.0.0/16 auto=add The network of the strongSwan server is 192.168.128.0/24. I want to route 192.168.5.0/24 network traffic through t1, 192.168.128.0/24 traffic is local and all other traffic should go through defaultTunnel. If defaultTunnel is established first and t1 second, the strongSwan server receives the traffic from the tunnel t1 but doesn't send back packets through it. The traffic seems to always be routed to the tunnel defaultTunnel. If t1 is established first and defaultTunnel second, it works. Any ideas why this doesn't work anymore after upgrading? Is there a way to ensure this always work regardless of the connection establishment order? Thanks again for your help. Cheers, Benoit. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] IKEv1 connection issues after upgrading from 4.4.1 to 4.5.0
Hi,
After looking more carefully at the logs, there are also some suspicious traces
for pluto:
pluto[11637]: | creating acquire event for policy 10.12.15.22/32 ===
27.21.27.40/32 with reqid {16420}
pluto[11637]: |
pluto[11637]: | *handling asynchronous events
pluto[11637]: | initiate on demand from 10.12.15.22:0 to 27.21.27.40:0 proto=0
state: fos_start because: whack
pluto[11637]: | find_connection: looking for policy for connection:
10.12.15.22:0/0 - 27.21.27.40:0/0
pluto[11637]: | find_connection: concluding with empty
ip xfrm state gives me the following:
src 10.12.15.22 dst 27.21.27.40
proto esp spi 0xc7c5af3a reqid 16420 mode tunnel
replay-window 32
auth hmac(sha1) 0x47ff9f0112dac804a37a7f47f4371ac8b69219a8
enc cbc(aes) 0xf1bedbfe7aabc07cda4a40b8fb934484
sel src 0.0.0.0/0 dst 0.0.0.0/0
src 27.21.27.40 dst 10.12.15.22
proto esp spi 0xc500ee4a reqid 16420 mode tunnel
replay-window 32
auth hmac(sha1) 0x413ed35699112a5a00599ee721ce72017f400bbb
enc cbc(aes) 0x0b289980e478348eb8950bd4da54b8d3
sel src 0.0.0.0/0 dst 0.0.0.0/0
It sounds like charon fails to retrieve the policy or are those traces expected?
Thanks
Cheers,
Benoit.
On Dec 2, 2010, at 8:53 PM, Benoit Foucher wrote:
Hi,
I've upgraded from 4.4.1 to 4.5.0 today to workaround the issue where a given
peer ID can't acquire multiple virtual IP addresses. However, my IKEv1
connections don't work anymore now. I did add keyexchange=ikev1 to make sure
to use pluto. I've attached my config below.
The tunnel is established but it seems there are some problems with routing.
If I ping my strongSwan gateway from the peer network, the gateway correctly
receives the ICMP packets (according to tcpdump on the gateway). However, the
replies don't seem to be sent back over the tunnel (I don't see any ICMP
reply with tcpdump on the gateway and the ping from the peer doesn't get any
reply either).
The only suspicious thing are the errors below which come from charon despite
the fact that the tunnel is established with pluto. Could this be related to
the change where pluto is now using netlink for setting up policies? Here are
the messages:
charon: 05[KNL] received an SADB_ACQUIRE with policy id 140489 but no
matching policy found
charon: 05[KNL] creating acquire job for policy 10.12.15.22/32 ===
27.21.27.40/32 with reqid {0}
charon: 03[CFG] trap not found, unable to acquire reqid 0
My ipsec.conf for that connection:
---
config setup
plutodebug=control
crlcheckinterval=180
strictcrlpolicy=no
charonstart=yes
plutostart=yes
nat_traversal=yes
conn %default
ikelifetime=3h
lifetime=3h
rekeymargin=3m
keyingtries=1
left=%defaultroute
left...@gw.foo.com
leftsourceip=192.168.128.1
leftsubnet=192.168.128.0/17
leftcert=gw_cert.pem
leftfirewall=yes
rightfirewall=yes
conn sj-gw
keyexchange=ikev1
right=%any
leftsubnet=192.168.0.0/16
rightsubnet=192.168.0.0/16
right...@sj-gw.foo.com
auto=add
Any ideas what could be wrong? Is there some additional settings require for
4.5.0 now?
Thanks for the help!
Cheers,
Benoit.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] IKEv1 connection issues after upgrading from 4.4.1 to 4.5.0
Hi Andreas,
Thanks for your prompt reply. All my connections are defined with auto=add (a
mix of IKEv1 and IKEv2 connections).
Benoit.
On Dec 3, 2010, at 9:18 AM, Andreas Steffen wrote:
Hi Benoit,
it is strange that you get acquire events. Do you define any connections
in ipsec.conf with the setting auto=route? If yes, are these IKEv1
or IKEv2 connections?
Regards
Andreas
On 12/03/2010 09:11 AM, Benoit Foucher wrote:
Hi,
After looking more carefully at the logs, there are also some suspicious
traces for pluto:
pluto[11637]: | creating acquire event for policy 10.12.15.22/32 ===
27.21.27.40/32 with reqid {16420}
pluto[11637]: |
pluto[11637]: | *handling asynchronous events
pluto[11637]: | initiate on demand from 10.12.15.22:0 to 27.21.27.40:0
proto=0 state: fos_start because: whack
pluto[11637]: | find_connection: looking for policy for connection:
10.12.15.22:0/0 - 27.21.27.40:0/0
pluto[11637]: | find_connection: concluding with empty
ip xfrm state gives me the following:
src 10.12.15.22 dst 27.21.27.40
proto esp spi 0xc7c5af3a reqid 16420 mode tunnel
replay-window 32
auth hmac(sha1) 0x47ff9f0112dac804a37a7f47f4371ac8b69219a8
enc cbc(aes) 0xf1bedbfe7aabc07cda4a40b8fb934484
sel src 0.0.0.0/0 dst 0.0.0.0/0
src 27.21.27.40 dst 10.12.15.22
proto esp spi 0xc500ee4a reqid 16420 mode tunnel
replay-window 32
auth hmac(sha1) 0x413ed35699112a5a00599ee721ce72017f400bbb
enc cbc(aes) 0x0b289980e478348eb8950bd4da54b8d3
sel src 0.0.0.0/0 dst 0.0.0.0/0
It sounds like charon fails to retrieve the policy or are those traces
expected?
Thanks
Cheers,
Benoit.
On Dec 2, 2010, at 8:53 PM, Benoit Foucher wrote:
Hi,
I've upgraded from 4.4.1 to 4.5.0 today to workaround the issue where a
given peer ID can't acquire multiple virtual IP addresses. However, my
IKEv1 connections don't work anymore now. I did add keyexchange=ikev1 to
make sure to use pluto. I've attached my config below.
The tunnel is established but it seems there are some problems with
routing. If I ping my strongSwan gateway from the peer network, the gateway
correctly receives the ICMP packets (according to tcpdump on the gateway).
However, the replies don't seem to be sent back over the tunnel (I don't
see any ICMP reply with tcpdump on the gateway and the ping from the peer
doesn't get any reply either).
The only suspicious thing are the errors below which come from charon
despite the fact that the tunnel is established with pluto. Could this be
related to the change where pluto is now using netlink for setting up
policies? Here are the messages:
charon: 05[KNL] received an SADB_ACQUIRE with policy id 140489 but no
matching policy found
charon: 05[KNL] creating acquire job for policy 10.12.15.22/32 ===
27.21.27.40/32 with reqid {0}
charon: 03[CFG] trap not found, unable to acquire reqid 0
My ipsec.conf for that connection:
---
config setup
plutodebug=control
crlcheckinterval=180
strictcrlpolicy=no
charonstart=yes
plutostart=yes
nat_traversal=yes
conn %default
ikelifetime=3h
lifetime=3h
rekeymargin=3m
keyingtries=1
left=%defaultroute
left...@gw.foo.com
leftsourceip=192.168.128.1
leftsubnet=192.168.128.0/17
leftcert=gw_cert.pem
leftfirewall=yes
rightfirewall=yes
conn sj-gw
keyexchange=ikev1
right=%any
leftsubnet=192.168.0.0/16
rightsubnet=192.168.0.0/16
right...@sj-gw.foo.com
auto=add
Any ideas what could be wrong? Is there some additional settings require
for 4.5.0 now?
Thanks for the help!
Cheers,
Benoit.
==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] IKEv1 connection issues after upgrading from 4.4.1 to 4.5.0
That was it! Disabling the kernel-pfkey plugin solved the issue.
Thanks for your help.
Cheers,
Benoit.
On Dec 3, 2010, at 11:44 AM, Andreas Steffen wrote:
Hmmm,
I see that pluto loads the kernel-pfkey plugin which is totally untested with
IKEv1
Dec 3 09:16:43 gw pluto[16007]: loaded plugins:
curl aes des blowfish sha1 sha2 md5 random x509 pkcs1 pgp dnskey pem
gmp hmac xauth attr kernel-pfkey kernel-netlink resolve
Could you please remove the kernel-pfkey plugin and check whether the
problem disappears? And do the same on charon
Dec 3 09:16:43 gw charon: 00[DMN] loaded plugins:
curl aes des blowfish sha1 sha2 md4 md5 random x509 revocation pubkey
pkcs1 pgp pem fips-prf gmp xcbc hmac attr kernel-pfkey kernel-netlink
resolve socket-raw stroke smp updown eap-identity eap-sim
eap-sim-file eap-aka eap-md5 eap-gtc eap-mschapv2
since the PFKEYv2 kernel interface does not give you any advantage
over the default XFRM interface on a Linux box.
Regards
Andreas
On 12/03/2010 10:28 AM, Benoit Foucher wrote:
I've attached pluto and charon logs. One additional information: the acquire
event traces only show up when I try to ping a machine on the remote network
from the strongSwan gateway (the ping doesn't succeed). The remote network
is behind a Zywall USG 100 which only supports IKEv1. Thanks again for your
help.
Cheers,
Benoit.
On Dec 3, 2010, at 9:50 AM, Andreas Steffen wrote:
It is getting stranger all the time. Could you send me the complete
ipsec.conf and complete pluto log (with plutodebug=control) and charon
log where these acquire events happen? Are you initiation both IKEv1 and
IKEv2 connections? Just start the minimum number of connections for
this strange phenomenon to occur.
Regards
Andreas
On 12/03/2010 09:38 AM, Benoit Foucher wrote:
No other IKE daemons are running, ip xfrm policy does indeed come back
empty:
[r...@gw ~]# /etc/init.d/ipsec stop
Stopping strongSwan IPsec...
[r...@gw ~]# ip xfrm policy
[r...@gw ~]#
Cheers,
Benoit.
On Dec 3, 2010, at 9:25 AM, Andreas Steffen wrote:
Hi Benoit,
is there some other IKE daemon running (e.g. racoon) which is inserting
IPsec policies into the kernel? Does the command
ip xfrm policy
come back empty before you start strongSwan?
Andreas
On 12/03/2010 09:21 AM, Benoit Foucher wrote:
Hi Andreas,
Thanks for your prompt reply. All my connections are defined with
auto=add (a mix of IKEv1 and IKEv2 connections).
Benoit.
On Dec 3, 2010, at 9:18 AM, Andreas Steffen wrote:
Hi Benoit,
it is strange that you get acquire events. Do you define any connections
in ipsec.conf with the setting auto=route? If yes, are these IKEv1
or IKEv2 connections?
Regards
Andreas
On 12/03/2010 09:11 AM, Benoit Foucher wrote:
Hi,
After looking more carefully at the logs, there are also some
suspicious traces for pluto:
pluto[11637]: | creating acquire event for policy 10.12.15.22/32 ===
27.21.27.40/32 with reqid {16420}
pluto[11637]: |
pluto[11637]: | *handling asynchronous events
pluto[11637]: | initiate on demand from 10.12.15.22:0 to 27.21.27.40:0
proto=0 state: fos_start because: whack
pluto[11637]: | find_connection: looking for policy for connection:
10.12.15.22:0/0 - 27.21.27.40:0/0
pluto[11637]: | find_connection: concluding with empty
ip xfrm state gives me the following:
src 10.12.15.22 dst 27.21.27.40
proto esp spi 0xc7c5af3a reqid 16420 mode tunnel
replay-window 32
auth hmac(sha1) 0x47ff9f0112dac804a37a7f47f4371ac8b69219a8
enc cbc(aes) 0xf1bedbfe7aabc07cda4a40b8fb934484
sel src 0.0.0.0/0 dst 0.0.0.0/0
src 27.21.27.40 dst 10.12.15.22
proto esp spi 0xc500ee4a reqid 16420 mode tunnel
replay-window 32
auth hmac(sha1) 0x413ed35699112a5a00599ee721ce72017f400bbb
enc cbc(aes) 0x0b289980e478348eb8950bd4da54b8d3
sel src 0.0.0.0/0 dst 0.0.0.0/0
It sounds like charon fails to retrieve the policy or are those traces
expected?
Thanks
Cheers,
Benoit.
On Dec 2, 2010, at 8:53 PM, Benoit Foucher wrote:
Hi,
I've upgraded from 4.4.1 to 4.5.0 today to workaround the issue where
a given peer ID can't acquire multiple virtual IP addresses. However,
my IKEv1 connections don't work anymore now. I did add
keyexchange=ikev1 to make sure to use pluto. I've attached my config
below.
The tunnel is established but it seems there are some problems with
routing. If I ping my strongSwan gateway from the peer network, the
gateway correctly receives the ICMP packets (according to tcpdump on
the gateway). However, the replies don't seem to be sent back over
the tunnel (I don't see any ICMP reply with tcpdump on the gateway
and the ping from the peer doesn't get any reply either).
The only suspicious thing are the errors below which come from charon
despite the fact that the tunnel is established with pluto. Could
Re: [strongSwan] virtual IP assignement fails if previous tunnel not properly shutdown
Hi Martin, Thanks for your answer. It's not clear to me why using a larger pool would solve the problem. My pool is already quite large and has many addresses available. The gateway refuses to assign the virtual IP (be it the same or a new one) to the new tunnel because a virtual IP is already assigned for the peer identity and it thinks it's still online. Do you know when strongSwan detects that the tunnel is dead and releases the lease for the IP otherwise? Thanks again. Cheers, Benoit. On Dec 2, 2010, at 11:36 AM, Martin Willi wrote: Hi Benoit, 'CN=game.foo.com' already has an online lease, unable to assign address Is there a way to force the IP address assignment for the new tunnel in this case? No, currently not. The address is reserved, and the daemon won't assign it twice. The ipsec.conf uniqueids option won't work either, as it gracefully negotiates the shutdown of the old tunnel. As the peer won't respond on this SA, this takes several retransmits. This is a good case where the INITIAL_CONTACT notify could delete the old SA, but we currently do not support it. One option is to set leftsourceip on the client to the specific IP, the server will reassign it in this case. But this probably won't solve the problem, you'll have a conflict between the old and the new CHILD_SA. The only solution I currently see is to use a larger pool with multiple addresses. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] virtual IP assignement fails if previous tunnel not properly shutdown
Thanks for your help. I'll upgrade to 4.5.0. Cheers, Benoit. On Dec 2, 2010, at 12:07 PM, Martin Willi wrote: My pool is already quite large and has many addresses available. The memory pool in 4.4.1 is limited to a single IP for each ID. This has been fixed with 4.5.0, where you can assign multiple leases to the same identity. Upgrading your server to 4.5.0 should fix the problem. Do you know when strongSwan detects that the tunnel is dead and releases the lease for the IP otherwise? Depends on your configuration, ~2min after the server initiates an exchange on this connection. This exchange might be triggered by a rekey, or can be enforced with DPD checks (man ipsec.conf for dpd). Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] IKEv1 connection issues after upgrading from 4.4.1 to 4.5.0
Hi,
I've upgraded from 4.4.1 to 4.5.0 today to workaround the issue where a given
peer ID can't acquire multiple virtual IP addresses. However, my IKEv1
connections don't work anymore now. I did add keyexchange=ikev1 to make sure to
use pluto. I've attached my config below.
The tunnel is established but it seems there are some problems with routing. If
I ping my strongSwan gateway from the peer network, the gateway correctly
receives the ICMP packets (according to tcpdump on the gateway). However, the
replies don't seem to be sent back over the tunnel (I don't see any ICMP reply
with tcpdump on the gateway and the ping from the peer doesn't get any reply
either).
The only suspicious thing are the errors below which come from charon despite
the fact that the tunnel is established with pluto. Could this be related to
the change where pluto is now using netlink for setting up policies? Here are
the messages:
charon: 05[KNL] received an SADB_ACQUIRE with policy id 140489 but no matching
policy found
charon: 05[KNL] creating acquire job for policy 10.12.15.22/32 ===
27.21.27.40/32 with reqid {0}
charon: 03[CFG] trap not found, unable to acquire reqid 0
My ipsec.conf for that connection:
---
config setup
plutodebug=control
crlcheckinterval=180
strictcrlpolicy=no
charonstart=yes
plutostart=yes
nat_traversal=yes
conn %default
ikelifetime=3h
lifetime=3h
rekeymargin=3m
keyingtries=1
left=%defaultroute
left...@gw.foo.com
leftsourceip=192.168.128.1
leftsubnet=192.168.128.0/17
leftcert=gw_cert.pem
leftfirewall=yes
rightfirewall=yes
conn sj-gw
keyexchange=ikev1
right=%any
leftsubnet=192.168.0.0/16
rightsubnet=192.168.0.0/16
right...@sj-gw.foo.com
auto=add
Any ideas what could be wrong? Is there some additional settings require for
4.5.0 now?
Thanks for the help!
Cheers,
Benoit.
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
