[Openswan Users] Yet Another EC2 Config Debug

[James Nelson]

Alright, it seems as though we now have a proper handshake and connection
between the two locations.  Unfortunately, I can't get any packets/traffic
sent from one side to another.  Any requests don't seem to even be hitting
the client firewall, even though the connection goes through.  So, let me
start with a basic clarification:

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?

I think the original expectation was that the traffic would be coming from
the Elastic IP, and that's what was configured on the client end.

Otherwise, from the auth.log:

pluto[7676]: NAT-Traversal: Trying new style NAT-T
pluto[7676]: NAT-Traversal: ESPINUDP(1) setup failed for new style NAT-T
family IPv4 (errno=19)
pluto[7676]: NAT-Traversal: Trying old style NAT-T

Is the NAT-T not functioning properly, or is this fine?

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.

-James


On Fri, Sep 9, 2011 at 3:21 PM, Paul Wouters <paul at xelerance.com> wrote:

> On Fri, 9 Sep 2011, James Nelson wrote:
>
>  Hopefully this doesn't cause a new thread.  If so, I apologize for
>> spamming the group.  I found something that I'm not liking at
>> the moment with a simple ipsec whack --status.  My questions are simply:
>> 1) Are these algorithms compatible/consistent?
>> 2) If not, what does my ike and phase2alg variables have to be set at?
>>
>> 000 "ec2check":   IKE algorithms wanted: 3DES_CBC(5)_000-MD5(1)-**MODP1536(5),
>> 3DES_CBC(5)_000-MD5(1)-**MODP1024(2); flags=-strict
>> 000 "ec2check":   IKE algorithms found:  3DES_CBC(5)_192-MD5(1)_128-5,
>> 3DES_CBC(5)_192-MD5(1)_128-2,
>> 000 "ec2check":   ESP algorithms wanted: 3DES(3)_000-MD5(1); flags=-strict
>> 000 "ec2check":   ESP algorithms loaded: 3DES(3)_192-MD5(1)_128
>>
>
> The repsentatations are a bit odd with "000" meaning "any sane length".
> So yes, this is a proper match.
>
> Paul
>



-- 
-----------------------
James Nelson II
630-334-0177
james.nelson.ii at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20110913/57c551f4/attachment.html