I am trying to establish IPSec SA by giving run time commands to Pluto but it fails in negotiation phase by not exchanging the certificates.

Command User on server and client side :
ipsec whack --name hello --host 192.168.54.220 --client 192.168.54.1/32 --cert Server --ca CA_auth --sendcert yes --to --host 192.168.54.221 --client 192.168.54.1/32 --cert Client --ca CA_auth --sendcert yes --rsasig --tunnel

Server and Client are the nicknames of the digital certificates in the server/client ipsec database.

[root@localhost ipsec.d]# ipsec whack --initiate --name hello
002 "hello" #1: initiating Main Mode
104 "hello" #1: STATE_MAIN_I1: initiate
003 "hello" #1: received Vendor ID payload [Dead Peer Detection]
003 "hello" #1: received Vendor ID payload [RFC 3947]
002 "hello" #1: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
002 "hello" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "hello" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "hello" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
002 "hello" #1: I am sending my cert
002 "hello" #1: I am sending a certificate request
002 "hello" #1: Not sending INITIAL_CONTACT
002 "hello" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "hello" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "hello" #1: ignoring informational payload INVALID_ID_INFORMATION, msgid=00000000, length=12
003 "hello" #1: received and ignored informational message for unknown state
003 "hello" #1: discarding duplicate packet; already STATE_MAIN_I3
010 "hello" #1: STATE_MAIN_I3: retransmission; will wait 20s for response
003 "hello" #1: ignoring informational payload INVALID_ID_INFORMATION, msgid=00000000, length=12
003 "hello" #1: received and ignored informational message for unknown state

Looks like I am missing some parameter while initiating the ipsec SA.

I'm suspicious of those INVALID_ID_INFORMATION responses. I don't know IPSec well enough to diagnose this, but I'd be looking at the logs on the other side as well as this one. It superficially looks to me like this client sent a certificate but that the other side didn't like it. I don't expect the response message to be an "informational payload" to be "ignored," but ... I do know that the IPSec stack (Raccoon and all its other rabid furry-friends) is an infernal state-machine from hell.

Also noticed on the web:

• https://lists.openswan.org/pipermail...ne/014779.html

I see references to people asking for a state-diagram of the IPSec connection negotiations, but I never yet found that anyone found one.

Anyway: IPSec is evil ook. OpenVPN is not.