Firewalling non-IPsec connections

Firewalling non-IPsec connections

[Peter Hoeg]

Normally google is my friend but hasn't been able to help me out, which is
the reason I am turning to you guys.

Here is the deal:

I have a multipurpose gateway/firewall box (running linux kernel
2.6.0-test9) using iptables 1.2.9 (standard debian package) with 3 NICs:

eth0 - internal LAN
eth1 - WLAN (using a crossover cable into an orinoco wireless gateway)
eth2 - internet connection via adsl

For the IPsec stuff I am using the in-kernel ipsec implementation and racoon
for IKE (tunnel mode by the way).

What I want to do:

Basically, the only connections that are to be allowed as wireless
connections are IPsec tunnels, so I can ensure nobody else uses my
connection. This is pretty easy for connections to the gateway host (UDP
port 500 for IKE, ESP protocol and dhcp) as I just need to limit the INPUT
chain for eth1.

The REAL problem is since I need to allow connections from the wireless LAN
segment to go onto the internet and it seems like the connections only hit
the FORWARD chain AFTER the kernel has done all its magic with unpacking the
encrypted packages. What I would like to do is something like:

iptables -A FORWARD -i eth1 -o eth2 -p esp -j ACCEPT

and then drop everything else, but again, the problem is that if I as an
example ping www.google.com from a wireless host with the IPsec tunnel
active and having this rule:

iptables -A FORWARD -j LOG

I can then see the ICMP packages in my log for the forward chain.

I hope I have managed to explain what it is that I am looking for and that
somebody out there can help me out.

Re: Firewalling non-IPsec connections

[Arnt Karlsen]

On Sun, 14 Dec 2003 23:30:35 +0100, 
"Peter Hoeg" <disposable1@hoeg.com> wrote in message 
<000c01c3c291$e4e0f3a0$fc00000a@vmwarew2k>:

> Normally google is my friend but hasn't been able to help me out,
> which is the reason I am turning to you guys.
> 
> Here is the deal:
> 
> I have a multipurpose gateway/firewall box (running linux kernel
> 2.6.0-test9) using iptables 1.2.9 (standard debian package) with 3

..tried 2.6.0-test_11_?  
knoppix@ttyp5[knoppix]$ finger @finger.kernel.org
[zeus-pub.kernel.org]
The latest stable version of the Linux kernel is:           2.4.23
The latest prepatch for the stable Linux kernel tree is:  2.4.24-pre1
The latest snapshot for the stable Linux kernel tree is:  2.4.23-bk11
The latest beta version of the Linux kernel is:             2.6.0-test11
The latest snapshot for the beta Linux kernel tree is:   
2.6.0-test11-bk10 
The latest 2.2 version of the Linux kernel is:           2.2.25 
The latest 2.0 version of the Linux kernel is:           2.0.39 
The latest prepatch for the 2.0 Linux kernel tree is:  2.0.40-rc6 
The latest -ac patch to the stable Linux kernels is:  2.4.22-ac4 
The latest -ac patch to the beta Linux kernels is:    2.6.0-test1-ac3 
knoppix@ttyp5[knoppix]$


-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: Firewalling non-IPsec connections

[Antony Stone]

On Sunday 14 December 2003 10:30 pm, Peter Hoeg wrote:

> I have a multipurpose gateway/firewall box (running linux kernel
> 2.6.0-test9) using iptables 1.2.9 (standard debian package) with 3 NICs:
>
> eth0 - internal LAN
> eth1 - WLAN (using a crossover cable into an orinoco wireless gateway)
> eth2 - internet connection via adsl
>
> Basically, the only connections that are to be allowed as wireless
> connections are IPsec tunnels, so I can ensure nobody else uses my
> connection. This is pretty easy for connections to the gateway host (UDP
> port 500 for IKE, ESP protocol and dhcp) as I just need to limit the INPUT
> chain for eth1.
>
> The REAL problem is since I need to allow connections from the wireless LAN
> segment to go onto the internet and it seems like the connections only hit
> the FORWARD chain AFTER the kernel has done all its magic with unpacking
> the encrypted packages. What I would like to do is something like:
>
> iptables -A FORWARD -i eth1 -o eth2 -p esp -j ACCEPT
>
> and then drop everything else, but again, the problem is that if I as an
> example ping www.google.com from a wireless host with the IPsec tunnel
> active and having this rule:
>
> iptables -A FORWARD -j LOG
>
> I can then see the ICMP packages in my log for the forward chain.

I have used IPtables + FreeS/WAN a fair amount, and I created a diagram some 
time ago which showed the (surprisingly complex) route packets take through 
the system when you have such a combination.

I'll describe the route the packets take, and hopefully you'll be able to 
identify from that a suitable place for you to do the filtering you want...

1. An IPsec-encrypted packet comes in on the real interface (eth1) addressed 
to the Firewall / VPN gateway, so it passes through PREROUTING and then 
INPUT.   The input interface as seen by netfilter (-i) is eth1.

2. The packet gets processed by the Klips kernel-level IPsec module, gets 
decrypted, and appears on the ipsec0 virtual interface.

3. The decrypted packet has the true destination address, so it passes through 
PREROUTING, FORWARD and POSTROUTING.   Note that for the first two if these, 
the input interface as seen by netfilter (-i) is ipsec0.

4. Reply packets come back in on the real physical interface (eth2) and go 
through PREROUTING, FORWARD and POSTROUTING, and get routed to ipsec0.

5. Klips picks up the packets on ipsec0, encrypts them, and then generates 
IPsec-encrypted packets from a local process, which therefore pass through 
OUTPUT and POSTROUTING before going out of the real interface eth1.

So, from the above you can see that the FORWARD chain will always see 
unencrypted packets, but they may be coming from or going to ipsec0.

INPUT will see the encrypted packets coming in to be decrypted, and OUTPUT 
will see the packets which have just been encrypted before leaving the box.

You may be able to do the filtering you want based on -i and -o interface 
names.   Look at the log entries carefully to see if that's all it takes.

Hope this helps,

Antony.

-- 
Documentation is like sex.
When it's good, it's very very good.
When it's bad, it's still better than nothing.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Firewalling non-IPsec connections

[Sven-Haegar Koch]

On Mon, 15 Dec 2003, Antony Stone wrote:

> On Sunday 14 December 2003 10:30 pm, Peter Hoeg wrote:
>
> > The REAL problem is since I need to allow connections from the wireless LAN
> > segment to go onto the internet and it seems like the connections only hit
> > the FORWARD chain AFTER the kernel has done all its magic with unpacking
> > the encrypted packages. What I would like to do is something like:

> I have used IPtables + FreeS/WAN a fair amount, and I created a diagram some
> time ago which showed the (surprisingly complex) route packets take through
> the system when you have such a combination.

FreeS/WAN is different than the in-kernel IPsec of 2.6

> 2. The packet gets processed by the Klips kernel-level IPsec module, gets
> decrypted, and appears on the ipsec0 virtual interface.

The in-kernel ipsec does not have an ipsec0 virtual interface, that is
where the problem come from - I don't see a way yet to destinguish
decapsulated ipsec traffic from eth0 to eth1 from raw traffic between the
two interfaces.

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

Re: Firewalling non-IPsec connections

[Michael Gale]

Hello,

	Can you not check the protocol of a forward packet and if encrypted
send to a use chain:

iptables -N EXTnoipsec
iptables -N EXTyesipsec

iptables -A INPUT -i ext -p 50 -j EXTyesipsec
iptables -A INPUT -i ext ! -p 50 -j EXTnoipsec

Michael



On Tue, 16 Dec 2003 00:55:41 +0100 (CET)
Sven-Haegar Koch <haegar@sdinet.de> wrote:

> On Mon, 15 Dec 2003, Antony Stone wrote:
> 
> > On Sunday 14 December 2003 10:30 pm, Peter Hoeg wrote:
> >
> > > The REAL problem is since I need to allow connections from the
> > > wireless LAN segment to go onto the internet and it seems like the
> > > connections only hit the FORWARD chain AFTER the kernel has done
> > > all its magic with unpacking the encrypted packages. What I would
> > > like to do is something like:
> 
> > I have used IPtables + FreeS/WAN a fair amount, and I created a
> > diagram some time ago which showed the (surprisingly complex) route
> > packets take through the system when you have such a combination.
> 
> FreeS/WAN is different than the in-kernel IPsec of 2.6
> 
> > 2. The packet gets processed by the Klips kernel-level IPsec module,
> > gets decrypted, and appears on the ipsec0 virtual interface.
> 
> The in-kernel ipsec does not have an ipsec0 virtual interface, that is
> where the problem come from - I don't see a way yet to destinguish
> decapsulated ipsec traffic from eth0 to eth1 from raw traffic between
> the two interfaces.
> 
> c'ya
> sven
> 
> -- 
> 
> The Internet treats censorship as a routing problem, and routes around
> it.(John Gilmore on http://www.cygnus.com/~gnu/)
> 

Re: Firewalling non-IPsec connections

[Antony Stone]

On Monday 15 December 2003 11:55 pm, Sven-Haegar Koch wrote:

> On Mon, 15 Dec 2003, Antony Stone wrote:
> >
> > I have used IPtables + FreeS/WAN a fair amount, and I created a diagram
> > some time ago which showed the (surprisingly complex) route packets take
> > through the system when you have such a combination.
>
> FreeS/WAN is different than the in-kernel IPsec of 2.6
>
> The in-kernel ipsec does not have an ipsec0 virtual interface, that is
> where the problem come from - I don't see a way yet to destinguish
> decapsulated ipsec traffic from eth0 to eth1 from raw traffic between the
> two interfaces.

Ah.   I have yet to play with the features of 2.6 kernels, therefore I didn't 
realise that this version of IPsec has such a drawback compared to FreeS/WAN.

It may be that the higher efficiency of the in-kernel version means there is 
less userspace information available about where packets came from or are 
going to...

Please let us know if you find a solution to this - I'm sure many of us will 
encounter this sort of thing in the future once 2.6 becomes standard.

Antony.

-- 
Success is a lousy teacher.  It seduces smart people into thinking they can't 
lose.

 - William H Gates III

                                                     Please reply to the list;
                                                           please don't CC me.

RE: Firewalling non-IPsec connections

[Mark Weaver]

> > The in-kernel ipsec does not have an ipsec0 virtual interface, that is
> > where the problem come from - I don't see a way yet to destinguish
> > decapsulated ipsec traffic from eth0 to eth1 from raw traffic
> between the
> > two interfaces.
>
> Ah.   I have yet to play with the features of 2.6 kernels,
> therefore I didn't
> realise that this version of IPsec has such a drawback compared
> to FreeS/WAN.
>
I solved this using firewall marks.  Essentially, packets that come in via
IPSEC and then get untunelled retain the fwmark, so you can do something
like:

iptables -t mangle -A PREROUTING -i eth0 -p esp -j MARK --set-mark 1
iptables -A INPUT -m mark --mark 1 -j ACCEPT

(Obviously repeat for forward if required and do further firewalling for
anything you don't trust from your VPN).

There is also a way of matching particular SPIs inside AH/ESP packets (where
you can do the same thing and set a mark).  This is even better because
specific connections can then be tracked, untested but should be something
like:

iptables -t mangle -A PREROUTING -m esp --espspi num:num -j MARK --set-mark
1

You would more than likely want to insert these into the firewall ruleset
dynamically with the help of your keying daemon (freeswan, isakmpd, ...).

Mark

Re: Firewalling non-IPsec connections

[Antony Stone]

On Tuesday 16 December 2003 2:45 pm, Mark Weaver wrote:

> > > The in-kernel ipsec does not have an ipsec0 virtual interface, that is
> > > where the problem come from - I don't see a way yet to destinguish
> > > decapsulated ipsec traffic from eth0 to eth1 from raw traffic
> > > between the two interfaces.
> >
> > Ah.   I have yet to play with the features of 2.6 kernels,
> > therefore I didn't
> > realise that this version of IPsec has such a drawback compared
> > to FreeS/WAN.
>
> I solved this using firewall marks.  Essentially, packets that come in via
> IPSEC and then get untunelled retain the fwmark, so you can do something
> like:
>
> iptables -t mangle -A PREROUTING -i eth0 -p esp -j MARK --set-mark 1
> iptables -A INPUT -m mark --mark 1 -j ACCEPT

I'm intrigued by this.   If the packets are encrypted with ESP as they go 
through PREROUTING, but you need to MARK them in order to recognise which 
ones they are by the time they hit the INPUT chain, at what point does the 
decryption occur?   Does it mysteriously happen somewhere between the 
PREROUTING and INPUT chains?   (If it does, I can see an awful lot more 
puzzled newbies asking questions here once 2.6 takes off....)

Antony.

-- 
"Reports that say that something hasn't happened are always interesting to me, 
because as we know, there are known knowns; there are things we know we know. 
We also know there are known unknowns; that is to say we know there are some 
things we do not know. But there are also unknown unknowns - the ones we 
don't know we don't know."

 - Donald Rumsfeld, US Secretary of Defence

                                                     Please reply to the list;
                                                           please don't CC me.

RE: Firewalling non-IPsec connections

[Mark Weaver]

> I'm intrigued by this.   If the packets are encrypted with ESP as they go
> through PREROUTING, but you need to MARK them in order to recognise which
> ones they are by the time they hit the INPUT chain, at what point
> does the
> decryption occur?   Does it mysteriously happen somewhere between the
> PREROUTING and INPUT chains?   (If it does, I can see an awful lot more
> puzzled newbies asking questions here once 2.6 takes off....)
>
I have to guess so.  I've no idea TBH where the packets actually go, but
this definitely works for me.  I'm more of a cook than a chef when it comes
to netfilter.  I've tried looking around the source, but I'm pretty
clueless, and the native ipsec doesn't seem to be documented at all.  It's
not even got a maintainer listed, and virtually nothing in
linux/Documentation.  (If anyone could point me in the right direction that
would be great!).

It kind of makes sense, because without this we'd have no possibility of
handling packets that came in via an IPSC tunnel separately.

Mark

Re: Firewalling non-IPsec connections

[Peter Hoeg]

Mark Weaver wrote:

>I have to guess so.  I've no idea TBH where the packets actually go, but
>this definitely works for me.  I'm more of a cook than a chef when it comes
>to netfilter.  I've tried looking around the source, but I'm pretty
>clueless, and the native ipsec doesn't seem to be documented at all.  It's
>not even got a maintainer listed, and virtually nothing in
>linux/Documentation.  (If anyone could point me in the right direction that
>would be great!).
>
mark, you simply rule! this fixed my problem. now, since i was going 
nuts trying to figure it out and i couldn't find ANY info on ANYWHERE 
(you guys were my last resort), so i have decided to make a small guide 
(i needed to learn docbook anyway so this seemed like a good chance) 
which can be found here:

http://hoeg.org/lri/

but one thing - to be honest i actually was thinking briefly about the 
MARK solution myself but came to the conclusion that since it is similar 
to the TOS marks you can set, then technically somebody else could tag 
the packets themselves before entering my system which would bypass the 
solution. and thats why i didnt take it further. can anybody shed any 
light on that?

but in order for the search engines to pick up this message: racoon 
linux kernel 2.6 ipsec vpn tunnel firewall iptables netfilter

>It kind of makes sense, because without this we'd have no possibility of
>handling packets that came in via an IPSC tunnel separately.
>
agree

Re: Firewalling non-IPsec connections

[Michael H. Warfield]

[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]

On Wed, Dec 17, 2003 at 11:02:35PM +0100, Peter Hoeg wrote:
> Mark Weaver wrote:
> 
> >I have to guess so.  I've no idea TBH where the packets actually go, but
> >this definitely works for me.  I'm more of a cook than a chef when it comes
> >to netfilter.  I've tried looking around the source, but I'm pretty
> >clueless, and the native ipsec doesn't seem to be documented at all.  It's
> >not even got a maintainer listed, and virtually nothing in
> >linux/Documentation.  (If anyone could point me in the right direction that
> >would be great!).

> mark, you simply rule! this fixed my problem. now, since i was going 
> nuts trying to figure it out and i couldn't find ANY info on ANYWHERE 
> (you guys were my last resort), so i have decided to make a small guide 
> (i needed to learn docbook anyway so this seemed like a good chance) 
> which can be found here:

> http://hoeg.org/lri/

> but one thing - to be honest i actually was thinking briefly about the 
> MARK solution myself but came to the conclusion that since it is similar 
> to the TOS marks you can set, then technically somebody else could tag 
> the packets themselves before entering my system which would bypass the 
> solution. and thats why i didnt take it further. can anybody shed any 
> light on that?

	No...  TOS is contained in the packet.  It's actually a header
field.  MARK is not.  It's not a part of the packet at all outside of the
system.  It can not be introduced from outside the system.

> but in order for the search engines to pick up this message: racoon 
> linux kernel 2.6 ipsec vpn tunnel firewall iptables netfilter

> >It kind of makes sense, because without this we'd have no possibility of
> >handling packets that came in via an IPSC tunnel separately.

> agree

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

RE: Firewalling non-IPsec connections

[Mark Weaver]

> so i have decided to make a small guide
> (i needed to learn docbook anyway so this seemed like a good chance)
> which can be found here:
>
> http://hoeg.org/lri/
>
Splendid, more information on this sort of thing is always useful.  I guess
2.6 is lagging a bit behind in the documentation stakes at the moment.

> then technically somebody else could tag
> the packets themselves before entering my system which would bypass the
> solution. and thats why i didnt take it further. can anybody shed any
> light on that?
>
The mark is just an internal tag in the kernel attached to the packet.  As
such, only the kernel ever adds or uses the mark, and it is not something
that can be automatically introduced by anything in a packet that someone
sends to you -- in other words, it's quite safe.

As soon as the freeswan users list is back, I'll see if I can get help
figuring out how to match on the SPI (I'm using pluto for keying currently
as it's a lot less manual than racoon), which allows easy per tunnel
firewalling.

> but in order for the search engines to pick up this message: racoon
> linux kernel 2.6 ipsec vpn tunnel firewall iptables netfilter
>
Google picks up a lot of russian pages for that at the moment :)