<div dir="ltr"><span style="font-size:13px;line-height:19.5px">Hi,</span><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">I have two targets, on which I am running strongswan 5.2.2.</div><div style="font-size:13px;line-height:19.5px"><div>A single VLAN interface is configured on each . <br></div><div>A any to any protect policy exists.</div><div>IKEv2 is used.</div><div><br></div><div>Following are the lscpu details of each targets.</div><div><br></div><div><b>Target A</b></div><div><b><br></b></div><div><b><div>lscpu</div><div>Architecture:          armv7l</div><div>Byte Order:            Little Endian</div><div>CPU(s):                16</div><div>On-line CPU(s) list:   0-15</div><div>Thread(s) per core:    1</div><div>Core(s) per socket:    4</div><div>Socket(s):             4</div><div>Model name:            ARMv7 Processor rev 2 (v7l)</div></b></div><div><br></div><div><b>Target B</b></div><div><b><br></b></div><div><b><div>Architecture:          mips64</div><div>Byte Order:            Big Endian</div><div>CPU(s):                6</div><div>On-line CPU(s) list:   0-2</div><div>Off-line CPU(s) list:  3-5</div><div>Thread(s) per core:    1</div><div>Core(s) per socket:    1</div><div>Socket(s):             3</div><div>L1d cache:             32K</div><div>L1i cache:             37K</div><div>L2 cache:              2048K</div></b></div><div><br></div><div>The problem here is with Target A, which is a ARMv71, Little Endian.</div><div><br></div><div><br></div><div><div>With Target A,<span class="lG">Ike</span> <span class="lG">cookie</span> as shown in charon logs during establishment phase matches with captured trace as on tcpcump on target console or with packet trace outside the target..</div><div>But looking into ipsec satusall on target console this is really confusing, shown here in reverse order.</div><div><br></div><div>e.g. from attached charon logs:</div><div>2016-02-01T14:17:15.783770+00:00 [info]     charon:  11[<span class="lG">IKE</span>] octets = message + nonce + prf(Sk_px, IDx') = 389 bytes @ 0xad603798</div><div>2016-02-01T14:17:15.784628+00:00 [info]     charon:  11[<span class="lG">IKE</span>]    0:<b> 3A CB BB 0B 41 92 01 E0 E7 A1 EE DB BA 3F 2E E6</b>  :...A........?..</div><div><br></div><div><br></div><div> from ipsec statusall:</div><div><br></div><div>conn65535_9[3]: ESTABLISHED 5 minutes ago, 10.46.167.109[CN=yyyyyyyyy, O=zzzzzzzzzzzzz]...10.44.34.130[qwwwwwwqqwqqwqwqww]</div><div>conn65535_9[3]: IKEv2 SPIs: <b>e00192410bbbcb3a</b>_i <b>e62e3fbadbeea1e7</b>_r*, rekeying in 23 hours</div></div></div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">I don't see the problem with Target B, which is mips64 Big Endian.</div><div style="font-size:13px;line-height:19.5px">I guess the reversing has to do with Endianess?</div><div style="font-size:13px;line-height:19.5px">Is there a way I could still rectify this issue for Target A?</div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">Note: Some details about the Targets are masked with random letters. :)<br></div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">Regards</div><div style="font-size:13px;line-height:19.5px">Nanda</div></div>