[Openswan Users] Firewall rules for openswan behind NAT

[Fred Weston]

Each openswan box does only have one interface.  On that interface it has a 10.x.x.x IP address which serves as both access to the local subnet as well as Internet access via 1:1 NAT to a public IP.

-----Original Message-----
From: users-bounces at lists.openswan.org [mailto:users-bounces at lists.openswan.org] On Behalf Of Neal Murphy
Sent: Thursday, November 21, 2013 12:21 AM
To: users at openswan.org
Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT

On Wednesday, November 20, 2013 10:57:35 PM Fred Weston wrote:
> >-----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:
> ...
> >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.

All the firewall should see is UDP packets on port 4500; it shouldn't act on what's in the payload (unless it's using deep packet inspection--DPI).

>
> 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?

No, only iptables (netfilter) wrangles packets.

Wait. Does the openswan machine have only one interface? If so, you're probably well beyond my expertise; I can handle OS when it uses two NICs. If it has two, your diagram and routing are wrong.
_______________________________________________
Users at lists.openswan.org
https://lists.openswan.org/mailman/listinfo/users
Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
Building and Integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
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.