[Openswan Users] Firewall rules for openswan behind NAT

[Fred Weston]

>-----Original Message-----
>From: users-bounces at lists.openswan.org [mailto:users-bounces at lists.openswan.org] On Behalf Of Neal Murphy
>Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT
>
>On Wednesday, November 20, 2013 05:14:55 PM Fred Weston wrote:
>> I don't really need it for anything and I can always unblock it if I
>> do, but the more pressing point is ANY traffic will fail to pass in
>> the current state unless I permit it through the AWS firewall.  My
>> understanding of how this should work is I should only need to allow
>> udp500, udp4500 and maybe one or two other ports into openswan from
>> the Internet, but that's not the case currently.  There has to be a
>> misconfiguration somewhere, but I just can't seem to find it.
>
>A neuron just painfully fired. I'll bet ICMP is *required* for NAT-T. From
>wikipedia:
>---------
>For IPv4 packets, Path MTU Discovery works by setting the Don't Fragment (DF) option bit in the IP headers of outgoing packets. Then, any device along the path whose MTU is smaller than the packet will drop it, and send back an Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3, Code 4) message containing its MTU, allowing the source host to reduce its Path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.
>---------

I know from other cases where I am using NAT-T that ICMP isn't required unless that is an openswan specific requirement.  I have many IOS routers with VPN tunnels behind cable routers running NAT.

>
>If you are saying that *no* traffic passes from one end to the other unless you forward their ports inbound to the destination openswan server, then I must suspect that no traffic is passing >through the tunnel (into which the outer firewalls will not and cannot see). Are you *sure* the client nodes have their routes set up correctly?

Yes, this is exactly what I'm saying.  The traceroutes confirm that the traffic is passing through the two openswan boxes, there is no other path between the two networks so the traffic *must* be traversing the tunnel.  That being said, I 100% agree with you that this makes absolutely no sense UNLESS the traffic is only being tunneled and is not being encrypted.  In that case this could make sense because the firewall might be able to see the tunneled traffic and apply its ruleset to it.  Everything seems to indicate that traffic is being encrypted though, so the firewall controlling what traffic can come into the far openswan box shouldn't be able to see any of the raw traffic, all it should see is encrypted noise.

The way AWS handles routing is a bit different than how you would normally handle it.  For instance, when I set a route for 10.1.0.0/16, I don't set an IP address as the next hop, I set a network interface which just happens to be the virtual NIC assigned to the openswan VM.  Otherwise, yes I am pretty sure the routing should not be suspect.

>
>But I'm *really* beginning to suspect the configuration of the openswan system. What type of system is it running on?
>

So am I.  It's a t1.micro instance running Amazon Linux.  Specifically, it was launched from their NAT AMI (machine image).

>Are you certain there is no other tunneling going on?

The only other thing I could think of is that since the image I'm using was purpose built for doing NAT, that perhaps there were some existing firewall rules on the openswan boxes that could be monkeying with things.  I tried to list the iptables ruleset, but it came up empty.  Since the boxes are designed to do NAT, shouldn't I see some sort of iptables rules?  Is there something other than iptables that could be in use that I should check?
The information transmitted in this message (including any attachments) is intended only for the use of the individual(s) and/or entity(ies) to which it is addressed and may contain confidential business information which should not be disclosed. If you are not the intended recipient, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error, please notify the sender and immediately destroy and delete this email from your system without disseminating it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the LPGA and/or its affiliates. No employee is authorized to conclude any binding agreement on behalf of LPGA and/or its affiliates with another party by e-mail. All agreements shall be contained in a separate writing executed by an authorized LPGA signatory. Thank You.