Hi all!
I'm starting with IPSec right now. To make it work, I must open up
protocols 50 and 51 to pass across my Linux firewalls, but I want to use
connection tracking much like I do when not using IPSec.
For example,
iptables -A INPUT -m state --state RELATED,ESTABLISHED
When using IPSec, if I open up protocols 50 and 51, all IPSec-protected
traffic passes through the firewall, but it's not checked against the
connection tracking module. How can I configure iptables so an
IPSec-protected packet, after being classified as IP protocol 50 or 51,
loop back one more time to pass through the connection tracking module?
I don't want to set up IPSec to get addititional protection by using AH
and ESP and then let any machine talking IPSec pass entirely through my
firewall ignoring the rest of rules.
Thanks!
Am Mi, 2003-08-20 um 13.22 schrieb Felipe Alfaro Solana:
> When using IPSec, if I open up protocols 50 and 51, all IPSec-protected
> traffic passes through the firewall, but it's not checked against the
> connection tracking module. How can I configure iptables so an
> IPSec-protected packet, after being classified as IP protocol 50 or 51,
> loop back one more time to pass through the connection tracking module?
You're saying it's not honouring the netfilter rules at all?
I'm having a related problem here. I switched my small home
server/router to the 2.6 kernel and switched from klips(freeswan) to the
new in-kernel ipsec. Racoon is working fine as keying daemon but the
netfilter rules don't work anymore.
I'm using it to encrypt between a single server in the internet (not a
network) and my router at home. I want it to masquerade the traffic from
my internal home network to the other machine, just like if there was no
encrypted path.
It doesn't work. The traffic from my internal network goes out
masqueraded but unencrypted and the other machine answers, but
encrypted, and on the return path my router at home throws the packet
away because it doesn't know what to do with that packet.
With klips it was possible to apply netfilter rules before and after the
packets got encrypted, because there was an additional virtual device
(ipsec0) that catches the traffic before encryption (or after
decryption).
--
Christophe Saout <[email protected]>
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
--On Wednesday, August 20, 2003 01:22:49 PM +0200 Felipe Alfaro Solana
<[email protected]> wrote:
> Hi all!
>
> I'm starting with IPSec right now. To make it work, I must open up
> protocols 50 and 51 to pass across my Linux firewalls, but I want to use
> connection tracking much like I do when not using IPSec.
>
> For example,
>
> iptables -A INPUT -m state --state RELATED,ESTABLISHED
Hmm. You can't do this if the end host does the ESP (AH is another
matter). Ever. If the ESP is working, the router can't tell what is
inside the packet; this is the whole point of IPSEC. If you want this
functionality, you can only provide it on the end host, or else do the
IPSEC on the router.
> When using IPSec, if I open up protocols 50 and 51, all IPSec-protected
> traffic passes through the firewall, but it's not checked against the
> connection tracking module. How can I configure iptables so an
> IPSec-protected packet, after being classified as IP protocol 50 or 51,
> loop back one more time to pass through the connection tracking module?
You can't, by design of IPSEC. However, you do have a couple of options:
1) let through IPSEC only for hosts you trust
2) for hosts you must firewall at the router, do the IPSEC there too, and
do not allow those hosts to use IPSEC.
These aren't exclusive.
>
> I don't want to set up IPSec to get addititional protection by using AH
> and ESP and then let any machine talking IPSec pass entirely through my
> firewall ignoring the rest of rules.
>
> Thanks!
You're welcome.
Andrew
> > I'm starting with IPSec right now. To make it work, I must open up
> > protocols 50 and 51 to pass across my Linux firewalls, but I want to use
> > connection tracking much like I do when not using IPSec.
> >
> > For example,
> >
> > iptables -A INPUT -m state --state RELATED,ESTABLISHED
>
> Hmm. You can't do this if the end host does the ESP (AH is another
> matter). Ever. If the ESP is working, the router can't tell what is
> inside the packet; this is the whole point of IPSEC. If you want this
> functionality, you can only provide it on the end host, or else do the
> IPSEC on the router.
Well, I'm using IPSec on two machines and both of them are end hosts.
They are *not* working as routers. My netfilter rules are:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- localhost.localdomain anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
The problem is that if I enable IPSec on both machines by using manual,
preshared keys, no traffic will pass through both firewalls, as I need
to open up protocols 50 and 51 (AH and ESP).
The problem here is that opening up protocols 50 and 51, makes *any*
IPSec-protected traffic to pass the firewall, but I still want that any
traffic (IPSec-protected or not) be applied the connection-track
filters. For normal (no IPSec) traffic, an incoming packet is only
accepted if it belongs to a connection that was initiated locally. For
IPSec traffic, I just want the same. I don't want any kind of
IPSec-protected traffic to be able to pass through the firewall, only
traffic that belongs to a connection that was initiated locally on the
machine receiving it.
End note: an incoming packet should be accepted by the firewall if and
only if there is a corresponding connection (let it be TCP, UDP or ICMP)
that was first initiated locally on that machine. For example, for any
incoming TCP packet to traverse the firewall, first there must have been
a packet with the SYN flag that travelled in the opposite direction. I
want this to work for normal traffic (it does work now) and for
IPSec-protected traffic.
Did I explain it clearly?
Thanks again!
On Wed, 2003-08-20 at 14:11, Christophe Saout wrote:
> Am Mi, 2003-08-20 um 13.22 schrieb Felipe Alfaro Solana:
>
> > When using IPSec, if I open up protocols 50 and 51, all IPSec-protected
> > traffic passes through the firewall, but it's not checked against the
> > connection tracking module. How can I configure iptables so an
> > IPSec-protected packet, after being classified as IP protocol 50 or 51,
> > loop back one more time to pass through the connection tracking module?
>
> You're saying it's not honouring the netfilter rules at all?
No... What I'm saying is that normal IP traffic is processed by the
firewall. However, if the incoming traffic is protected with IPSec,
since I opened up protocols 50 and 51, the IPSec traffic is admitted
without passing any remaining firewall filters. The machine in question
is an end host (not a router).
I want something like this:
1. If an IPSec-protected IP packet arrives and since we're not operating
in tunnel mode (the machine is an end host and not a router), the IP
header contains the destination host and is readable. Since we're using
ESP and the packet is intended for us, decrypt the payload to get access
to the TCP/UDP/ICMP data.
2. Else, if the incoming packet is not IPSec-protected, the TCP/UDP/ICMP
payload is already in plaintext.
3. At this point, we have a plaintext TCP/UDP/ICMP payload.
4. If the TCP/UDP/ICMP incoming packet belongs to an existing
connection, that was initiated locally, let the packet pass.
5. Else, the packet is silently discarded.
On Wed, Aug 20, 2003 at 01:22:49PM +0200, Felipe Alfaro Solana wrote:
> I'm starting with IPSec right now. To make it work, I must open up
> protocols 50 and 51 to pass across my Linux firewalls, but I want to use
> connection tracking much like I do when not using IPSec.
>
> For example,
>
> iptables -A INPUT -m state --state RELATED,ESTABLISHED
>
> When using IPSec, if I open up protocols 50 and 51, all IPSec-protected
> traffic passes through the firewall, but it's not checked against the
> connection tracking module. How can I configure iptables so an
> IPSec-protected packet, after being classified as IP protocol 50 or 51,
> loop back one more time to pass through the connection tracking module?
>
> I don't want to set up IPSec to get addititional protection by using AH
> and ESP and then let any machine talking IPSec pass entirely through my
> firewall ignoring the rest of rules.
you can use iptables to open proto 50 and 51 to specific ip's, too:
iptables -A INPUT -i eth0 -p 50 -s n.n.n.n -j ACCEPT
iptables -A INPUT -i eth0 -p 51 -s n.n.n.n -j ACCEPT
iptables -A INPUT -i eth0 -p 51 -s n.m.n.n -j DROP
this will work. If you want netfilter to fully recognize ipsec states
you have to do it yourself, afaik there is no ipsec support for the
statefull/conntrack system.
But you are better of asking here: [email protected]
--
Regards,
Wiktor Wodecki
Am Mi, 2003-08-20 um 16.22 schrieb Felipe Alfaro Solana:
> saying it's not honouring the netfilter rules at all?
>
> No... What I'm saying is that normal IP traffic is processed by the
> firewall. However, if the incoming traffic is protected with IPSec,
> since I opened up protocols 50 and 51, the IPSec traffic is admitted
> without passing any remaining firewall filters. The machine in question
> is an end host (not a router).
Yes, you're right. I just checked. Only the encrypted traffic passes the
netfilter rules, never the unencrypted data. So if you open the
protocols 50 and 51, the encrypted data can pass, gets
encrypted/decrypted and that data can always pass unchecked.
These packets should get reinjected into the netfilter mechanism after
decryption and should pass the rules before getting encrypted.
--
Christophe Saout <[email protected]>
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
On Wed, 2003-08-20 at 16:53, Christophe Saout wrote:
> > No... What I'm saying is that normal IP traffic is processed by the
> > firewall. However, if the incoming traffic is protected with IPSec,
> > since I opened up protocols 50 and 51, the IPSec traffic is admitted
> > without passing any remaining firewall filters. The machine in question
> > is an end host (not a router).
>
> Yes, you're right. I just checked. Only the encrypted traffic passes the
> netfilter rules, never the unencrypted data. So if you open the
> protocols 50 and 51, the encrypted data can pass, gets
> encrypted/decrypted and that data can always pass unchecked.
>
> These packets should get reinjected into the netfilter mechanism after
> decryption and should pass the rules before getting encrypted.
Exactly! Now, I dont know how to reinject the IPSec-decrypted packets
back to the netfilter engine. Anyone?
On Wednesday, 20 August 2003, at 16:53:47 +0200,
Christophe Saout wrote:
> These packets should get reinjected into the netfilter mechanism after
> decryption and should pass the rules before getting encrypted.
>
I don't know if this is possible or even desireable, but if you want to
have an answer from the people who cares and works most on Linux's net
support, you should at least Cc: [email protected], where Linux
network development occurs.
Regards,
--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test3-mm2)
--On Wednesday, August 20, 2003 04:16:28 PM +0200 Felipe Alfaro Solana
<[email protected]> wrote:
> Well, I'm using IPSec on two machines and both of them are end hosts.
> They are *not* working as routers. My netfilter rules are:
Ah. OK. You want to do that *inside* the tunnels.
> Chain INPUT (policy DROP)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
> ACCEPT all -- localhost.localdomain anywhere
>
> Chain FORWARD (policy DROP)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
>
> The problem is that if I enable IPSec on both machines by using manual,
> preshared keys, no traffic will pass through both firewalls, as I need
> to open up protocols 50 and 51 (AH and ESP).
Which makes sense so far.
> The problem here is that opening up protocols 50 and 51, makes *any*
> IPSec-protected traffic to pass the firewall, but I still want that any
> traffic (IPSec-protected or not) be applied the connection-track
> filters. For normal (no IPSec) traffic, an incoming packet is only
> accepted if it belongs to a connection that was initiated locally. For
> IPSec traffic, I just want the same. I don't want any kind of
> IPSec-protected traffic to be able to pass through the firewall, only
> traffic that belongs to a connection that was initiated locally on the
> machine receiving it.
It doesn't make sense for this configuration to fail in this way, I agree.
Essentially, the ESP and AH transforms should be a magic netfilter rule, so
you can insert them in a netfilter chain and do this sort of thing. If
they aren't, we should at least have the input and output chains traversed
by packets both before and after the transforms.
The issue exists, I'm convinced. Dang, I'm going to run into it too one
day soon. Another thing that needs looking at, in case noone else fixes it
first.
> End note: an incoming packet should be accepted by the firewall if and
> only if there is a corresponding connection (let it be TCP, UDP or ICMP)
> that was first initiated locally on that machine. For example, for any
> incoming TCP packet to traverse the firewall, first there must have been
> a packet with the SYN flag that travelled in the opposite direction. I
> want this to work for normal traffic (it does work now) and for
> IPSec-protected traffic.
>
> Did I explain it clearly?
Yes, you did.
> Thanks again!
You're welcome,
Andrew
On Wed, 2003-08-20 at 17:12, Andrew McGregor wrote:
> --On Wednesday, August 20, 2003 04:16:28 PM +0200 Felipe Alfaro Solana
> <[email protected]> wrote:
> > The problem here is that opening up protocols 50 and 51, makes *any*
> > IPSec-protected traffic to pass the firewall, but I still want that any
> > traffic (IPSec-protected or not) be applied the connection-track
> > filters. For normal (no IPSec) traffic, an incoming packet is only
> > accepted if it belongs to a connection that was initiated locally. For
> > IPSec traffic, I just want the same. I don't want any kind of
> > IPSec-protected traffic to be able to pass through the firewall, only
> > traffic that belongs to a connection that was initiated locally on the
> > machine receiving it.
>
> It doesn't make sense for this configuration to fail in this way, I agree.
>
> Essentially, the ESP and AH transforms should be a magic netfilter rule, so
> you can insert them in a netfilter chain and do this sort of thing. If
> they aren't, we should at least have the input and output chains traversed
> by packets both before and after the transforms.
I brought up the same thing in the netfilter and netfilter-dev lists
last month. http://www.spinics.net/lists/netfilter/msg18030.html
I think there's no need for a special netfilter rule if the assumption
is made that an ESP packet reaching the "mangle" chain of the "INPUT"
table is definitely destined for a local process. At that point, it
should be automatically unencapsulated so that its true protocol and
port numbers can be interrogated. e.g. if we know an ESP packet is for
this machine, do the unencapsulation as early as possible. Since
there's not yet a consensus on the behavior of things like NAT-based
forwarding of IPsec packets I think this is a safe assumption. (But my
opinion generally doesn't count for much.)
If it's important to remember that the packet had been an ESP packet,
netfilter can be set up to mark it as such in the PREROUTING mangle
chain so that it can later be filtered appropriately. This seems
similar to what I've read is done in FreeBSD:
http://www.bsdforums.org/forums/showthread.php?threadid=11725
> The issue exists, I'm convinced. Dang, I'm going to run into it too one
> day soon. Another thing that needs looking at, in case noone else fixes it
> first.
That's sort of what I thought too. And, yeah, I'd be real happy if
someone else did it before I tried to. 8^)
--
Rick Kennell <[email protected]>
Purdue University School of Electrical and Computer Engineering