Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(3) |
Apr
(6) |
May
|
Jun
(14) |
Jul
(4) |
Aug
(19) |
Sep
(27) |
Oct
(7) |
Nov
(4) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(58) |
Feb
(20) |
Mar
(70) |
Apr
(93) |
May
(102) |
Jun
(130) |
Jul
(47) |
Aug
(61) |
Sep
(149) |
Oct
(160) |
Nov
(243) |
Dec
(94) |
| 2005 |
Jan
(199) |
Feb
(166) |
Mar
(276) |
Apr
(422) |
May
(289) |
Jun
(222) |
Jul
(306) |
Aug
(154) |
Sep
(72) |
Oct
(163) |
Nov
(113) |
Dec
(195) |
| 2006 |
Jan
(174) |
Feb
(94) |
Mar
(130) |
Apr
(45) |
May
(85) |
Jun
(115) |
Jul
(120) |
Aug
(111) |
Sep
(210) |
Oct
(56) |
Nov
(72) |
Dec
(30) |
| 2007 |
Jan
(56) |
Feb
(49) |
Mar
(35) |
Apr
(58) |
May
(83) |
Jun
(101) |
Jul
(46) |
Aug
(58) |
Sep
(47) |
Oct
(58) |
Nov
(55) |
Dec
(54) |
| 2008 |
Jan
(52) |
Feb
(21) |
Mar
(20) |
Apr
(49) |
May
(20) |
Jun
(37) |
Jul
(101) |
Aug
(49) |
Sep
(75) |
Oct
(152) |
Nov
(34) |
Dec
(63) |
| 2009 |
Jan
(90) |
Feb
(12) |
Mar
(88) |
Apr
(49) |
May
(36) |
Jun
(36) |
Jul
(52) |
Aug
(54) |
Sep
(19) |
Oct
(45) |
Nov
(18) |
Dec
(34) |
| 2010 |
Jan
(12) |
Feb
(28) |
Mar
(18) |
Apr
(19) |
May
(14) |
Jun
(15) |
Jul
(24) |
Aug
(45) |
Sep
(6) |
Oct
(4) |
Nov
(21) |
Dec
(23) |
| 2011 |
Jan
(24) |
Feb
(45) |
Mar
(56) |
Apr
(18) |
May
(4) |
Jun
(10) |
Jul
(15) |
Aug
(38) |
Sep
(11) |
Oct
(48) |
Nov
(55) |
Dec
(29) |
| 2012 |
Jan
(41) |
Feb
(15) |
Mar
(24) |
Apr
(17) |
May
(12) |
Jun
(17) |
Jul
(18) |
Aug
(17) |
Sep
(17) |
Oct
(4) |
Nov
(8) |
Dec
(13) |
| 2013 |
Jan
(9) |
Feb
(1) |
Mar
(10) |
Apr
(18) |
May
(18) |
Jun
(14) |
Jul
(34) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(8) |
Dec
(4) |
| 2014 |
Jan
(12) |
Feb
(6) |
Mar
(1) |
Apr
(12) |
May
|
Jun
(2) |
Jul
(20) |
Aug
(1) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
|
| 2015 |
Jan
(16) |
Feb
(2) |
Mar
(9) |
Apr
|
May
(56) |
Jun
(6) |
Jul
(7) |
Aug
(1) |
Sep
(17) |
Oct
(13) |
Nov
(23) |
Dec
(3) |
| 2016 |
Jan
(10) |
Feb
(8) |
Mar
(34) |
Apr
(19) |
May
(26) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(6) |
Nov
(5) |
Dec
(2) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(12) |
2
(3) |
|
3
(8) |
4
(10) |
5
(6) |
6
(8) |
7
(7) |
8
(17) |
9
(14) |
|
10
(11) |
11
(21) |
12
(11) |
13
(10) |
14
(21) |
15
(10) |
16
(10) |
|
17
(22) |
18
(24) |
19
(20) |
20
(11) |
21
(3) |
22
(2) |
23
(2) |
|
24
(1) |
25
(12) |
26
(10) |
27
(9) |
28
(8) |
29
(3) |
30
|
|
31
|
|
|
|
|
|
|
|
From: Alexandre Hautequest <hquest@on...> - 2005-07-18 17:49:30
|
urimobile@... wrote: > Yvan, > > Could you provide examples? Numeric SPD and SAD entries for the below configuration - for Transport mode, and for Tunnel mode? In form of "setkey" input (to make it easy to write and easy to read/understand)? I provided concrete IP addresses to make this exercise possible. > > Thank you!! > > P.S. If necessary to illustrate the point - you may assume LAN to the left of host A and to the right of host B, 9.8.7.0/24 on the left and 9.8.5.0/24 on the right. > > > Assumptions: host A knows about B only NATr public IP address, host B knows nothing about host A and anything to the left of it. > > Host A > Initiator <-----------> NATi <------- Internet -----> > 1.2.3.4 1.2.3.254 - 10.0.0.1 > > Host B > -------> NATr <----------> Responder > 11.0.0.2 - 1.2.3.254 1.2.3.8 > > Responder (host B) runs Racoon. How would it generate SPD (and SAD) > entries for IPsec between A and B for Transport mode and for Tunnel > mode? What would those SPD entries look like? > Just a side note: This setup will not work because both Host A and B are on the same network addresses (1.2.3.0) and they will keep searching for hosts on local network, unless some kind of "proxy arp" could be added to this setup. -- Alexandre |
|
From: <urimobile@op...> - 2005-07-18 16:16:50
|
Yvan,
Could you provide examples? Numeric SPD and SAD entries for the below configuration - for Transport mode, and for Tunnel mode? In form of "setkey" input (to make it easy to write and easy to read/understand)? I provided concrete IP addresses to make this exercise possible.
Thank you!!
P.S. If necessary to illustrate the point - you may assume LAN to the left of host A and to the right of host B, 9.8.7.0/24 on the left and 9.8.5.0/24 on the right.
Assumptions: host A knows about B only NATr public IP address, host B knows nothing about host A and anything to the left of it.
Host A
Initiator <-----------> NATi <------- Internet ----->
1.2.3.4 1.2.3.254 - 10.0.0.1
Host B
-------> NATr <----------> Responder
11.0.0.2 - 1.2.3.254 1.2.3.8
Responder (host B) runs Racoon. How would it generate SPD (and SAD)
entries for IPsec between A and B for Transport mode and for Tunnel
mode? What would those SPD entries look like?
|
|
From: <urimobile@op...> - 2005-07-18 16:02:50
|
Yvan, I'm sorry to say that I still see no difference *from NAT-T point of view* between Tunnel and Transport. The only thing that your diagram depicts differently is presence of LANs on each side of the "IPsec-talking" hosts. OK, that would add some extra parameters to SPD etc. - but it still doesn't change what host-A-to-host-B (in my diagram :-) addresses and ports should be with NAT-T... I'll probably be in Paris first week of August. Could we chat then and there? Manu? ----- Original Message ----- From: VANHULLEBUS Yvan <vanhu@...> Date: Monday, July 18, 2005 3:07 am Subject: Re: [Ipsec-tools-devel] Re: GreenBow VPN > On Sun, Jul 17, 2005 at 10:04:07PM -0700, urimobile@... > wrote:> > You are thinking in transport mode. > > > > Probably... But still... > > Here is a setup for a Tunnel scenario: > > LanA <--> GateA <========================> GateB <--> LanB > > > So, when we have traffic from LanA to LanB, GateA will encapsulate it, > send the encapsulated packet to GateB, which will decapsulate it and > send it to the correct host on LanB. > And vice versa. > > Note that GateA and GateB's IPs are probably NOT on (resp.) LanA and > LanB. > > When negociating, each gate will know peer's Gate IP address (at least > in the IP header of each Isakmp message) and peer's Lan network > (duringthe quick mode, it's a part of the negociation). > > And that's enough when generating policies with racoon. > > > Now, let's set up some NAT on the way: > > > LanA <--> GateA <== NatA =================== NatB ==> GateB <--> LanB > > > Now, during the negociation, each Gate will still have the peer's Lan > network, but will have peer's NATed address for peer's gate. > > But we just don't care, because this NATed address is the address to > which we'll send Isakmp messages and ESP/UDP encapsulated traffic. > > > We have a traffic profile to check for packets to encrypt, and an IP > to send the packets to. If this IP address is the address of a NAT > device and not the real address of the peer Gate, we just don't care > about that, it's a problem for the peer NAT device, it's it's job ! > > Detecting NAT on the way and doing some UDP encapsulation here is hust > to help the NAT device doing this job ! > > > > > In tunnel mode, SPDs have the traffic policy and the tunnel > endpoints,> > which are distinct. > > > > Yes. But if the tunnel is from behind a NAT on both ends, the peers > > may not know each other original addresses, and even if they did > - > > it wouldn't help them because those addresses are non-accessible and > > non-routable from outside the NAT. And applications will have to use > > NAT-ed peer addresses rather than the original ones - otherwise > > their packets won't get there. > > Traffic addresses in Tunnel mode don't care about Tunnel endpoints. > > And tunnel endpoints don't care if the remote Tunnel IP is the address > of the gate of the address of a NAT device, as I just explained upper. > > > > > The traffic policy is negociated in the quick mode (with or > without> > NAT-T), and the remote tunnel endpoint is "the addres > we can see", > > > > But NAT adds crucial difference: with NAT you don't know the correct > > IP address of the peer in advance (so you cannot pre-load the > > appropriate policy). > > You know "the address you use to contact the peer", which is > enough to > contact peer's gate, and "the traffic to encrypt", which has nothing > to do with the NAT on the way, it's just a encrypted and encapsulated > payload for the NAT device. > > > > > I'm confused - I don't see how IPsec mode (transport or tunnel) can > > possibly make any difference on what IP addresses we put in the SPD > > for IPsec SA end-points. > > In Tunnel mode, you have to make difference between "tunnel endpoints" > and "traffic endpoints". > > > > > and we don't care if this is not the real address of the remote > > > IPSec gate, this is the address we use to contact it, > > > and we don't need any more informations. > > > > First, my main confusion is on the use of our own IP > > address. Because in the phase2 (isakmp_quick) the Initiator uses our > > NAT-ed address in negotiation, but we must put our original IP > > address in SPD entry. It doesn't matter whether it's tunnel or > > transport end-point. > > In tunnel mode, during the quick mode, one of the payloads contains > "the traffic to encrypt with this SA", which has nothing to do with > Gate's IP addresses ! > > And this is this payload which is used as the traffic's values of the > generated SPD. > > > > Second - we can contact the NAT-ed peer only using its NAT-ed > > address (not its original address), again regardless of whether it's > > tunnel or transport. > > Yep. > > > > Perhaps you could draw a quick diagram with two peers, each > behind a > > NAT, illustrating how SPD would be different for Tunnel and > > Transport? > > I'm very bad in ASCII drawing, hope this mail helped you understanding > Tunnel mode. > > I wanted to do a quick howto or FAQ for IPSec for a long time, but I > don't have much time for that, and I'm as bad with HTML than with > ASCII drawings...... > > > > Let's assume that Responder knows nothing except his own address > > 1.2.3.8 (and certificate authority :-). Initiator knows his IP > > address 1.2.3.4, and Responder's public IP address 11.0.0.2 > > (otherwise there's no way Initiator can contact the Responder). > > > > Host A > > Initiator <-----------> NATi <------- > > 1.2.3.4 1.2.3.254 - 10.0.0.1 > > > > Host B > > -------> NATr <----------> Responder > > 11.0.0.2 - 1.2.3.254 1.2.3.8 > > > > Responder (host B) runs Racoon. How would it generate SPD (and SAD) > > entries for IPsec between A and B for Transport mode and for Tunnel > > mode? What would those SPD entries look like? > > Once again, you don't make the difference between Tunnel endpoints > (the ones that you are talking about) and Traffic endpoints, which are > missing in your scenario, but MUST be present for a Tunnel setup. > > > Yvan. > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Ipsec-tools-devel mailing list > Ipsec-tools-devel@... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > |
|
From: Paul Grabinar <Paul.Grabinar@fl...> - 2005-07-18 13:58:42
|
Larry, Just to let you know your patches worked a treat. I am now connected to = racoon from a GreenBow client with NAT. Thank you very much for your help. Paul. -----Original Message----- From: Larry Baird [mailto:lab@...] Sent: 15 July 2005 15:20 To: Paul Grabinar Cc: ipsec-tools-devel@... Subject: Re: GreenBow VPN Paul, > Sorry to contact you directly, but we are trying to use the GreenBow = VPN client on Windows talking to a Linux machine running racoon using = NAT support. I saw you made some changes in the area and I am using = racoon 0.6, which I believe includes the changes. However, when clients = try to connect, the following is logged: I havn't tried greenbow with certificates. The message: > Jul 15 08:26:15 [racoon] ERROR: ignore the packet, received = unexpecting payloa d type 131._ looks familiar. I think one change I made to support greenbow didn't = make it into the patches I submitted. Can you try the attached patches to = verify this is this is the missing one. Larry >=20 > Jul 15 08:25:50 [racoon] INFO: begin Identity Protection mode._ > Jul 15 08:25:50 [racoon] INFO: received Vendor ID: = draft-ietf-ipsec-nat-t-ike-00_ > Jul 15 08:25:50 [racoon] INFO: received Vendor ID: = draft-ietf-ipsec-nat-t-ike-02__ > Jul 15 08:25:50 [racoon] INFO: received Vendor ID: = draft-ietf-ipsec-nat-t-ike-03_ > Jul 15 08:25:50 [racoon] INFO: Selected NAT-T version: = draft-ietf-ipsec-nat-t-ike-02__ > Jul 15 08:25:52 [racoon] WARNING: CR received, ignore it. It should be = in other exchange._ > Jul 15 08:25:52 [racoon] INFO: Hashing 83.104.187.235[500] with algo = #1 _ > Jul 15 08:25:52 [racoon] INFO: NAT-D payload #0 verified_ > Jul 15 08:25:52 [racoon] INFO: Hashing 212.183.128.185[37962] with = algo #1 _ > Jul 15 08:25:52 [racoon] INFO: NAT-D payload #1 doesn't match_ > Jul 15 08:25:52 [racoon] INFO: NAT detected: PEER_ > Jul 15 08:25:52 [racoon] INFO: Hashing 212.183.128.185[37962] with = algo #1 _ > Jul 15 08:25:52 [racoon] INFO: Hashing 83.104.187.235[500] with algo = #1 _ > Jul 15 08:25:52 [racoon] INFO: Adding remote and local NAT-D = payloads._ > Jul 15 08:25:54 [racoon] INFO: NAT-T: ports changed to: = 212.183.128.185[41119]<->83.104.187.235[4500]_ > Jul 15 08:25:54 [racoon] INFO: KA list add: = 83.104.187.235[4500]->212.183.128.185[41119]_ > Jul 15 08:25:54 [racoon] WARNING: unable to get certificate CRL(3) at = depth:0 = SubjectName:/C=3DUK/ST=3DBerkshire/L=3DFinchamstead/O=3DflyingSPARK/OU=3D= IT/CN=3Dplglap2.flyingspark.com/emailAddress=3Dinfo@... > Jul 15 08:25:54 [racoon] WARNING: unable to get certificate CRL(3) at = depth:1 = SubjectName:/C=3DUK/ST=3DBerkshire/L=3DFinchamstead/O=3DflyingSPARK/OU=3D= IT/CN=3DflyingSPARK/emailAddress=3Dinfo@... > Jul 15 08:25:54 [racoon] INFO: ISAKMP-SA established = 83.104.187.235[4500]-212.183.128.185[41119] = spi:78402a8a345bc38c:2b2fb388fbed65d5_ > Jul 15 08:25:59 [racoon] INFO: respond new phase 2 negotiation: = 83.104.187.235[4500]<=3D>212.183.128.185[41119]_ > Jul 15 08:25:59 [racoon] ERROR: ignore the packet, received = unexpecting payload type 131._ > Jul 15 08:25:59 [racoon] ERROR: failed to pre-process packet._ > Jul 15 08:26:05 [racoon] INFO: respond new phase 2 negotiation: = 83.104.187.235[4500]<=3D>212.183.128.185[41119]_ > Jul 15 08:26:05 [racoon] ERROR: ignore the packet, received = unexpecting payload type 131._ > Jul 15 08:26:05 [racoon] ERROR: failed to pre-process packet._ > Jul 15 08:26:15 [racoon] INFO: respond new phase 2 negotiation: = 83.104.187.235[4500]<=3D>212.183.128.185[41119]_ > Jul 15 08:26:15 [racoon] ERROR: ignore the packet, received = unexpecting payload type 131._ >=20 > A quick debug showed that the error is comming from isakmp_quick.c = line 2112, which seems to be outside the scope of the paches. >=20 > I can't get past the payload type error. Any ideas? >=20 > Paul. >=20 --=20 ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@... | TEL 407-380-0220, FAX 407-380-6080 |
|
From: Marco Berizzi <pupilla@ho...> - 2005-07-18 13:17:30
|
Aidas Kasparas wrote: > It sets esp/tunnel SA into kernel instead of esp/transport, and for > every outgoing packet kernel asks to "acquire" esp/transport SA. This is > why racoon establishes a lot of them. > > I'm attaching diff which tries to address that problem (note, it's work > in progress, needs cleanup, do not address remote->local SAs, so use it > only if you're brave enought). If you'll succeed to send ping packet > from local network to the remote network, I'll know I'm on the right way. > > [I developed that behind NAT not in my control + used not sufficient > racoon.conf => may be was too pesimistic] "Morning is clever than evening!" Ok, applied to ipsec-tools 0.6: same problem :-(( As you may see, this patch tries to set also ipcomp in transport mode. Here is setkey -D output: 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=476189880(0x1c6214b8) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:09:55 2005 current: Jul 18 15:09:56 2005 diff: 1(s) hard: 2400(s) soft: 1920(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=88 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=210166284(0x0c86e20c) reqid=0(0x00000000) E: 3des-cbc b19c49d1 6fdf0000 3bfe379e 77736546 379928e7 9309021e A: hmac-md5 d5919f5b 0512a468 2203354d 42d698f9 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:09:55 2005 current: Jul 18 15:09:56 2005 diff: 1(s) hard: 2400(s) soft: 1920(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=87 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=2135864849(0x7f4eb611) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:09:54 2005 current: Jul 18 15:09:56 2005 diff: 2(s) hard: 2400(s) soft: 1920(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=86 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=118743567(0x0713e20f) reqid=0(0x00000000) E: 3des-cbc e53dbfb6 f4b49335 a3307e12 eb53b333 29a5b346 6f99fb17 A: hmac-md5 b1a53171 153ddee9 5be51754 508fd448 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:09:54 2005 current: Jul 18 15:09:56 2005 diff: 2(s) hard: 2400(s) soft: 1920(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=85 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=2346000977(0x8bd52251) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:47 2005 current: Jul 18 15:09:56 2005 diff: 69(s) hard: 2400(s) soft: 1920(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=84 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=134427128(0x080331f8) reqid=0(0x00000000) E: 3des-cbc 04f2da02 37c71513 cbb963f7 4d16aa1a 36c218d7 2384085a A: hmac-md5 0448597c 12fc663c 2f6b27c3 70347722 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:47 2005 current: Jul 18 15:09:56 2005 diff: 69(s) hard: 2400(s) soft: 1920(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=83 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=3425982802(0xcc345952) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:46 2005 current: Jul 18 15:09:56 2005 diff: 70(s) hard: 2400(s) soft: 1920(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=82 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=77522548(0x049ee674) reqid=0(0x00000000) E: 3des-cbc 5644642f d0ec4348 f890f5a5 2685ff81 d61c32f3 1df6f23a A: hmac-md5 78b309ea 14cac533 84957be4 e7a73fdf seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:46 2005 current: Jul 18 15:09:56 2005 diff: 70(s) hard: 2400(s) soft: 1920(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=81 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=3787712(0x0039cbc0) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:45 2005 current: Jul 18 15:09:56 2005 diff: 71(s) hard: 2400(s) soft: 1920(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=80 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=46588079(0x02c6e0af) reqid=0(0x00000000) E: 3des-cbc 673afc87 9d439c9a 6cfeac7b ca4de6d6 2374a007 17909f5b A: hmac-md5 a6cfddae 01120883 cfbdc8c0 5d3b3ae3 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:45 2005 current: Jul 18 15:09:56 2005 diff: 71(s) hard: 2400(s) soft: 1920(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=79 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=2839363635(0xa93d4033) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:45 2005 current: Jul 18 15:09:56 2005 diff: 71(s) hard: 2400(s) soft: 1920(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=78 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=94428717(0x05a0de2d) reqid=0(0x00000000) E: 3des-cbc dcf9566e 78cee42c 26c35947 43e40728 d1b08b62 e9d9b9e9 A: hmac-md5 cb92d868 8c1dbfdb df3d80a8 ddd2ce27 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:45 2005 current: Jul 18 15:09:56 2005 diff: 71(s) hard: 2400(s) soft: 1920(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=77 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=2467354471(0x9310d767) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:44 2005 current: Jul 18 15:09:56 2005 diff: 72(s) hard: 2400(s) soft: 1920(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=76 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=231310243(0x0dc983a3) reqid=0(0x00000000) E: 3des-cbc da19dbf4 356bef77 580a1109 c80e8e61 86ecf566 a699eb1f A: hmac-md5 2f69dc90 dd086adc 6f833418 fd28efb6 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:44 2005 current: Jul 18 15:09:56 2005 diff: 72(s) hard: 2400(s) soft: 1920(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=75 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=3378070425(0xc9594399) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:44 2005 current: Jul 18 15:09:56 2005 diff: 72(s) hard: 2400(s) soft: 1920(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=74 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=175600616(0x0a7773e8) reqid=0(0x00000000) E: 3des-cbc b05eece4 2a0724b7 3f00c2c7 f29cddf1 aa66b918 b3760e51 A: hmac-md5 6be9fcbe c2631b95 19fee77f 6ff032bd seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:44 2005 current: Jul 18 15:09:56 2005 diff: 72(s) hard: 2400(s) soft: 1920(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=73 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=3075016554(0xb749076a) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:43 2005 current: Jul 18 15:09:56 2005 diff: 73(s) hard: 2400(s) soft: 1920(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=72 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=126068351(0x0783a67f) reqid=0(0x00000000) E: 3des-cbc bf4551fd 0088368b f9242255 d1263131 5823d6e4 cd5914eb A: hmac-md5 74d741c4 b0b024e4 cf6d3d36 5c94c069 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:43 2005 current: Jul 18 15:09:56 2005 diff: 73(s) hard: 2400(s) soft: 1920(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=71 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=3029360117(0xb4905df5) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:43 2005 current: Jul 18 15:09:56 2005 diff: 73(s) hard: 2400(s) soft: 1920(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=70 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=232949664(0x0de287a0) reqid=0(0x00000000) E: 3des-cbc 1d283316 19a85805 71b26559 112e91ef 195e771a 7e4b8dec A: hmac-md5 f12bbf11 8f9f7d85 32647510 775bec7a seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:43 2005 current: Jul 18 15:09:56 2005 diff: 73(s) hard: 2400(s) soft: 1920(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=69 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=616683333(0x24c1d745) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:42 2005 current: Jul 18 15:09:56 2005 diff: 74(s) hard: 2400(s) soft: 1920(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=68 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=104346237(0x0638327d) reqid=0(0x00000000) E: 3des-cbc e1080706 4b483122 c4406629 d24beb6b 6b85ee27 a180ae18 A: hmac-md5 347e5427 cabcb0d7 864556d4 2cc5c7a7 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:42 2005 current: Jul 18 15:09:56 2005 diff: 74(s) hard: 2400(s) soft: 1920(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=67 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=2937499389(0xaf16aefd) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:42 2005 current: Jul 18 15:09:56 2005 diff: 74(s) hard: 2400(s) soft: 1920(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=66 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=90093803(0x055eb8eb) reqid=0(0x00000000) E: 3des-cbc f78734f2 cb89a2aa 4873be1e 1075a553 1f795924 16e4574f A: hmac-md5 abaaa0d9 0ad81db3 44233d3f 1f0e040f seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:42 2005 current: Jul 18 15:09:56 2005 diff: 74(s) hard: 2400(s) soft: 1920(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=65 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=3490657258(0xd00f33ea) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:41 2005 current: Jul 18 15:09:56 2005 diff: 75(s) hard: 2400(s) soft: 1920(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=64 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=141725126(0x08728dc6) reqid=0(0x00000000) E: 3des-cbc 6110777d ec81f730 c0df7de3 3a7e8406 07f9d6de ade8ea9f A: hmac-md5 24f02962 533548df 1abd8970 c4e59efb seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:41 2005 current: Jul 18 15:09:56 2005 diff: 75(s) hard: 2400(s) soft: 1920(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=63 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=2059182530(0x7abca1c2) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:40 2005 current: Jul 18 15:09:56 2005 diff: 76(s) hard: 2400(s) soft: 1920(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=62 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=137367830(0x08301116) reqid=0(0x00000000) E: 3des-cbc f062044e 4a9facf5 a0bb3c76 379954d0 e5288fe3 66bc66f9 A: hmac-md5 b3cb5ad6 580ac36e 272bb8d6 6ce3ba0a seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:40 2005 current: Jul 18 15:09:56 2005 diff: 76(s) hard: 2400(s) soft: 1920(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=61 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=2879980559(0xaba9040f) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:39 2005 current: Jul 18 15:09:56 2005 diff: 77(s) hard: 2400(s) soft: 1920(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=60 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=57773000(0x03718bc8) reqid=0(0x00000000) E: 3des-cbc ac7bb4f1 8717fb50 2285b98b 095375c5 74035713 db7059b8 A: hmac-md5 fce12a5f 878ac74a 6a3e2351 8fc1d613 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:39 2005 current: Jul 18 15:09:56 2005 diff: 77(s) hard: 2400(s) soft: 1920(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=59 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=4759395(0x00489f63) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:38 2005 current: Jul 18 15:09:56 2005 diff: 78(s) hard: 2400(s) soft: 1920(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=58 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=3586918(0x0036bb66) reqid=0(0x00000000) E: 3des-cbc 61d42341 a7ccba66 40b4d788 60ee523a b243470b cb0d062b A: hmac-md5 dbf6465f 78e2e7f9 a80b7dd5 13bf2453 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:38 2005 current: Jul 18 15:09:56 2005 diff: 78(s) hard: 2400(s) soft: 1920(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=57 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=1593871366(0x5f008c06) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:37 2005 current: Jul 18 15:09:56 2005 diff: 79(s) hard: 2400(s) soft: 1920(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=56 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=63655059(0x03cb4c93) reqid=0(0x00000000) E: 3des-cbc c2b5224d 53501600 ffc38c34 fa945f00 b30fab2d bc17fee8 A: hmac-md5 9222f2e4 534bd3dd 4b52c12d 974c0a56 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:37 2005 current: Jul 18 15:09:56 2005 diff: 79(s) hard: 2400(s) soft: 1920(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=55 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=3158259609(0xbc3f3799) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:37 2005 current: Jul 18 15:09:56 2005 diff: 79(s) hard: 2400(s) soft: 1920(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=54 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=245058724(0x0e9b4ca4) reqid=0(0x00000000) E: 3des-cbc e9e8d8a1 efd06b56 65550a4b 68775333 7dbec8cc 2d6a32d4 A: hmac-md5 5882d164 439df210 fb809705 ffa35109 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:37 2005 current: Jul 18 15:09:56 2005 diff: 79(s) hard: 2400(s) soft: 1920(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=53 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=1563314110(0x5d2e47be) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:36 2005 current: Jul 18 15:09:56 2005 diff: 80(s) hard: 2400(s) soft: 1920(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=52 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=149046797(0x08e2460d) reqid=0(0x00000000) E: 3des-cbc d9176856 4956c256 0111617b f0e27e6f 755945c3 ce16b05c A: hmac-md5 628483fd 77d48749 8ef45a8e ee16396f seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:36 2005 current: Jul 18 15:09:56 2005 diff: 80(s) hard: 2400(s) soft: 1920(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=51 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=3837709950(0xe4bece7e) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:36 2005 current: Jul 18 15:09:56 2005 diff: 80(s) hard: 2400(s) soft: 1920(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=50 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=267736293(0x0ff554e5) reqid=0(0x00000000) E: 3des-cbc e296bc56 c3c1fde9 a0499f60 e71f22d8 e51693ca 66880f4e A: hmac-md5 f1474dd3 47d0523c ee1c7154 a8b72eb3 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:36 2005 current: Jul 18 15:09:56 2005 diff: 80(s) hard: 2400(s) soft: 1920(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=49 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=3499994987(0xd09daf6b) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:35 2005 current: Jul 18 15:09:56 2005 diff: 81(s) hard: 2400(s) soft: 1920(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=48 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=4951818(0x004b8f0a) reqid=0(0x00000000) E: 3des-cbc 6fe4901e 8495ac28 da962e68 22b6a1a2 edbdb9a6 38ea4298 A: hmac-md5 a5035fd7 54a4e057 f34b363c 4899dca0 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:35 2005 current: Jul 18 15:09:56 2005 diff: 81(s) hard: 2400(s) soft: 1920(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=47 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 ipcomp mode=transport spi=2633938075(0x9cfeb49b) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:07:44 2005 current: Jul 18 15:09:56 2005 diff: 132(s) hard: 2400(s) soft: 1920(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=46 pid=8784 refcnt=0 172.16.1.226 172.16.1.247 esp mode=transport spi=235332441(0x0e06e359) reqid=0(0x00000000) E: 3des-cbc b9cba7e2 d5aa22ab 584bc878 5b281aa2 521b8005 b27ed4f1 A: hmac-md5 fc701c91 81789e00 9b5f8637 daaeb90c seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:07:44 2005 current: Jul 18 15:09:56 2005 diff: 132(s) hard: 2400(s) soft: 1920(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=45 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=25739(0x0000648b) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:09:55 2005 current: Jul 18 15:09:56 2005 diff: 1(s) hard: 2400(s) soft: 1920(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=44 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=3223392957(0xc02112bd) reqid=0(0x00000000) E: 3des-cbc 08a36afb 78c9e8c3 ff62e17f fe92280d 417a36ee 8eba55c1 A: hmac-md5 e9f5753f 652c956d dec5a9bb fd9f17f5 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:09:55 2005 current: Jul 18 15:09:56 2005 diff: 1(s) hard: 2400(s) soft: 1920(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=43 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=22903(0x00005977) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:09:54 2005 current: Jul 18 15:09:56 2005 diff: 2(s) hard: 2400(s) soft: 1920(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=42 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=4197347300(0xfa2e6fe4) reqid=0(0x00000000) E: 3des-cbc 7049095f 3b50a797 5e3968bc d2debb42 8d8da10f 681765b0 A: hmac-md5 6d804a53 9fc5cbe4 6be839ee 6cd67949 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:09:54 2005 current: Jul 18 15:09:56 2005 diff: 2(s) hard: 2400(s) soft: 1920(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=41 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=22462(0x000057be) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:47 2005 current: Jul 18 15:09:56 2005 diff: 69(s) hard: 2400(s) soft: 1920(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=40 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=1217580093(0x4892cc3d) reqid=0(0x00000000) E: 3des-cbc 902b1d4c 3080b432 96d946db 03c274cd 82fb2bec f009cd22 A: hmac-md5 5cd16b05 e7ec858e efc7da03 56fa6050 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:47 2005 current: Jul 18 15:09:56 2005 diff: 69(s) hard: 2400(s) soft: 1920(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=39 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=48135(0x0000bc07) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:46 2005 current: Jul 18 15:09:56 2005 diff: 70(s) hard: 2400(s) soft: 1920(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=38 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=1343846995(0x50197a53) reqid=0(0x00000000) E: 3des-cbc 5a0473d8 60cabb26 9d51432a 7f81ac39 47f59c57 bec0e516 A: hmac-md5 32b09414 9ae788ae 32f08982 e4d77ad8 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:46 2005 current: Jul 18 15:09:56 2005 diff: 70(s) hard: 2400(s) soft: 1920(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=37 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=40562(0x00009e72) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:45 2005 current: Jul 18 15:09:56 2005 diff: 71(s) hard: 2400(s) soft: 1920(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=36 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=4148707539(0xf74840d3) reqid=0(0x00000000) E: 3des-cbc 430b9e24 0ac9030f 8ed7bb56 5ada494b 5f4d99ef a869a872 A: hmac-md5 3819001f fd5271a8 935886fc 42b45161 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:45 2005 current: Jul 18 15:09:56 2005 diff: 71(s) hard: 2400(s) soft: 1920(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=35 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=41721(0x0000a2f9) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:45 2005 current: Jul 18 15:09:56 2005 diff: 71(s) hard: 2400(s) soft: 1920(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=34 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=1827842436(0x6cf2a984) reqid=0(0x00000000) E: 3des-cbc e6987886 0f016723 2f6cb0f1 d5105e5e e98de5ac 97c0e913 A: hmac-md5 eb692b87 6210ff12 098e9de5 9af549be seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:45 2005 current: Jul 18 15:09:56 2005 diff: 71(s) hard: 2400(s) soft: 1920(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=33 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=51899(0x0000cabb) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:44 2005 current: Jul 18 15:09:56 2005 diff: 72(s) hard: 2400(s) soft: 1920(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=32 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=888203340(0x34f0e84c) reqid=0(0x00000000) E: 3des-cbc 424ab421 284f552e 6f5606d0 58468d83 af5fdf1a 89b4eb07 A: hmac-md5 71aa75ec 0fe7b335 104c46d3 9e4abf93 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:44 2005 current: Jul 18 15:09:56 2005 diff: 72(s) hard: 2400(s) soft: 1920(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=31 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=14321(0x000037f1) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:44 2005 current: Jul 18 15:09:56 2005 diff: 72(s) hard: 2400(s) soft: 1920(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=30 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=725026407(0x2b370667) reqid=0(0x00000000) E: 3des-cbc 2b2b1e73 35588db9 85989d1b 8b800de3 d4fe2b47 8e29da04 A: hmac-md5 f62159d9 cbdb822f d56a6170 f28ed503 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:44 2005 current: Jul 18 15:09:56 2005 diff: 72(s) hard: 2400(s) soft: 1920(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=29 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=10447(0x000028cf) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:43 2005 current: Jul 18 15:09:56 2005 diff: 73(s) hard: 2400(s) soft: 1920(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=28 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=2086509900(0x7c5d9d4c) reqid=0(0x00000000) E: 3des-cbc c625504f 52ad295e 7605e767 de888191 c88d7468 9ef17998 A: hmac-md5 5d7467e1 2152546d 4c4461e0 e2bfe472 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:43 2005 current: Jul 18 15:09:56 2005 diff: 73(s) hard: 2400(s) soft: 1920(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=27 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=44309(0x0000ad15) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:43 2005 current: Jul 18 15:09:56 2005 diff: 73(s) hard: 2400(s) soft: 1920(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=26 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=717036562(0x2abd1c12) reqid=0(0x00000000) E: 3des-cbc 94cee8cd c4cd1cd2 86820cd2 7335164e b62ef7f4 0ff02771 A: hmac-md5 7b3d7cae 2bb40f56 e21e131e 87e83c6c seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:43 2005 current: Jul 18 15:09:56 2005 diff: 73(s) hard: 2400(s) soft: 1920(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=25 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=37295(0x000091af) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:42 2005 current: Jul 18 15:09:56 2005 diff: 74(s) hard: 2400(s) soft: 1920(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=24 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=4140375626(0xf6c91e4a) reqid=0(0x00000000) E: 3des-cbc 459e0fe9 a634096b 9a1141d4 e957ccbf 28ea367f 29cfeb47 A: hmac-md5 4d06c05f 897f1b4a 274d49d2 0aac9e2b seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:42 2005 current: Jul 18 15:09:56 2005 diff: 74(s) hard: 2400(s) soft: 1920(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=23 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=32532(0x00007f14) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:42 2005 current: Jul 18 15:09:56 2005 diff: 74(s) hard: 2400(s) soft: 1920(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=22 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=138984752(0x0848bd30) reqid=0(0x00000000) E: 3des-cbc 4e5702a5 f003e938 5b451f73 afd4b926 e90463ab 756a110b A: hmac-md5 f91896ab 31e463c9 c2347987 102607ba seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:42 2005 current: Jul 18 15:09:56 2005 diff: 74(s) hard: 2400(s) soft: 1920(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=21 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=33144(0x00008178) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:41 2005 current: Jul 18 15:09:56 2005 diff: 75(s) hard: 2400(s) soft: 1920(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=20 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=2987003621(0xb20a0ee5) reqid=0(0x00000000) E: 3des-cbc 46f2e5fc 31d3e593 17d94b32 4b810379 af09dbe1 e9c731ed A: hmac-md5 623c55eb 3415d5c2 8dab535e 907b5ba1 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:41 2005 current: Jul 18 15:09:56 2005 diff: 75(s) hard: 2400(s) soft: 1920(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=19 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=24586(0x0000600a) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:40 2005 current: Jul 18 15:09:56 2005 diff: 76(s) hard: 2400(s) soft: 1920(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=18 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=3630473442(0xd864a0e2) reqid=0(0x00000000) E: 3des-cbc 801a40d3 6817d10a 9ceb9172 34070345 4bdf2b9b 18998e5f A: hmac-md5 d5600b63 ba2926a5 54a1c24c a5be463e seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:40 2005 current: Jul 18 15:09:56 2005 diff: 76(s) hard: 2400(s) soft: 1920(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=17 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=52679(0x0000cdc7) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:39 2005 current: Jul 18 15:09:56 2005 diff: 77(s) hard: 2400(s) soft: 1920(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=16 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=3096217702(0xb88c8866) reqid=0(0x00000000) E: 3des-cbc 3da4a855 2bd6ab3d 4b90ae30 f2f65410 f4e167e8 13d9f8b6 A: hmac-md5 a2fe0a9f 1f5ed04a 46f56f3c f915b488 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:39 2005 current: Jul 18 15:09:56 2005 diff: 77(s) hard: 2400(s) soft: 1920(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=15 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=19170(0x00004ae2) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:38 2005 current: Jul 18 15:09:56 2005 diff: 78(s) hard: 2400(s) soft: 1920(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=14 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=701370850(0x29ce11e2) reqid=0(0x00000000) E: 3des-cbc ada5aaa1 2ec7ed2b 5c9fbbf7 b16d116d 7956d0a3 dea56a55 A: hmac-md5 b114da94 2d7e95dc edc24698 118e0dc1 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:38 2005 current: Jul 18 15:09:56 2005 diff: 78(s) hard: 2400(s) soft: 1920(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=13 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=20981(0x000051f5) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:37 2005 current: Jul 18 15:09:56 2005 diff: 79(s) hard: 2400(s) soft: 1920(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=12 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=1011058184(0x3c438608) reqid=0(0x00000000) E: 3des-cbc 44d4ae02 6c646483 21b71900 a9f3c332 d881658a 936fd53a A: hmac-md5 d8e23480 7af7caaa e0d27a9a 0838363b seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:37 2005 current: Jul 18 15:09:56 2005 diff: 79(s) hard: 2400(s) soft: 1920(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=11 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=31479(0x00007af7) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:37 2005 current: Jul 18 15:09:56 2005 diff: 79(s) hard: 2400(s) soft: 1920(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=10 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=3263724104(0xc2887a48) reqid=0(0x00000000) E: 3des-cbc 888fde1e fed9b47a d436fd1e a191ba2f c84b8785 e3835687 A: hmac-md5 f8793dc1 7d372976 52923af2 d24fd8f1 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:37 2005 current: Jul 18 15:09:56 2005 diff: 79(s) hard: 2400(s) soft: 1920(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=9 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=45874(0x0000b332) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:36 2005 current: Jul 18 15:09:56 2005 diff: 80(s) hard: 2400(s) soft: 1920(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=8 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=1063548279(0x3f647577) reqid=0(0x00000000) E: 3des-cbc af2149d1 90cd8068 120d2452 e111f3e6 8fcac39d 4e991616 A: hmac-md5 1090ce42 6671f824 1d8def65 5031b85b seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:36 2005 current: Jul 18 15:09:56 2005 diff: 80(s) hard: 2400(s) soft: 1920(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=7 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=31301(0x00007a45) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:36 2005 current: Jul 18 15:09:56 2005 diff: 80(s) hard: 2400(s) soft: 1920(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=6 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=1786474933(0x6a7b71b5) reqid=0(0x00000000) E: 3des-cbc 380f30aa 34477478 ea84cbf9 fe792072 5dd37957 b655836f A: hmac-md5 e337afcd e7ceaca2 209ffdd7 e2cd07dc seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:36 2005 current: Jul 18 15:09:56 2005 diff: 80(s) hard: 2400(s) soft: 1920(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=5 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=2153(0x00000869) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:08:35 2005 current: Jul 18 15:09:56 2005 diff: 81(s) hard: 2400(s) soft: 1920(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=4 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=3937909676(0xeab7bbac) reqid=0(0x00000000) E: 3des-cbc ad286f9a a24dee00 b699626b 959bf286 9e04fa09 cd28b96b A: hmac-md5 f33a0769 9388dc38 9de6fa2e 69b1ed6f seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:08:35 2005 current: Jul 18 15:09:56 2005 diff: 81(s) hard: 2400(s) soft: 1920(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=3 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 ipcomp mode=transport spi=43530(0x0000aa0a) reqid=0(0x00000000) C: deflate seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Jul 18 15:07:44 2005 current: Jul 18 15:09:56 2005 diff: 132(s) hard: 2400(s) soft: 1920(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=2 pid=8784 refcnt=0 172.16.1.247 172.16.1.226 esp mode=transport spi=3318327712(0xc5c9a9a0) reqid=0(0x00000000) E: 3des-cbc 20253636 afe0e6f2 5724059d f3e90a50 2a8bc01f fb605f69 A: hmac-md5 c4a79b97 3cad3266 a402541b 8a8a3511 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jul 18 15:07:44 2005 current: Jul 18 15:09:56 2005 diff: 132(s) hard: 2400(s) soft: 1920(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=8784 refcnt=0 10.1.2.10 10.1.1.10 esp mode=transport spi=0(0x00000000) reqid=0(0x00000000) seq=0x00000000 replay=0 flags=0x00000000 state=larval created: Jul 18 15:09:54 2005 current: Jul 18 15:09:56 2005 diff: 2(s) hard: 30(s) soft: 0(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=0 pid=8784 refcnt=0 |
|
From: Aidas Kasparas <a.kasparas@gm...> - 2005-07-18 10:45:54
|
Marco Berizzi wrote: > Emmanuel Dreyfus wrote: > > Aidas Kasparas wrote: > > >>Joy was premature, unfortunately. > > > [Sorry for the late response.] > > No. It wasn't premature. Phase 2 is > working with complex_bundle off. > I'm not using NAT. swan and racoon > now establish the tunnel, but there > is no packet flow because racoon is > looping. However I think this another > problem and IIRC Emmanuel is keeping > an eye on it. Here is the log: > > Jul 18 11:38:27 Cocorita racoon: INFO: initiate new phase 2 negotiation: > 172.16.1.247[0]<=>172.16.1.226[0] > Jul 18 11:38:27 Cocorita racoon: ERROR: IPComp SPI size promoted from > 16bit to 32bit > Jul 18 11:38:27 Cocorita racoon: INFO: IPsec-SA established: ESP/Tunnel > 172.16.1.226->172.16.1.247 spi=48116586(0x2de336a) > Jul 18 11:38:27 Cocorita racoon: INFO: IPsec-SA established: > IPCOMP/Tunnel 172.16.1.226->172.16.1.247 spi=190470384(0xb5a58f0) It sets esp/tunnel SA into kernel instead of esp/transport, and for every outgoing packet kernel asks to "acquire" esp/transport SA. This is why racoon establishes a lot of them. I'm attaching diff which tries to address that problem (note, it's work in progress, needs cleanup, do not address remote->local SAs, so use it only if you're brave enought). If you'll succeed to send ping packet from local network to the remote network, I'll know I'm on the right way. [I developed that behind NAT not in my control + used not sufficient racoon.conf => may be was too pesimistic] "Morning is clever than evening!" -- Aidas Kasparas IT administrator GM Consult Group, UAB |
|
From: V <vejas@ne...> - 2005-07-18 10:11:53
|
> F. Senault <fred.letter@...> wrote: > >> Can't make phase2 renego work in many situations - there have been >> plenty of issues discussed on list, with various workarounds (make >> racoon renegociate first, often). Still, with cisco (see mails posted >> onlist by V <vejas@...>), for instance, I can't make it work. >> I'll try the freshest CVS on of these days, but I didn't see anything >> that would help. > > I have phase 2 rekeying working in racoon vs racoon and racoon vs Cisco > VPN client, both with HEAD and 0.6. Whats your config? > Hello, phase 2 renegotiation doesn't work correctly in racoon (as xauth client) vs Cisco VPN concentrator. regards, V. |
|
From: VANHULLEBUS Yvan <vanhu@fr...> - 2005-07-18 10:07:21
|
On Sun, Jul 17, 2005 at 10:04:07PM -0700, urimobile@... wrote: > > You are thinking in transport mode. > > Probably... But still... Here is a setup for a Tunnel scenario: LanA <--> GateA <========================> GateB <--> LanB So, when we have traffic from LanA to LanB, GateA will encapsulate it, send the encapsulated packet to GateB, which will decapsulate it and send it to the correct host on LanB. And vice versa. Note that GateA and GateB's IPs are probably NOT on (resp.) LanA and LanB. When negociating, each gate will know peer's Gate IP address (at least in the IP header of each Isakmp message) and peer's Lan network (during the quick mode, it's a part of the negociation). And that's enough when generating policies with racoon. Now, let's set up some NAT on the way: LanA <--> GateA <== NatA =================== NatB ==> GateB <--> LanB Now, during the negociation, each Gate will still have the peer's Lan network, but will have peer's NATed address for peer's gate. But we just don't care, because this NATed address is the address to which we'll send Isakmp messages and ESP/UDP encapsulated traffic. We have a traffic profile to check for packets to encrypt, and an IP to send the packets to. If this IP address is the address of a NAT device and not the real address of the peer Gate, we just don't care about that, it's a problem for the peer NAT device, it's it's job ! Detecting NAT on the way and doing some UDP encapsulation here is hust to help the NAT device doing this job ! > > In tunnel mode, SPDs have the traffic policy and the tunnel endpoints, > > which are distinct. > > Yes. But if the tunnel is from behind a NAT on both ends, the peers > may not know each other original addresses, and even if they did - > it wouldn't help them because those addresses are non-accessible and > non-routable from outside the NAT. And applications will have to use > NAT-ed peer addresses rather than the original ones - otherwise > their packets won't get there. Traffic addresses in Tunnel mode don't care about Tunnel endpoints. And tunnel endpoints don't care if the remote Tunnel IP is the address of the gate of the address of a NAT device, as I just explained upper. > > The traffic policy is negociated in the quick mode (with or without > > NAT-T), and the remote tunnel endpoint is "the addres we can see", > > But NAT adds crucial difference: with NAT you don't know the correct > IP address of the peer in advance (so you cannot pre-load the > appropriate policy). You know "the address you use to contact the peer", which is enough to contact peer's gate, and "the traffic to encrypt", which has nothing to do with the NAT on the way, it's just a encrypted and encapsulated payload for the NAT device. > I'm confused - I don't see how IPsec mode (transport or tunnel) can > possibly make any difference on what IP addresses we put in the SPD > for IPsec SA end-points. In Tunnel mode, you have to make difference between "tunnel endpoints" and "traffic endpoints". > > and we don't care if this is not the real address of the remote > > IPSec gate, this is the address we use to contact it, > > and we don't need any more informations. > > First, my main confusion is on the use of our own IP > address. Because in the phase2 (isakmp_quick) the Initiator uses our > NAT-ed address in negotiation, but we must put our original IP > address in SPD entry. It doesn't matter whether it's tunnel or > transport end-point. In tunnel mode, during the quick mode, one of the payloads contains "the traffic to encrypt with this SA", which has nothing to do with Gate's IP addresses ! And this is this payload which is used as the traffic's values of the generated SPD. > Second - we can contact the NAT-ed peer only using its NAT-ed > address (not its original address), again regardless of whether it's > tunnel or transport. Yep. > Perhaps you could draw a quick diagram with two peers, each behind a > NAT, illustrating how SPD would be different for Tunnel and > Transport? I'm very bad in ASCII drawing, hope this mail helped you understanding Tunnel mode. I wanted to do a quick howto or FAQ for IPSec for a long time, but I don't have much time for that, and I'm as bad with HTML than with ASCII drawings...... > Let's assume that Responder knows nothing except his own address > 1.2.3.8 (and certificate authority :-). Initiator knows his IP > address 1.2.3.4, and Responder's public IP address 11.0.0.2 > (otherwise there's no way Initiator can contact the Responder). > > Host A > Initiator <-----------> NATi <------- > 1.2.3.4 1.2.3.254 - 10.0.0.1 > > Host B > -------> NATr <----------> Responder > 11.0.0.2 - 1.2.3.254 1.2.3.8 > > Responder (host B) runs Racoon. How would it generate SPD (and SAD) > entries for IPsec between A and B for Transport mode and for Tunnel > mode? What would those SPD entries look like? Once again, you don't make the difference between Tunnel endpoints (the ones that you are talking about) and Traffic endpoints, which are missing in your scenario, but MUST be present for a Tunnel setup. Yvan. |
|
From: Marco Berizzi <pupilla@ho...> - 2005-07-18 09:46:19
|
Emmanuel Dreyfus wrote:
Aidas Kasparas wrote:
> Joy was premature, unfortunately.
[Sorry for the late response.]
No. It wasn't premature. Phase 2 is
working with complex_bundle off.
I'm not using NAT. swan and racoon
now establish the tunnel, but there
is no packet flow because racoon is
looping. However I think this another
problem and IIRC Emmanuel is keeping
an eye on it. Here is the log:
Jul 18 11:38:27 Cocorita racoon: INFO: initiate new phase 2 negotiation:
172.16.1.247[0]<=>172.16.1.226[0]
Jul 18 11:38:27 Cocorita racoon: ERROR: IPComp SPI size promoted from
16bit to 32bit
Jul 18 11:38:27 Cocorita racoon: INFO: IPsec-SA established: ESP/Tunnel
172.16.1.226->172.16.1.247 spi=48116586(0x2de336a)
Jul 18 11:38:27 Cocorita racoon: INFO: IPsec-SA established:
IPCOMP/Tunnel 172.16.1.226->172.16.1.247 spi=190470384(0xb5a58f0)
Jul 18 11:38:27 Cocorita racoon: INFO: IPsec-SA established: ESP/Tunnel
172.16.1.247->172.16.1.226 spi=1210726861(0x482a39cd)
Jul 18 11:38:27 Cocorita racoon: INFO: IPsec-SA established:
IPCOMP/Tunnel 172.16.1.247->172.16.1.226 spi=59531(0xe88b)
Jul 18 11:38:28 Cocorita racoon: INFO: initiate new phase 2 negotiation:
172.16.1.247[0]<=>172.16.1.226[0]
Jul 18 11:38:28 Cocorita racoon: ERROR: IPComp SPI size promoted from
16bit to 32bit
Jul 18 11:38:28 Cocorita racoon: INFO: IPsec-SA established: ESP/Tunnel
172.16.1.226->172.16.1.247 spi=256647086(0xf4c1fae)
Jul 18 11:38:28 Cocorita racoon: INFO: IPsec-SA established:
IPCOMP/Tunnel 172.16.1.226->172.16.1.247 spi=3797126570(0xe2538daa)
Jul 18 11:38:28 Cocorita racoon: INFO: IPsec-SA established: ESP/Tunnel
172.16.1.247->172.16.1.226 spi=3611043378(0xd73c2632)
Jul 18 11:38:28 Cocorita racoon: INFO: IPsec-SA established:
IPCOMP/Tunnel 172.16.1.247->172.16.1.226 spi=30895(0x78af)
Jul 18 11:38:28 Cocorita racoon: INFO: initiate new phase 2 negotiation:
172.16.1.247[0]<=>172.16.1.226[0]
Jul 18 11:38:28 Cocorita racoon: ERROR: IPComp SPI size promoted from
16bit to 32bit
Jul 18 11:38:28 Cocorita racoon: INFO: IPsec-SA established: ESP/Tunnel
172.16.1.226->172.16.1.247 spi=230881302(0xdc2f816)
Jul 18 11:38:28 Cocorita racoon: INFO: IPsec-SA established:
IPCOMP/Tunnel 172.16.1.226->172.16.1.247 spi=2325077802(0x8a95df2a)
Jul 18 11:38:28 Cocorita racoon: INFO: IPsec-SA established: ESP/Tunnel
172.16.1.247->172.16.1.226 spi=4079732212(0xf32bc5f4)
Jul 18 11:38:28 Cocorita racoon: INFO: IPsec-SA established:
IPCOMP/Tunnel 172.16.1.247->172.16.1.226 spi=53387(0xd08b)
Jul 18 11:38:42 Cocorita racoon: INFO: initiate new phase 2 negotiation:
172.16.1.247[0]<=>172.16.1.226[0]
Jul 18 11:38:42 Cocorita racoon: ERROR: IPComp SPI size promoted from
16bit to 32bit
Jul 18 11:38:42 Cocorita racoon: INFO: IPsec-SA established: ESP/Tunnel
172.16.1.226->172.16.1.247 spi=65190624(0x3e2bae0)
Jul 18 11:38:42 Cocorita racoon: INFO: IPsec-SA established:
IPCOMP/Tunnel 172.16.1.226->172.16.1.247 spi=961593218(0x3950bf82)
Jul 18 11:38:42 Cocorita racoon: INFO: IPsec-SA established: ESP/Tunnel
172.16.1.247->172.16.1.226 spi=3287680518(0xc3f60606)
Jul 18 11:38:42 Cocorita racoon: INFO: IPsec-SA established:
IPCOMP/Tunnel 172.16.1.247->172.16.1.226 spi=16724(0x4154)
Here is my setkey file:
spdadd 10.1.2.0/24 10.1.1.0/24 any -P out ipsec
ipcomp/tunnel/172.16.1.247-172.16.1.226/use
esp/transport//require;
spdadd 10.1.1.0/24 10.1.2.0/24 any -P in ipsec
ipcomp/tunnel/172.16.1.226-172.16.1.247/use
esp/transport//require;
Ohh... Same behaviour with
racoon 0.5.2 and 0.6.0
|
|
From: VANHULLEBUS Yvan <vanhu@fr...> - 2005-07-18 09:10:19
|
On Mon, Jul 18, 2005 at 09:44:36AM +0100, Martin Algesten wrote: > > On 18 Jul 2005, at 09:32, Emmanuel Dreyfus wrote: > > >Not sure. Give it a try? > >Maybe it could be possible to get interoperability with Apple's > >implementation if we knew the nature of the problem? > > I read it here: > http://www.jacco2.dds.nl/networking/freeswan-panther.html#NAT-Traversal > > Seems to boil down to: > > - Mac OS X sends the non-standard vendor ID string "draft-ietf-ipsec- > nat-t-ike" instead of "RFC 3947" Well.. When they made their implementation, the RFC was NOT published. They used the latest available RFC, for which the string to hash was "RFCXXXX" (it was a "pre-rfc" draft). > - implemented draft version 8 of the NAT-T... not the final > version... uses invalid numbers which are already allocated by IANA Yep. At least, they could easily report my patches to their implementation, I already sent them links to them (and everybody can find them on KAME's mailing lists). I'll send again a post to Apple's developpers to see if we can do "something" to at least improve NAT-T interoperability. Yvan. |
|
From: VANHULLEBUS Yvan <vanhu@fr...> - 2005-07-18 08:50:29
|
On Mon, Jul 18, 2005 at 09:30:48AM +0100, Martin Algesten wrote: > > On 18 Jul 2005, at 09:20, Emmanuel Dreyfus wrote: > > >Use nat_traversal force in the remote section. That will produce ESP > >over UDP traffic that may have more chances to get through. > > Our road warriors are Mac OS X laptops. I read somewhere that Apple > implemented a different nat-t spec than the rest of the world which > doesn't interoperate. Is that right? No. Apple's guys have another NAT-T implementation than ipsec-tool's one. I worked on their code, made a FreeBSD port, some fixes and some ehancements, and never noticed specific interoperability problems. The only problem I know with the first version of their implementation was that they only supported recent NAT-T drafts, which shlould not be implemented (problem with IANA numbers). This is one of the ehancements I made on their code, I sent them the modifications but I don't know if they reported them in their code. I also had a recent discussion with some Apple's developpers to see if we could work together to migrate their racoon / NAT-T support to ipsec-tools version, but nothing has yet been decided. Yvan. |
|
From: Martin Algesten <spamnow@ma...> - 2005-07-18 08:44:45
|
On 18 Jul 2005, at 09:32, Emmanuel Dreyfus wrote: > Not sure. Give it a try? > Maybe it could be possible to get interoperability with Apple's > implementation if we knew the nature of the problem? I read it here: http://www.jacco2.dds.nl/networking/freeswan-panther.html#NAT-Traversal Seems to boil down to: - Mac OS X sends the non-standard vendor ID string "draft-ietf-ipsec- nat-t-ike" instead of "RFC 3947" - implemented draft version 8 of the NAT-T... not the final version... uses invalid numbers which are already allocated by IANA Martin |
|
From: Martin Algesten <spamnow@ma...> - 2005-07-18 08:30:55
|
On 18 Jul 2005, at 09:20, Emmanuel Dreyfus wrote: > Use nat_traversal force in the remote section. That will produce ESP > over UDP traffic that may have more chances to get through. Our road warriors are Mac OS X laptops. I read somewhere that Apple implemented a different nat-t spec than the rest of the world which doesn't interoperate. Is that right? Martin |
|
From: Emmanuel Dreyfus <manu@ne...> - 2005-07-18 08:20:48
|
On Mon, Jul 18, 2005 at 09:12:40AM +0100, Martin Algesten wrote: > I've now moved away from doing roadwarriors VPN using IPSEC (not only > because of this bug, but also that I can't get ESP traffic through > Vodafone GPRS), Use nat_traversal force in the remote section. That will produce ESP over UDP traffic that may have more chances to get through. > which leaves IPSEC only between fixed IP tunnel > endpoints where I don't need to generate SP anyway. > > The bug is most likely in the Linux kernel - do you have a contact in > the kernel team for this? No, I don't know who is developing the Linux kernel. > Is Yvan your Linux guy or who is maintaining that part of the code in > ipsec? Yvan is a FreeBSD person. Aidas and Michal use Linux, AFAIK -- Emmanuel Dreyfus manu@... |
|
From: Martin Algesten <spamnow@ma...> - 2005-07-18 08:12:46
|
On 18 Jul 2005, at 08:00, Emmanuel Dreyfus wrote: > Hum, that's Linux specific. I'm not sure I can help you here... > > Does it get better with longet IPsec SA lifetime? Well, not really. I reckon it's an 80% chance to go wrong whenever the renegotiation happens, no matter how long the lifetime. 8 hour lifetime just means 8 hours VPN down now and then. I've now moved away from doing roadwarriors VPN using IPSEC (not only because of this bug, but also that I can't get ESP traffic through Vodafone GPRS), which leaves IPSEC only between fixed IP tunnel endpoints where I don't need to generate SP anyway. The bug is most likely in the Linux kernel - do you have a contact in the kernel team for this? Is Yvan your Linux guy or who is maintaining that part of the code in ipsec? Martin |
|
From: VANHULLEBUS Yvan <vanhu@fr...> - 2005-07-18 07:49:57
|
On Sun, Jul 17, 2005 at 10:10:46PM +0200, Emmanuel Dreyfus wrote: > VANHULLEBUS Yvan <vanhu@...> wrote: > > > - No distinction between tunnel and transport mode. As I explained in > > other mails, the actual (in the CVS) code is good for tunnel mode, > > and MUST be kept (or replaced by some other better code which does > > the same thing). > > Yes, please don't break it, it took me a long time to get everything > working with multiple peers behind the NAT. I'll verify that Tunnel mode won't be broken before any commit :-) > General question for NAT-T in transport mode: it won't require kernel > tweaks? I'd be surprised if we didn't have to hold the OA in the SPD and > SAD. > > As I understand, the OA is the key enabling the remote peer to > distinguish different peers behind the NAT in transport mode, just like > the internal address do that in tunnel mode. Just ignoring the NAT-OA, whis it what the actual patch does, will "only" make things works on tunnel negociations with some "exotic" Isakmp peers (which will send NAT-OA payloads for Tunnel mode, where they "SHOULD NOT" send them). In transport mode, NAT-OAir will have to be correctly generated by both peers, and will have to be sent to the IPSec stacks to correct the AH checksums. Yvan. |
|
From: VANHULLEBUS Yvan <vanhu@fr...> - 2005-07-18 07:42:52
|
On Sun, Jul 17, 2005 at 10:31:33PM +0200, F. Senault wrote: > Saturday, July 16, 2005, 12:17:39 AM, Emmanuel Dreyfus wrote: [scripts] > Or a unique script that would take the mode of operation (the keywords > you proposed) as an argument (à la rc scripts with start, stop). Yep, it can be cleaner, at least in the racoon source / structs. And your other mail is right: with such a lot of events, we'll have to set up an order, document it, and ensure that a call is done before doing the next one.... And we'll have to warn everybody about long scripts calls and the problems that may cause !! Yvan. |
|
From: <manu@ne...> - 2005-07-18 07:00:09
|
Martin Algesten <spamnow@...> wrote: > Sure, here's two emails I sent to the list which describes the issue. > The lifetime is deliberately set to very low to provoke the problem. > It happens with longer lifetimes as well. Hum, that's Linux specific. I'm not sure I can help you here... Does it get better with longet IPsec SA lifetime? --=20 Emmanuel Dreyfus Un bouquin en fran=E7ais sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php manu@... |
|
From: Martin Algesten <spamnow@ma...> - 2005-07-18 06:47:23
|
On 17 Jul 2005, at 22:34, Emmanuel Dreyfus wrote: >> There's still the issue with auto generated SP not being updated in >> an orderly fashion on Linux. >> > > Could you develop? > Sure, here's two emails I sent to the list which describes the issue. The lifetime is deliberately set to very low to provoke the problem. It happens with longer lifetimes as well. 22nd of July: > I believe I've found a reproducible problem with racoon and auto > generated policies. > > I came across this when trying to create a VPN for roadwarriors. > > The configuration is (in words): > > Roadwarrior: > - Set a SPD that requires esp/tunnel in and out to the VPN-gw. > - Configured racoon with sainfo section having a lifetime of 30 > seconds. > > VPN-GW: > - Configured racoon with generating policies and passive. > > I start the VPN with a ping to the VPN-GW and it comes up fine. I > keep the ping going - and after 30 seconds there is an expected > renegotiation of phase 2. Sometimes this works fine, and the ping > keeps going, sometimes the ping stops (it might start again after > another 30 seconds). > > The log outputs from racoon does not seem to indicate that anything > has gone wrong (a successful renegotiation looks the same as a > broken one). However I can see that the auto generated policy on > the VPN-GW disappears when it stops working. > > I have made a more in-depth analysis of the problem on my blog, > where I show the configuration files and log output: > http://algesten.blogspot.com/#111943350461748012 My post on the 2nd of July: > I think I've got closer to identifying the problem I encounter. And > I have a sort of workaround/fix. > > What seems to happen is that around row 1660 in isakmp_quick.c > (ipsec-tools v. 0.5.2) the call pk_sendspdupdate2() is done (which > in turn does a SADB_X_SPDUPDATE to the kernel). > > It looks like the kernel get these updates wrong, and after > isakmp_quick.c has made updates to all three generated policies (in/ > out/fwd) - it ends up with none of them. > > The workaround is to do a pk_sendspddelete() before doing the > pk_sendspdupdate2() for all three policies. This is probably to be > considered a hack rather than a fix since the real problem is > either the message to the kernel or the kernel itself. > > I'm happy to take a pointer on what to do next. Thanks, Martin |
|
From: <urimobile@op...> - 2005-07-18 05:04:41
|
> You are thinking in transport mode.
Probably... But still...
> In tunnel mode, SPDs have the traffic policy and the tunnel endpoints,
> which are distinct.
Yes. But if the tunnel is from behind a NAT on both ends, the peers may not know each other original addresses, and even if they did - it wouldn't help them because those addresses are non-accessible and non-routable from outside the NAT. And applications will have to use NAT-ed peer addresses rather than the original ones - otherwise their packets won't get there.
> The traffic policy is negociated in the quick mode (with or without
> NAT-T), and the remote tunnel endpoint is "the addres we can see",
But NAT adds crucial difference: with NAT you don't know the correct IP address of the peer in advance (so you cannot pre-load the appropriate policy).
I'm confused - I don't see how IPsec mode (transport or tunnel) can possibly make any difference on what IP addresses we put in the SPD for IPsec SA end-points.
> and we don't care if this is not the real address of the remote
> IPSec gate, this is the address we use to contact it,
> and we don't need any more informations.
First, my main confusion is on the use of our own IP address. Because in the phase2 (isakmp_quick) the Initiator uses our NAT-ed address in negotiation, but we must put our original IP address in SPD entry. It doesn't matter whether it's tunnel or transport end-point.
Second - we can contact the NAT-ed peer only using its NAT-ed address (not its original address), again regardless of whether it's tunnel or transport.
Perhaps you could draw a quick diagram with two peers, each behind a NAT, illustrating how SPD would be different for Tunnel and Transport?
Let's assume that Responder knows nothing except his own address 1.2.3.8 (and certificate authority :-). Initiator knows his IP address 1.2.3.4, and Responder's public IP address 11.0.0.2 (otherwise there's no way Initiator can contact the Responder).
Host A
Initiator <-----------> NATi <-------
1.2.3.4 1.2.3.254 - 10.0.0.1
Host B
-------> NATr <----------> Responder
11.0.0.2 - 1.2.3.254 1.2.3.8
Responder (host B) runs Racoon. How would it generate SPD (and SAD) entries for IPsec between A and B for Transport mode and for Tunnel mode? What would those SPD entries look like?
|
|
From: <urimobile@op...> - 2005-07-18 04:44:12
|
=3E =3E Proposal to retain backward compatibility=3A I keep phase1-up an= d =3E =3E phase1-down as they are now=2C and I tag them as deprecated in t= he =3E =3E documentation=2E I add the following hook scripts=3A =3E = =3E =3E isakmp-up called after establishing an ISAKMP SA =3E =3E isakmp-down called after deleting an ISAKMP SA =3E =3E xauth-up called after a successful Xauth exchange =3E =3E cfg-up called after ISAKMP mode config info is received/sen= t =3E =3E cfg-down called after releasing an ISAKMP mode config state =3E =3E xauth-down synonym for cfg-down = =3E =3E ipsec-up called after establishing an IPsec SA = =3E =3E ipsec-down called after deleting an IPsec SA =3E =3E racoon-exit called before exitting racoon =3E = =3E Or a unique script that would take the mode of operation (the keywor= ds =3E you proposed) as an argument (=E0 la rc scripts with start=2C stop)=2E= And among the parameters - all the IP addresses (original and NAT-ed IP = addresses for both Initiator and Responder)=2C ports (both from the orig= inal request=2C and floated by NAT)=2C operation mode (tunnel or transpo= rt)=2C policy generation flag (whether =22generate=5Fpolicy=22 is on or = off)=2E=2E=2E This would make dealing with policies so much easier=2E=2E= =2E =5BIn other words=2C make the amount of info/parameters known to t= his script as exhaustive as possible/feasible=2E It is OK if for some in= vokations some parameters aren=27t set/available=2E=5D = =3E I think it would be easier to maintain (all the variables = =3E processing and =3E information gathering about the system as we see it in the current =3E scripts could be nicely put once=2C in functions if needed=2C etc) e= t to =3E expand (just call the script with a new keyword=2C it won=27t break = other =3E correctly designed scripts)=2E Yes=2C a very good idea=2E |
|
From: <urimobile@op...> - 2005-07-18 03:37:14
|
> - struct isakmp_nat_oa should include an explicit field for the > effective payload (the address). And this should be used > "somewhere" :-) The place to use it is (a) parsing NAT-OA, and (b) generating NAT-OA for Initiator mode. > - As responder, we can NOT copy initiator's NAT-OAi and NAT-OAr, we > HAVE to generate our owns (we may also be behind a NAT device !). I think we can - because NAT-OA must contain *original* IP addresses of both. So even if we generate our own NAT-OA pair - it must look exactly the same as the pair we received. Consider it to be a token of identification [of a particular IPsec flow]. |
|
From: <urimobile@op...> - 2005-07-18 03:10:52
|
> > - No distinction between tunnel and transport mode. As I > explained in > > other mails, the actual (in the CVS) code is good for tunnel mode, > > and MUST be kept (or replaced by some other better code which does > > the same thing). > > Yes, please don't break it, it took me a long time to get everything > working with multiple peers behind the NAT. The only reason that check isn't there now is - I don't know how to check for it! It should take a one-line of C code in the "if( .... NAT_DETECTED_ME)" statement. > General question for NAT-T in transport mode: it won't require kernel > tweaks? No it doesn't require any kernel tweaks (so far :-). Until you want to support multiple peers behind the OPPOSITE NAT (not your NAT). And support for that can be added by somebody else later on. :-) > I'd be surprised if we didn't have to hold the OA in the > SPD and SAD. My patch changes the request for SPD entry creation, by substituting NATY-ed address with the original address of the Responder. Nothing else is necessary, IMHO. > As I understand, the OA is the key enabling the remote peer to > distinguish different peers behind the NAT in transport mode, just > like the internal address do that in tunnel mode. Yes. But at this time I'm happy to get it working for just one peer behind the opposite NAT, and for that you don't REALLY need to parse/use NAT-OA. |
|
From: <urimobile@op...> - 2005-07-18 03:04:38
|
> I just made a *quick* review of your patch. > > Actually, we can NOT include it in the repository, as it would break > some things in Tunnel mode. > > I'll try to take some time to integrate a modified version of your > patch asap. If you want, and if you have more time than me to work on > that (and it looks like !) you can contact me in private, or we can > continue to discuss on this list to the actual problems, and the > potential solutions, to help you making a commitable patchset. I'm happy to let you modify the patch and integrate it. > Really quick review of problems I saw: > > - Some other cleanups not related to NAT-OA mode (it's interesting to > report them, but I would like to do clean commits for each > fix/feature/cleanup). Not really related to my patch. I thought it's about time to do, so I did it. Since it's unnecessary for the correct performance of the patch - feel free to ignore them. > - No distinction between tunnel and transport mode. As I explained in > other mails, the actual (in the CVS) code is good for tunnel mode, > and MUST be kept (or replaced by some other better code which does > the same thing). Yes, I simply didn't know how to figure out in the code whether it's tunnel or transport mode. So if you know how - just add this condition to the "if()" statement. It should be enough. > - struct isakmp_nat_oa should include an explicit field for the > effective payload (the address). And this should be used > "somewhere" :-) Well, again - I don't really understand the inner working of Racoon, so do feel free to correct me here! > - As responder, we can NOT copy initiator's NAT-OAi and NAT-OAr, we > HAVE to generate our owns (we may also be behind a NAT device !). Not relevant to my patch - as it doesn't process NAT-OA (because my uderstanding of Racoon code is limited, so I didn't figure out how to properly process the NAT-OA, nor how to generate them). > - ISAKMP_NPTYPE_NATOA_* are not really parsed... well, I guess we > could do a fist step by adding the code which ignore those payloads, > and optionnaly logs that.... Hmm... My patch *is* doing exactly that currently - it ignores those payloads, because the Responder in Transport mode doesn't need to know the original address of the Initiator, and the Responder darn well knows his own (pre-NAT) address anyway. And all it's really necessary for is policy (SPD entry) generation. So please review my patch again, add the checks for Tunnel mode in two places (where it checks for NAT_DETECTED_ME), and IMHO that's it. Parsing NAT-OA would be very nice to add. |