Nigel Metheringham
2005-08-16 14:45:34 UTC
I'm using openswan 2.3.1 on a 2.6.9-11.EL (thats a Centos 4.1/RHEL 4.1)
kernel.
I would prefer to use netkey (kernel native ipsec) rather than klips if
possible to keep the maintenance load down (having to generate kernel
modules every time there is a kernel update could be problematic).
However if anyone can make a good case for using klips over netkey I'd
be interested in hearing the details.
With netkey it appears pretty hard to work out how to handle firewalling
on the ipsec gateway, and it seems rather poorly documented.
This is what I have found/googled/deduced so far - I'd appreciate it if
anyone could comment on this - any inaccuracies or items I have missed
etc. I'll mash it into the wiki in a few days if people are happy with
it.
Incoming IPSec packets
----------------------
[ie coming in as encrypted ipsec packets, with a final destination of
the local box or a network behind the local box]
* Appear on normal INPUT firewall in their encapsulated form (ie
proto ESP, src/dest are the gateway ip addresses.
* Have magic de-encryption applied
* Appear on normal INPUT/FORWARD firewall (as appropriate) in
de-encapsulated form with original src/dest/proto/port. The
input interface is set to the physical interface the encrypted
packet came in on.
This double appearance and difficulty in telling traffic that has some
in through the tunnel and traffic that has sneaked round is a problem.
The suggested solution is to use the iptables mark facility, for
example:-
iptables -t mangle -A INPUT --proto esp -j mark --set-mark 1
This mark stays with the packet after decryption, so any non-esp packets
hitting the INPUT firewall with the mark set have been through the
tunnel.
Outgoing IPSec Packets
----------------------
[ie being sent from the local box, or from another box in clear,
encrypted on this box, and sent on]
* Unencrypted packet appears on OUTPUT/FORWARD iptable (as
appropriate)
* Magic encryption happens
* The packet goes through the mangle/POSTROUTING table as an
encrypted lump.
It therefore looks like it would be possible to do some protective work
in the POSTROUTING table (maybe with some mark magic elsewhere) to make
sure you do not leak unencrypted traffic.
[The packet is not seen on the standard OUTPUT chain - which is a
strange asymmetry]
Any references to articles and people that have worked through this pain
would be helpful :-)
Nigel.
kernel.
I would prefer to use netkey (kernel native ipsec) rather than klips if
possible to keep the maintenance load down (having to generate kernel
modules every time there is a kernel update could be problematic).
However if anyone can make a good case for using klips over netkey I'd
be interested in hearing the details.
With netkey it appears pretty hard to work out how to handle firewalling
on the ipsec gateway, and it seems rather poorly documented.
This is what I have found/googled/deduced so far - I'd appreciate it if
anyone could comment on this - any inaccuracies or items I have missed
etc. I'll mash it into the wiki in a few days if people are happy with
it.
Incoming IPSec packets
----------------------
[ie coming in as encrypted ipsec packets, with a final destination of
the local box or a network behind the local box]
* Appear on normal INPUT firewall in their encapsulated form (ie
proto ESP, src/dest are the gateway ip addresses.
* Have magic de-encryption applied
* Appear on normal INPUT/FORWARD firewall (as appropriate) in
de-encapsulated form with original src/dest/proto/port. The
input interface is set to the physical interface the encrypted
packet came in on.
This double appearance and difficulty in telling traffic that has some
in through the tunnel and traffic that has sneaked round is a problem.
The suggested solution is to use the iptables mark facility, for
example:-
iptables -t mangle -A INPUT --proto esp -j mark --set-mark 1
This mark stays with the packet after decryption, so any non-esp packets
hitting the INPUT firewall with the mark set have been through the
tunnel.
Outgoing IPSec Packets
----------------------
[ie being sent from the local box, or from another box in clear,
encrypted on this box, and sent on]
* Unencrypted packet appears on OUTPUT/FORWARD iptable (as
appropriate)
* Magic encryption happens
* The packet goes through the mangle/POSTROUTING table as an
encrypted lump.
It therefore looks like it would be possible to do some protective work
in the POSTROUTING table (maybe with some mark magic elsewhere) to make
sure you do not leak unencrypted traffic.
[The packet is not seen on the standard OUTPUT chain - which is a
strange asymmetry]
Any references to articles and people that have worked through this pain
would be helpful :-)
Nigel.
--
[ Nigel Metheringham ***@InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
[ Nigel Metheringham ***@InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]