[Openswan Users] Iptables ESTABLISHED/RELATED

[Scott Mcdermott]

Stephen J. McCracken on Fri 18/03 21:42 -0500:
> I am somewhat new to this, and have run into a problem.  I
> am working on getting a VPN up between a Linux Firewall
> (Openswan) and a Multitech RouteFinder.  I got everything
> working with a completely open VPN (using the default
> _updown_x509 script).  Now I am trying to tighten down the
> VPN to only allow some types of traffic across the VPN.
> It seems to me that the iptables is not recognizing
> packets as established/related.
> 
> This is running on a Fedora Core 3 box with
> openswan-2.1.5-2.FC3.1 rpm. 

I don't know if you are useing KLIPS or the native PF_KEY.

but in any case...these rules may help:

1. Any traffic between gateways, included the encapsulated
traffic, are goverened by INPUT/OUTPUT, not FORWARD.  The
tunnel packets will come in from the remote end via INPUT,
be decrypted, and then re-injected into the FORWARD
rulechain after decryption, if they are not destined for the
local machine (i.e. if they are to be routed).

2. When making the FORWARD rules on the receiving end, be
aware that the rules will be traversed by the unencrypted
packets.  You should make the rules as though the tunnel
does not exist at all, and the two networks are directly
connected to the firewall (you can treat the remote end as
though it were directly connected, from the vantage of both
firewalls).

3. The FORWARD rules and routing table will only be
consulted after the packets emerge from the tunnel.

4. do not use `-i' for packets coming from the remote end
(use IP layer input matching instead of link layer, and
always use *decrypted* addresses).  The input interface for
the packets which emerge from the tunnel will always end up
appearing to be from the interface that the tunnel routes
through, so this isn't very useful.  You can still use `-o'
on the receiving end since the packets will be decrypted and
have their end destination IP address by the time you know
what the outbound interface is.  After the routing table is
consulted `-o' will then be available for matching, and
accurate.

4. do not use `-o' to match packets destined for the remote
end, for all the same reasons that you don't want to use
`-i' for packets coming in from the remote end.

5. Do not bother making outbound restrictions on the
*source* end of the tunnel.  I am not 100% certain, but I
believe the packets will come in and consult the kernel
IPSEC policies early in the process and be encrypted before
any iptables rules are consulted (read: they will never even
traverse the FORWARD chain on the source end of the tunnel).
Firewall restrictions in general should always be
implemented by the receiving end.  This means you will have
to send the packets across whether or not you will actually
forward them on once they arrive at the remote end.

6. If you want to try to restrict what goes across on the
source end, you probably need to use IPSEC policies to do
this.  For example the `setkey' man page lists the
capability to specify protocols and port ranges which are
governed by the policies.  However, it then lists a bug at
the bottom of the page that it doesn't work in tunnel mode.
In general, send everything across on an address basis, and
drop them in FORWARD on the remote end.  In general, I do
not believe using IPSEC policies to send across only certain
packets in the address range would be a well-tested or
reliable thing to try to use.  You are better off sending
with proto `any' and then rejecting in FORWARD chain on
remote end, IMO.

The combination of ipsec/iptables in kernel 2.6 works quite
well for me given the above assumptions (although I have to
use strongswan instead of openswan in order to use AES ;)