Alright, it seems as though we now have a proper handshake and connection between the two locations.  Unfortunately, I can&#39;t get any packets/traffic sent from one side to another.  Any requests don&#39;t seem to even be hitting the client firewall, even though the connection goes through.  So, let me start with a basic clarification:<div>
<br></div><div>When we set up the connection, the request to the client came from 10.5.5.5 (the created encrypted domain), and not the elastic(static) ip.  Should the firewall rules on the client side been setup for 10.5.5.5 and not the elastic ip? </div>
<div><br></div><div>I think the original expectation was that the traffic would be coming from the Elastic IP, and that&#39;s what was configured on the client end.  </div><div><br></div><div>Otherwise, from the auth.log:</div>
<div><br></div><div><div>pluto[7676]: NAT-Traversal: Trying new style NAT-T</div><div>pluto[7676]: NAT-Traversal: ESPINUDP(1) setup failed for new style NAT-T family IPv4 (errno=19)</div><div>pluto[7676]: NAT-Traversal: Trying old style NAT-T</div>
</div><div><br></div><div>Is the NAT-T not functioning properly, or is this fine?  </div><div><br></div><div>Finally, any reason why there seems to be no traffic getting through to the client firewall?  UDP ports are set up properly through the AWS security groups.  </div>
<div><br></div><div>-James</div><div><br></div><div><br><div class="gmail_quote">On Fri, Sep 9, 2011 at 3:21 PM, Paul Wouters <span dir="ltr">&lt;<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Fri, 9 Sep 2011, James Nelson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hopefully this doesn&#39;t cause a new thread.  If so, I apologize for spamming the group.  I found something that I&#39;m not liking at<br>
the moment with a simple ipsec whack --status.  My questions are simply:<br>
1) Are these algorithms compatible/consistent?<br>
2) If not, what does my ike and phase2alg variables have to be set at?<br>
<br>
000 &quot;ec2check&quot;:   IKE algorithms wanted: 3DES_CBC(5)_000-MD5(1)-<u></u>MODP1536(5), 3DES_CBC(5)_000-MD5(1)-<u></u>MODP1024(2); flags=-strict<br>
000 &quot;ec2check&quot;:   IKE algorithms found:  3DES_CBC(5)_192-MD5(1)_128-5, 3DES_CBC(5)_192-MD5(1)_128-2,<br>
000 &quot;ec2check&quot;:   ESP algorithms wanted: 3DES(3)_000-MD5(1); flags=-strict<br>
000 &quot;ec2check&quot;:   ESP algorithms loaded: 3DES(3)_192-MD5(1)_128<br>
</blockquote>
<br></div>
The repsentatations are a bit odd with &quot;000&quot; meaning &quot;any sane length&quot;.<br>
So yes, this is a proper match.<br><font color="#888888">
<br>
Paul<br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>-----------------------<br>James Nelson II<br>630-334-0177<br><a href="mailto:james.nelson.ii@gmail.com">james.nelson.ii@gmail.com</a><br>
</div>