The bug exists in 2.4.12 too.<br><br>In aggressive mode initiator uses
port 500 to generate the hash (because the packet was received on 500)
and sends it in NAT-D payload.<br><br>"htoh" #4: Aggressive mode peer ID is ID_IPV4_ADDR: '<a href="http://172.16.2.2/" target="_blank">172.16.2.2</a>'<br>
| _natd_hash: hasher=0x80eab00(16)<br>
| _natd_hash: icookie=<br>
| a3 87 5b b4 de d8 47 76<br>
| _natd_hash: rcookie=<br>
| 99 fc e2 0c 65 1a 3e 79<br>
| _natd_hash: ip= ac 10 02 02<br>
| _natd_hash: port=500<br>
| _natd_hash: hash= 61 47 3f 04 ef 22 98 c9 2b b1 5b 87 e3 2b f6 40<br>
<br>Responder uses 4500 to verify received hash as it has switch to 4500.<br><br>"aggr-1"[2] <a href="http://172.16.2.1/" target="_blank">172.16.2.1</a> #62: STATE_AGGR_R1: sent AR1, expecting AI2<br>| processing connection aggr-1[2] <a href="http://172.16.2.1/" target="_blank">172.16.2.1</a><br>
| _natd_hash: hasher=0x80eab00(16)<br>| _natd_hash: icookie=<br>| a3 87 5b b4 de d8 47 76<br>| _natd_hash: rcookie=<br>| 99 fc e2 0c 65 1a 3e 79<br>| _natd_hash: ip= ac 10 02 02<br>| _natd_hash: port=4500<br>| _natd_hash: hash= a7 0c 8c ed b5 b0 ed 0f 33 7d 4f 39 f1 7e d3 ee<br>
...<br>| expected NAT-D(me): a7 0c 8c ed b5 b0 ed 0f 33 7d 4f 39 f1 7e d3 ee<br>| expected NAT-D(him):<br>| a4 77 17 54 20 77 12 1f cf c2 80 ff 98 0e 51 a1<br>| received NAT-D: 61 47 3f 04 ef 22 98 c9 2b b1 5b 87 e3 2b f6 40<div class="Ih2E3d">
<br>
| NAT_TRAVERSAL hash=1 (me:0) (him:0)<br></div>...<div class="Ih2E3d"><br>| NAT_TRAVERSAL hash=2 (me:0) (him:0)<br></div>"aggr-1"[2] <a href="http://172.16.2.1/" target="_blank">172.16.2.1</a> #62: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed<br>
<br>I didn't find any help from <a href="http://tools.ietf.org/html/rfc3947" target="_blank">http://tools.ietf.org/html/rfc3947</a>.<div><span id="q_11b0d8b704db65db_5" class="WQ9l9c">- Hide quoted text -</span></div>
<br><br>Thanks for your time.<br><br>-hiren