Re: IPsec NETKEY firewalling

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2012-02-20 at 00:14 +0100, Niccolò Belli wrote:
> Hi LARTC, hopefully this is the kind of question this list should be 
> suited for :)
> I want to use the NETKEY IPsec stack and put the firewall in the same 
> machine running Openswan/Strongswan. I'm starting to look how it hooks 
> in the netfilter chain and any help (including links to 
> documentation/howtos) is appreciated.
> 
> Incoming packets are received encrypted in the physical interface and 
> then "magically" appear in decrypted form, so firewalling isn't as easy 
> as matching an ipsecX interface like with the KLIPS stack. I thought 
> about marking esp packets at first to be able to recognize them later in 
> decrypted form to do appropriate matching: is there any other way to do 
> it? I already use tons of marks and mark masks :(
> 
> The biggest issue is with outgoing packets, for some reason they seem to 
> appear only in encrypted form, so there is no way to do any kind of 
> matching... How to achieve firewalling for outgoing packets then?
<snip>
Hi, Niccolo.  This is a very important issue to us.  For years, we have
been working in developing a technology we call Firepipes to replace
Firewalls which allows us to condense hundreds of thousands of iptables
rules into dozens of order independent policies so we can implement
highly granular network security without a huge administrative overhead.
One of the interesting side effects is that the entire Firepipe cloud
becomes aware of every user authentication anywhere in the cloud with
virtually no background network traffic.  A key to doing this is to
identify VPN traffic in iptables including netkey, KLIPS, and OpenVPN.

Our preferred way of doing this is with packet marking.  It's a little
simpler for us in that one of the foundational principles of firepiping
is that we make the access control decision at the point of ingress to
the cloud and not the point of egress, i.e., by the firewall protecting
the Accessor and not the firewall protecting the Resource.  We catch the
outbound packets on the FORWARD or OUTPUT chains, make an access control
decision and the other side doesn't need to worry about it other than to
know the traffic came on an authenticated tunnel.  On the receiving
side, we need to know that the decrypted packet came from a trusted VPN
connection, an untrusted VPN connection, or an unencrypted connection
and that is where the packet marking is used.

However, we hit a problem in our current project to firepipe enable
Endian products because they used all available marks for their policy
routing.  In that case, we needed to use the policy match.  This allowed
us to identify the decrypted packets which came from a netkey session
and send them to the appropriate chains for processing.

So, in summary, our first choice is packet marking and our second is the
policy match.  I hope that helps - John

--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux