[Openswan Users] Ipsec Transport Problem

[conn intel]

Hello Friends,


CLIENT behind G/W                IPSEC GATEWAY                   IPSEC HOST
|-------------------|                          |----------------|
                         |--------------|
|                        |---------------------|
  |---------------------|                  |
|         A            |                           |        B         |
                          |        C       |
|-------------------|                           |----------------|
                         |--------------|
                    eth0                       eth0
eth1
           eth0

      192.168.1.5                    192.168.1.1         10.10.100.25
10.10.100.88


I am using IPSEC KLIPS 2.6 with NAT support on Gateway B and Host C, Client
A is the normal host behind the Gateway B.. I am using type=transport in the
ipsec.conf files for both the Gateway B and Host C.

In the intial stage the tunnel is not getting up from Gateway B to HOST C,
thus not able to ping from A to C.

But I can successfully ping from Host C to Client A and then trying again
getting successfull ping response from Client A to Host C which is not there
before.

If I want to use transport mode where i can use that either on GATEWAY B or
on HOST C or on both ?

THank You.

Ankur.

BEFORE TRYING PING FROM C TO A ::

OUTPUT ON GATEWAY B :: Ipsec auto --status

000 "netone": 192.0.0.0/8===10.10.100.25...10.10.100.88---10.10.100.88;
erouted HOLD; eroute owner: #0
000 "netone":     srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec
_updown;
000 "netone":   ike_life: 3600s; ipsec_life: 3600s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0
000 "netone":   policy: PSK+ENCRYPT+COMPRESS+TUNNEL+UP+failurePASS; prio:
8,32; interface: eth1;
000 "netone":   newest ISAKMP SA: #1; newest IPsec SA: #0;
000 "netone":   IKE algorithms wanted: 3_000-1-5, 3_000-1-2, flags=strict
000 "netone":   IKE algorithms found:  3_128-1_128-5, 3_128-1_128-2,
000 "netone":   IKE algorithm newest: BLOWFISH_CBC_128-MD5-MODP1536
000 "netone":   ESP algorithms wanted: 3_000-1, flags=strict
000 "netone":   ESP algorithms loaded: 3_000-1, flags=strict
000
000 #4: "netone":500 STATE_QUICK_I1 (sent QI1, expecting QR1);
EVENT_RETRANSMIT in 2s; lastdpd=-1s(seq in:0 out:0)
000 #3: "netone":500 STATE_QUICK_I1 (sent QI1, expecting QR1);
EVENT_RETRANSMIT in 6s; lastdpd=-1s(seq in:0 out:0)
000 #1: "netone":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE
in 2973s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0)


AFTER TRYING PING FROM C TO A ::

OUTPUT ON GATEWAY B :: Ipsec auto --status

000 "netone": 192.0.0.0/8===10.10.100.25...10.10.100.88---10.10.100.88;
erouted; eroute owner: #5
000 "netone":     srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec
_updown;
000 "netone":   ike_life: 3600s; ipsec_life: 3600s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0
000 "netone":   policy: PSK+ENCRYPT+COMPRESS+TUNNEL+UP+failurePASS; prio:
8,32; interface: eth1;
000 "netone":   newest ISAKMP SA: #1; newest IPsec SA: #5;
000 "netone":   IKE algorithms wanted: 3_000-1-5, 3_000-1-2, flags=strict
000 "netone":   IKE algorithms found:  3_128-1_128-5, 3_128-1_128-2,
000 "netone":   IKE algorithm newest: BLOWFISH_CBC_128-MD5-MODP1536
000 "netone":   ESP algorithms wanted: 3_000-1, flags=strict
000 "netone":   ESP algorithms loaded: 3_000-1, flags=strict
000 "netone":   ESP algorithm newest: 3DES_0-HMAC_MD5; pfsgroup=<N/A>
000
000 #5: "netone":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE
in 3324s; newest IPSEC; eroute owner
000 #5: "netone" esp.9db7fa8 at 10.10.100.88 esp.6c5ef14f at 10.10.100.25
tun.1002 at 10.10.100.88 tun.1001 at 10.10.100.25
000 #4: "netone":500 STATE_QUICK_I1 (sent QI1, expecting QR1);
EVENT_RETRANSMIT in 24s; lastdpd=-1s(seq in:0 out:0)
000 #3: "netone":500 STATE_QUICK_I1 (sent QI1, expecting QR1);
EVENT_RETRANSMIT in 8s; lastdpd=-1s(seq in:0 out:0)
000 #1: "netone":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE
in 2935s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0)
000


b) I have used type=transport then also why in the above message it
shows policy:
PSK+ENCRYPT+COMPRESS+TUNNEL+UP+failurePASS instead of TRANSPORT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20061109/67641cfb/attachment-0001.html