<div dir="ltr">So i stopped ipsec, applied the patch, ran make programs and sudo make install, and restarted ipsec. I still get the same message about the unknown value <span style="font-size:13px">16777216</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 11, 2015 at 9:24 PM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 11 Jan 2015, Ali Gangji wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Sun, 11 Jan 2015 12:47:04<br>
004 "ner" #1: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=MODP1024}<br>
</blockquote>
<br>
So this is good. phase1 is up. Better than your phase1 errors before.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
117 "ner" #2: STATE_QUICK_I1: initiate<br>
</blockquote>
<br>
starting phase2....<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
003 "ner" #2: DOI of ISAKMP Notification Payload has an unknown value: 16777216<br>
</blockquote>
<br>
So the DOI (Domain of Interpretation) is a 4 octet value. It can either<br>
contain 0 for ISAKMP or 1 for IPsec.<br>
<br>
See: <a href="http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-19" target="_blank">http://www.iana.org/<u></u>assignments/ipsec-registry/<u></u>ipsec-registry.xhtml#ipsec-<u></u>registry-19</a><br>
<br>
So 16777216 is pretty wrong. Note that this value in hex is 0x1000000.<br>
So this makes be believe that the other end screwed up network and host<br>
order:<br>
<br>
$ python<br>
Python 2.7.5 (default, Nov 3 2014, 14:33:39) [GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux2<br>
Type "help", "copyright", "credits" or "license" for more information.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hex(16777216)<br>
</blockquote></blockquote></blockquote>
'0x1000000'<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
import socket<br>
socket.htonl(1)<br>
</blockquote></blockquote></blockquote>
16777216L<br>
<br>
So this looks like an OSX server bug. Please try the attached patch,<br>
<br>
Note this will only ignore their bad value on our end. If you reverse<br>
directions, things might still break if they don't like a real 1 and<br>
insist on 16777216.<span class="HOEnZb"><font color="#888888"><br>
<br>
Paul</font></span></blockquote></div><br></div>