reverse processing order: NAT, IPsec ?

[Hubert Feyrer]

I'm in a situation where I want to setup a router to translate (NAT) a
local network in a private network (assume both are /24), then send the
traffic over an IPsec tunnel to a vpn-gw router (Netscreen VPN, not under
my control):

local/24 =NAT=> private/24 ===tunnel===> vpn-gw

I wonder how to get NAT & IPsec right here. With a "normal" DSL setup, I
configure ipf.conf so that the NAT is done on the outgoing interface, i.e.
pppo0, but I'm not sure what interface to use here: pppoe0 is intended to
send out IPsec traffic via the external network, as a consequence the
external interface looks even more wrong; specifying the internal
interface looks wrong as I'd expect translation to happen for inbound
traffic then only.

What the general order of processing in this case? the NetBSD IPsec FAQ
says that IPsec is applied first[1], but what I want is to do NAT first,
then put the result through the IPsec mechanism.

Does anyone have an idea how to achieve this?

Note that the NAT is before the IPsec connection, so I'm pretty sure NAT-T
is not relevant here.

Any clues? Thanks in advance!


- Hubert

[1] http://www.netbsd.org/docs/network/ipsec/#procorder

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

local/24 =NAT=> private/24 ===tunnel===> vpn-gw

I wonder how to get NAT & IPsec right here. With a "normal" DSL setup,
I configure ipf.conf so that the NAT is done on the outgoing
interface, i.e. pppo0, but I'm not sure what interface to use here:
pppoe0 is intended to send out IPsec traffic via the external network,
as a consequence the external interface looks even more wrong;
specifying the internal interface looks wrong as I'd expect
translation to happen for inbound traffic then only.

What the general order of processing in this case? the NetBSD IPsec
FAQ says that IPsec is applied first[1], but what I want is to do NAT
first, then put the result through the IPsec mechanism.

I think IPsec happens first, and this is because of the way the code is
in the kernel.

Does anyone have an idea how to achieve this?

Start by reading netinet/ip_output.c. IPSEC is before PFIL_HOOKS. I
think right now munging in there is the only way.

So try moving pfil_hooks up before the ifdef IPSEC blocks. I don't know
if there is a correpsonding input change necessary, or if input
processing will cope. I also don't know what else tricky will pop up,
but this feels like perturbing a hairy situation and asking for at least
a bit of trouble.

You could also have a second machine and NAT but not IPsec on that, and
separate NAT and IPsec functionality. Kludgy perhaps (xen?), but it
might be fewer hours to what you want.

[Hubert Feyrer]

Post by Greg Troxel
Start by reading netinet/ip_output.c. IPSEC is before PFIL_HOOKS. I
think right now munging in there is the only way.

My hope was to avoid this...

Post by Greg Troxel
You could also have a second machine and NAT but not IPsec on that, and
separate NAT and IPsec functionality. Kludgy perhaps (xen?), but it
might be fewer hours to what you want.

The Netscreen that I've been playing with basically has two machines in
one, which allows doing this in a ~sane way. Running something as
heavy-weighted as Xen to just do NAT sounds pretty sub-optimal.

I wonder if all this could be done on a single machine, with some bridge
interfaces in between, or similar...


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Post by Hubert Feyrer

Post by Greg Troxel
Start by reading netinet/ip_output.c. IPSEC is before PFIL_HOOKS. I
think right now munging in there is the only way.

My hope was to avoid this...

Post by Greg Troxel
You could also have a second machine and NAT but not IPsec on that, and
separate NAT and IPsec functionality. Kludgy perhaps (xen?), but it
might be fewer hours to what you want.

The Netscreen that I've been playing with basically has two machines in
one, which allows doing this in a ~sane way. Running something as
heavy-weighted as Xen to just do NAT sounds pretty sub-optimal.
I wonder if all this could be done on a single machine, with some bridge
interfaces in between, or similar...

if_tap can be used as a virtual interface; would this help to decouple
the networks before/after NAT?

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hans Rosenfeld]

Post by Hubert Feyrer
I'm in a situation where I want to setup a router to translate (NAT) a
local network in a private network (assume both are /24), then send the
traffic over an IPsec tunnel to a vpn-gw router (Netscreen VPN, not under
local/24 =NAT=> private/24 ===tunnel===> vpn-gw
I wonder how to get NAT & IPsec right here. With a "normal" DSL setup, I
configure ipf.conf so that the NAT is done on the outgoing interface,
i.e. pppo0, but I'm not sure what interface to use here: pppoe0 is
intended to send out IPsec traffic via the external network, as a
consequence the external interface looks even more wrong; specifying the
internal interface looks wrong as I'd expect translation to happen for
inbound traffic then only.
What the general order of processing in this case? the NetBSD IPsec FAQ
says that IPsec is applied first[1], but what I want is to do NAT first,
then put the result through the IPsec mechanism.
Does anyone have an idea how to achieve this?
Note that the NAT is before the IPsec connection, so I'm pretty sure
NAT-T is not relevant here.

Could you use IPsec in transport mode and use a gif tunnel over that?
IIRC I read somewhere that this is functionally the same as IPsec tunnel
mode, and it would allow you to use NAT on the gif interface.

Hans



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thomas Galliano]

Hi,

OpenBSD made work on the subject recently
http://undeadly.org/cgi?action=article&sid=20090127205841

Thomas

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Thomas Galliano
OpenBSD made work on the subject recently
http://undeadly.org/cgi?action=article&sid=20090127205841

This looks interesting. The change seems to be only in the userland's IKE
processing - I wonder if our Racoon is of any use here?


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Hubert Feyrer
I'm in a situation where I want to setup a router to translate (NAT) a
local network in a private network (assume both are /24), then send the
traffic over an IPsec tunnel to a vpn-gw router (Netscreen VPN, not under
local/24 =NAT=> private/24 ===tunnel===> vpn-gw
I wonder how to get NAT & IPsec right here. With a "normal" DSL setup, I
configure ipf.conf so that the NAT is done on the outgoing interface,
i.e. pppo0, but I'm not sure what interface to use here: pppoe0 is
intended to send out IPsec traffic via the external network, as a
consequence the external interface looks even more wrong; specifying the
internal interface looks wrong as I'd expect translation to happen for
inbound traffic then only.

<soapbox>
These difficulties sound like a symptom of the design flaw in NetBSD's
IPsec that we should not repeat: hard-coding hooks in the IP input
and output routines. A design that re-used existing abstractions
to provide building blocks to the operator---for example, an IPsec
pseudo-interface where the IPsec processing occurs---would be more
versatile and transparent, and it would spare us some complexity in the
IP code.

You could attach to an IPsec pseudo-interface both a BPF tap, packet
filters and translators. It seems that a second attachment point for
packet filters is what you need here.
</soapbox>

Dave

[Thor Lancelot Simon]

Post by David Young
<soapbox>
These difficulties sound like a symptom of the design flaw in NetBSD's
IPsec that we should not repeat: hard-coding hooks in the IP input
and output routines. A design that re-used existing abstractions
to provide building blocks to the operator---for example, an IPsec
pseudo-interface where the IPsec processing occurs---would be more
versatile and transparent, and it would spare us some complexity in the
IP code.

OpenS/WAN did it this way on Linux. It came with its own whole set of
nastinesses, notably a huge profusion of interfaces on any kind of busy
IPsec gateway. I'm not sure it's really much better.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Thor Lancelot Simon

Post by David Young
<soapbox>
These difficulties sound like a symptom of the design flaw in NetBSD's
IPsec that we should not repeat: hard-coding hooks in the IP input
and output routines. A design that re-used existing abstractions
to provide building blocks to the operator---for example, an IPsec
pseudo-interface where the IPsec processing occurs---would be more
versatile and transparent, and it would spare us some complexity in the
IP code.

OpenS/WAN did it this way on Linux. It came with its own whole set of
nastinesses, notably a huge profusion of interfaces on any kind of busy
IPsec gateway. I'm not sure it's really much better.

I don't see why there should be a profusion of interfaces if there isn't
a profusion already for other reasons, such as a profusion of tunnel
interfaces.

I think that the "nastiness" of a profusion of interfaces is more or
less a matter of taste. The idea of a profusion of interfaces perturbs
me no more than a profusion of routes or policies or flows.

I'm open to other ideas of how to relieve the NetBSD IPsec operator of
the current design's inflexibility and opacity as compared with other
parts of our network stack.

Dave

[Thor Lancelot Simon]

Post by David Young
I don't see why there should be a profusion of interfaces if there isn't
a profusion already for other reasons, such as a profusion of tunnel
interfaces.

If you can get the amount of memory used by 5,000 tunnel interfaces down
to the amount of memory used by the datastructures for 5,000 tunnel-mode
IPsec SAs and SPD entries now, most of my concern goes away. I guess it
would also be desirable to benchmark and see that it's no slower than the
current FAST_IPSEC implementation, under load, as well.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Hi David,

Post by David Young
<soapbox>
These difficulties sound like a symptom of the design flaw in NetBSD's
IPsec that we should not repeat: hard-coding hooks in the IP input
and output routines. A design that re-used existing abstractions
to provide building blocks to the operator---for example, an IPsec
pseudo-interface where the IPsec processing occurs---would be more
versatile and transparent, and it would spare us some complexity in the
IP code.
You could attach to an IPsec pseudo-interface both a BPF tap, packet
filters and translators. It seems that a second attachment point for
packet filters is what you need here.
</soapbox>

Indeed... but we don't have that, and I only start digging into the kernel
in that area. What I currently see is that an ICMP ECHO is going out, with
proper NAT and IPsec appled. The reply gets in via IPsec fine, but is not
NATted back properly any more.

I've tried the patch below to run NAT a second time after IPsec, but that
doesn't do anything. I've also tried PFIL_OUT instead of PFIL_IN, but that
resulted in a loop, just like running pfil_run_hooks() before the
inetsw[].pr_input() calls. (I've tried all four combinations, no go)

I'm not sure where to go from there, esp. that the sending of the ICMP
ECHO DTRT, and that only the receiving part causes trouble here.

Do you have an idea?


- Hubert


Index: ip_input.c
===================================================================
RCS file: /cvsroot/src/sys/netinet/ip_input.c,v
retrieving revision 1.275.4.1
diff -u -r1.275.4.1 ip_input.c
--- ip_input.c 25 Nov 2008 04:04:38 -0000 1.275.4.1
+++ ip_input.c 25 Jun 2009 14:47:48 -0000
@@ -1057,6 +1057,26 @@
int off = hlen, nh = ip->ip_p;

(*inetsw[ip_protox[nh]].pr_input)(m, off, nh);
+
+ /* XXX HF: PFIL_HOOKS run #2 */
+ {
+ int rc;
+ printf("HF: running pfil_run_hooks()\n");
+ rc = pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN);
+ if (rc != 0) {
+ printf("HF: bad: pfil_run_hooks returned %d\n", rc);
+ goto bad;
+ } else {
+ printf("HF: good: pfil_run_hooks returned %d\n", rc);
+ }
+ if (m == NULL) {
+ printf("HF: bad: m == NULL\n");
+ goto bad;
+ } else {
+ printf("HF: good: m != NULL\n");
+ }
+ }
+
return;
}
bad:


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by David Young
You could attach to an IPsec pseudo-interface both a BPF tap, packet
filters and translators. It seems that a second attachment point for
packet filters is what you need here.
</soapbox>

You mean like OpenBSD's enc(4)?

FWIW, I wonder if there is any difference between IPfilter and PF (and
their NAT routines, respectively) with respect to processing order. To my
understanding there isn't as both are called via pfil_hooks(), or am I
wrong here?


- Hubert (trapped in a maze :)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Hubert Feyrer
Do you have an idea?

OK, a bit step further:

Reverting to the original code with just the patch below makes things work
for me. Apparrently the current code only runs the PFIL_HOOKS once for
incoming IPsec packets, but not a second time after de-encapsulation.
This is what I'm seeing in tcpdump here. Disabling the test if the packet
was already processed gets NAT done properly (and yes, I have FAST_IPSEC
enabled instead of IPSEC).

Does anyone have an idea on the implications here? Why is a second run of
PFIL_HOOKS disabled (only!) for IPsec?


- Hubert


Index: ip_input.c
===================================================================
RCS file: /cvsroot/src/sys/netinet/ip_input.c,v
retrieving revision 1.275.4.1
diff -u -r1.275.4.1 ip_input.c
--- ip_input.c 25 Nov 2008 04:04:38 -0000 1.275.4.1
+++ ip_input.c 25 Jun 2009 15:12:21 -0000
@@ -653,7 +653,7 @@
#ifdef IPSEC
if (!ipsec_getnhist(m))
#elif defined(FAST_IPSEC)
- if (!ipsec_indone(m))
+ if (1 || !ipsec_indone(m))
#else
if (1)
#endif


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg A. Woods]

At Thu, 25 Jun 2009 17:17:29 +0200 (CEST), Hubert Feyrer <***@feyrer.de> wrote:
Subject: Re: reverse processing order: NAT, IPsec ?

Post by Hubert Feyrer
Reverting to the original code with just the patch below makes things work
for me. Apparrently the current code only runs the PFIL_HOOKS once for
incoming IPsec packets, but not a second time after de-encapsulation.
This is what I'm seeing in tcpdump here. Disabling the test if the packet
was already processed gets NAT done properly (and yes, I have FAST_IPSEC
enabled instead of IPSEC).
Does anyone have an idea on the implications here? Why is a second run of
PFIL_HOOKS disabled (only!) for IPsec?

I suspect, with thinking too much about it so I may have this completely
wrong, that calling PFIL hooks for the de-encapsulated packet will
indeed cause problems with filter rules in non-tunnel-mode
(connectionless) IPsec implementations, at least if those filter rules
are not designed to take into account the presence and removal of the
authentication header on an otherwise identical IP header.

[Greg A. Woods]

Post by David Young
<soapbox>
These difficulties sound like a symptom of the design flaw in NetBSD's
IPsec that we should not repeat: hard-coding hooks in the IP input
and output routines. A design that re-used existing abstractions
to provide building blocks to the operator---for example, an IPsec
pseudo-interface where the IPsec processing occurs---would be more
versatile and transparent, and it would spare us some complexity in the
IP code.
You could attach to an IPsec pseudo-interface both a BPF tap, packet
filters and translators. It seems that a second attachment point for
packet filters is what you need here.
</soapbox>

I have to agree, though I'm not sure it's a flaw with NetBSD per se, but
rather a common thought process "flaw" in the IPsec community right from
the beginning or at least in my initial attempt to understand IPsec.

Many other IPsec implementations I've seen, going right back to long
before any open-source platform supported IPsec, totally avoided having
IPsec appear as a real construct in any of the regular networking stack
-- it was more often just a fictional overlay controlled entirely
separately from the normal TCP/IP stack. If you didn't know the host or
router had IPsec capabilities and that they were configured and working
then you'd never know there was anything different about it until you
put a tap on the network and discovered some or all of the traffic to
and from that host/router was encrypted.

For me this made the whole concept of IPsec, and especially the
practicalities of how to configure it usefully, almost infinitely more
difficult to understand than it should have been. Once I finally
learned about using tunnels with IPsec and such then I could finally
grasp how IPsec was supposed to work and when I looked back at the
original non-tunnelled variant I could finally see what they were
talking about but I still thought it was (and is) a completely warped
concept. To me tunnel mode IPsec should be the only way. I can however
see how non-tunnelled IPsec might be easier to drop down on existing
hosts such that suddenly the network would (hopefully) be more secure
without the hosts having to do anything whatsoever. It's more a
marketing and sales engineering feature than a real technical benefit
though.

After seeing the ultimately simple fix Hubert posted to re-enable PFIL
hooks for IPsec de-encapsulated packets I had a deja vu moment and I
think I can say this silliness has caused problems in other contexts as
well.

I guess the question would be if you're using non-tunnel-mode IPsec then
does passing the de-encapsulated packet through the PFIL hooks again
actually cause any other problems or confusions? I suspect it would.

[Edgar Fuß]

Post by Greg A. Woods
After seeing the ultimately simple fix Hubert posted to re-enable PFIL
hooks for IPsec de-encapsulated packets I had a deja vu moment and I
think I can say this silliness has caused problems in other contexts as
well.

Applying this "fix" would break my installation. At least as long as those packets are indistinguishable from non-IPsec traffic arriving on the same interface.
Currently, packets arriving on the gateway's external interface but appearing to come from an internal network are dropped by anti-spoofing filter rules. ESP traffic passes, and the de-encapsulated packets are never seen again by the packet filter. If they were, they should be somehow marked as being de-encapsulated---otherwise they would be dropped by the anti-spoof rules.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Edgar Fuß
Applying this "fix" would break my installation. At least as long as
those packets are indistinguishable from non-IPsec traffic arriving on
the same interface. Currently, packets arriving on the gateway's
external interface but appearing to come from an internal network are
dropped by anti-spoofing filter rules. ESP traffic passes, and the
de-encapsulated packets are never seen again by the packet filter. If
they were, they should be somehow marked as being
de-encapsulated---otherwise they would be dropped by the anti-spoof
rules.

Are you sure? Looking at the code, only the pfil_run_hooks() call is ran
only for encapsulated packages, everything else is outside that codepath.
Or do you have those anti-spoofing rules in your packet filter
(PF/IPfilter) config?

Also, if you don't run the PFIL_HOOKS on the decapsulated package, how do
you prevent someone from sending "internal" packets via IPSEC - plain
trust?


- Hubert (still trying to get a grip on the code)

[Hubert Feyrer]

Post by Greg A. Woods
After seeing the ultimately simple fix Hubert posted to re-enable PFIL
hooks for IPsec de-encapsulated packets I had a deja vu moment and I
think I can say this silliness has caused problems in other contexts as
well.

I don't understand - do you mean it's silly to run PFIL hooks on
de-encapsulated packets?

Post by Greg A. Woods
I guess the question would be if you're using non-tunnel-mode IPsec then
does passing the de-encapsulated packet through the PFIL hooks again
actually cause any other problems or confusions? I suspect it would.

I'll test things here, and see what happens. So far I haven't met
problems.

FWIW, looking at our two IPsec implementations (IPSEC vs. FAST_IPSEC),
they seem to use different mbuf tags to indicate that the packet is still
encapsulated (IPSEC: PACKET_TAG_ESP) and that it has been processed by
IPSEC specifically (FAST_IPSEC: PACKET_TAG_IPSEC_IN_DONE).

I think thad adding a kernel option like
{FAST_,}IPSEC_ALSO_RUN_PFIL_HOOKS_ON_DECAPSULATED_PACKET
would be a first stab at my problem (see patch below). The option would be
disabled by default, to be compatible with the existing behaviour.

Comments? Anyone familiar with the code? :)


- Hubert



Index: ip_input.c
===================================================================
RCS file: /cvsroot/src/sys/netinet/ip_input.c,v
retrieving revision 1.275.4.1
diff -u -r1.275.4.1 ip_input.c
--- ip_input.c 25 Nov 2008 04:04:38 -0000 1.275.4.1
+++ ip_input.c 26 Jun 2009 07:37:34 -0000
@@ -650,9 +650,9 @@
* let ipfilter look at packet on the wire,
* not the decapsulated packet.
*/
-#ifdef IPSEC
+#if defined(IPSEC) && !defined(IPSEC_ALSO_RUN_PFIL_HOOKS_ON_DECAPSULATED_PACKET)
if (!ipsec_getnhist(m))
-#elif defined(FAST_IPSEC)
+#elif defined(FAST_IPSEC) && !defined(FAST_IPSEC_ALSO_RUN_PFIL_HOOKS_ON_DECAPSULATED_PACKET)
if (!ipsec_indone(m))
#else
if (1)


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

Post by Hubert Feyrer
Are you sure?

Quite.
First, I block.
Then I pass loopback, then my own broadcasts.
After that, I have anti-spoof rules.
Then, I pass ESP, AH and UDP/IKE and ICMP for the IPsec peers.

Post by Hubert Feyrer
Or do you have those anti-spoofing rules in your packet filter
(PF/IPfilter) config?

Yes, but I don't understand what you mean by "or".

Post by Hubert Feyrer
Also, if you don't run the PFIL_HOOKS on the decapsulated package, how do
you prevent someone from sending "internal" packets via IPSEC - plain
trust?

Yes. I trust the IPsec peer (because it's run by me).

Not that I'm against running de-encapsulated trough the filter again (to the contrary, I would like that idea). Only, those packets must be distinguishable from packets arriving in the clear.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg A. Woods]

At Fri, 26 Jun 2009 09:40:48 +0200 (CEST), Hubert Feyrer <***@feyrer.de> wrote:
Subject: running PFIL_HOOKS on decapsulated IPsec packets, too [was: Re: reverse processing order: NAT, IPsec ?]

Post by Hubert Feyrer

Post by Greg A. Woods
After seeing the ultimately simple fix Hubert posted to re-enable PFIL
hooks for IPsec de-encapsulated packets I had a deja vu moment and I
think I can say this silliness has caused problems in other contexts as
well.

I don't understand - do you mean it's silly to run PFIL hooks on
de-encapsulated packets?

Sorry about the confusion. No, it's silly not to run PFIL hooks on
de-encapsulated IPsec packets.

The problem though is of course that PFIL users must have some way to
know that whether a packet has been de-encapsulated or not. This is
straight forward for when tunnel-mode IPsec is used because PFIL users
can distinguish which interface the packet is currently associated with.
However for connectionless IPsec the determination must be made based on
whether the authentication header has been removed or not. (IIUC IPF
rules, for example, could use "proto 51" to test whether the
authentication header was still present or not)

Post by Hubert Feyrer
Comments? Anyone familiar with the code? :)

I don't think an option of any kind _should_ be necessary provided that
all PFIL users always do have some way to make use of the MBUF tags you
mentioned or some other appropriate indicator. Presumably IPF and PF
both have the necessary functionality -- is that enough?

In any case though for backward compatibility purposes it may still be
necessary to preserve the existing semantics by default since folks with
existing IPF/PF rule sets will not necessarily have all the appropriate
conditions in place to distinguish encapsulated and de-encapsulated
packets, even if they are using tunnel-mode IPsec.

Personally I would also prefer a runtime control option if there is to
be one, rather than just a compile time option.

[Darren Reed]

Post by Greg A. Woods
Subject: running PFIL_HOOKS on decapsulated IPsec packets, too [was: Re: reverse processing order: NAT, IPsec ?]

Post by Hubert Feyrer

Post by Greg A. Woods
After seeing the ultimately simple fix Hubert posted to re-enable PFIL
hooks for IPsec de-encapsulated packets I had a deja vu moment and I
think I can say this silliness has caused problems in other contexts as
well.

I don't understand - do you mean it's silly to run PFIL hooks on
de-encapsulated packets?

Sorry about the confusion. No, it's silly not to run PFIL hooks on
de-encapsulated IPsec packets.
The problem though is of course that PFIL users must have some way to
know that whether a packet has been de-encapsulated or not.

A long time ago, my idea for this was to have decapsulated IPsec packets
appear (to pfil) to be on a different network interface to the encapsulated
ones. Thus while your ESP traffic comes in via fxp0, when the traffic is
decapsulated and reinjected on fxp0, PFIL_HOOKS would present that
to the hooks as being on ipsec.fxp0 (or something similar.) By presenting
the packets as belonging to a different interface, it is then straight
forward
to write a rule set that applies the correct policy.

It might be worthwhile extending that idea further so that you can then
do "tcpdump -i ipsec.fxp0" to get a packet trace of only the unencrypted
packets.

The above would be used for *both* tunnel mode and transport mode
decapsulated packets.

Thoughts?

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

Darren> A long time ago, my idea for this was to have decapsulated
Darren> IPsec packets appear (to pfil) to be on a different network
Darren> interface to the encapsulated ones. Thus while your ESP

It's really the only sane thing to do.
it's what Linux *SWAN has always done.

Darren> The above would be used for *both* tunnel mode and transport
Darren> mode decapsulated packets.

I think this might be something to thing carefully about.
After a packet comes out of a transport mode SA, it does not really
have an IP header on it anymore. I suggest that if you just want a
tcpdump interface for this, that:
a) you use a new DLT value, which says, "layer-4".
b) you permit attachment somehow to individual sockets.

also c.f:
draft-ietf-btns-channel-binding and draft-ietf-btns-connection-latching.
--
] Y'avait une poule de jammé dans l'muffler!!!!!!!!! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] h("Just another Debian GNU/Linux using, kernel hacking, ruby guy"); [


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Edgar Fuß

Post by Hubert Feyrer
Or do you have those anti-spoofing rules in your packet filter
(PF/IPfilter) config?

Yes, but I don't understand what you mean by "or".

I was under the impression that you were referring to some in-kernel code
that filters certain packets, instead of your own filter rules. Hence the
"or".

Post by Edgar Fuß

Post by Hubert Feyrer
Also, if you don't run the PFIL_HOOKS on the decapsulated package, how do
you prevent someone from sending "internal" packets via IPSEC - plain
trust?

Yes. I trust the IPsec peer (because it's run by me).
Not that I'm against running de-encapsulated trough the filter again (to
the contrary, I would like that idea). Only, those packets must be
distinguishable from packets arriving in the clear.

Yes. FWIW, our two IPsec implementations behave different in that regard,
see the two functions that my last patch disabled: One checks if there's a
tag that indicates an ESP header, the other indicates whether a packet was
processed by IPsec or not. I think the latter would be what we'd need
here, and then an interface would be needed for IPfilter / PF to refer to
that flag.

The bad news is that I don't have the time to work on that, and that I'll
just life with my patch for now. Sorry! :)


- Hubert

[Thor Lancelot Simon]

Post by Hans Rosenfeld
Could you use IPsec in transport mode and use a gif tunnel over that?
IIRC I read somewhere that this is functionally the same as IPsec tunnel
mode, and it would allow you to use NAT on the gif interface.

Probably, but you'll have no luck getting it configured how the peer
expects if IKE is in use -- racoon has no idea how to do this.

[Hubert Feyrer]

Short: Does anyone use a gre-with-nat-over-ipsec setup that they'd like to
share the config?

Long:

I've made another stab at this, and run into some unexpected effects.
The setup I have (full version appended below):


home-LAN -> RouterA -> Internet -> RouterB -> office-LAN
\ /
\________________/
gre Tunnel


I have a gre(4) tunnel between the home-LAN and the office-LAN, using
inside addresses of RouterA and RouterB as the gre(4) endpoints.
This follows the "create link between two private networks" example in
gre(4).

Adding NAT on RouterA's gre interface went fine: Changes that I made are
using the NATted address for RouterA's endpoint in both gre configs,
setting a bimap rule in IPfilter, and adding a route to RouterB to route
the NAT network (not the home network) to RouterA. With that, I see NATed
packets arrive at RouterB, and routing to the office-LAN works like a
breeze in both directions.

After adding NAT was surprisingly painless, I expected that securing the
transport for the GRE tunnel with IPsec would be too: adding
point-to-point encryption between the external addresses of the routers.
For starters I chose static keys via setkey(8), no racoon (yet). As the
gif(4) interfaces aren't involved in encrypting the point-to-point
connection between the routers, I didn't expect any problems.
Wrong assumption!

What I see is sort of a routing loop between the routers where RouterB
sends an answer to RouterA, but RouterA doesn't know what to do with
the packet, so sends it back to RouterB. Which thinks it's for Router A,
which loops a number of times.

Playing with the link1 flag on the gre tunnels, adding more routes and NAT
rules on RouterA didn't result in any useful results (yet), and again I
wonder if this is some funny interaction between NAT and IPsec?

Does anyone use a gre-with-nat-over-ipsec setup that they'd like to share
the config?


- Hubert


P.S.:

Here is the detailled config that I use for NAT & GRE without IPsec
(I'm doing this inside a VMware Team environment for now, hence the
funny "Internet" IPs):


Home-LAN Internet Office-LAN
Home-PC ---------- RouterA ----------- RouterB ------------ Office-PC
192.168.11.3 Home: 192.168.11.2 Office: 10.22.22.1 10.22.22.3
Internet: 10.11.11.2 Internet: 10.11.11.1
\ /
\________________/
gre0: 10.253.253.2 gre0: 10.22.22.1
NAT: 192.168.11.0/24
-> 10.253.253.0/24


Config Home-LAN: 192.168.11.0/24, NATted to 10.253.253.0/24
Config Office-LAN: 10.22.22.0/24
Internet (Transport network): 10.11.11.0/24

Config Home-PC:
* rc.conf:
ifconfig_pcn0="192.168.11.3/24"
defaultroute="192.168.11.2"

Config RouterA:
* rc.conf:
ipfilter=yes
ipnat=yes
auto_ifconfig=no
net_interfaces="pcn0 pcn1 gre0"
ifconfig_pcn0="192.168.11.2/24"
ifconfig_pcn1="10.11.11.2/24"
ifconfig_gre0="10.253.253.2/24 10.22.22.1 tunnel 10.11.11.2 10.11.11.1 link1"

* route.conf:
default 10.22.22.1

* ipf.conf:
pass in from any to any
pass out from any to any

* ipnat.conf:
bimap gre0 192.168.11.0/24 -> 10.253.253.0/24

Config RouterB:
* rc.conf:
auto_ifconfig=no
net_interfaces="pcn0 pcn1 gre0"
ifconfig_pcn0="10.22.22.1/24"
ifconfig_pcn1="10.11.11.1/24"
ifconfig_gre0="10.22.22.1/24 10.253.253.2 tunnel 10.11.11.1 10.11.11.2 link1"

* route.conf:
net 10.253.253.0/24 10.253.253.2

Config Office-PC:
* rc.conf:
ifconfig_pcn0="10.22.22.3/24"
defaultrouter="10.22.22.1"

* route.conf:
net default 10.22.22.1

Test:
* On Home-PC: ping 10.22.22.3
* On Office-PC: ping 10.253.253.3
* Both testcases work with the above configuration, but fail
with a routing loop where RouterA sends back packets to RouterB
instead of performing NAT and forwarding them to the home-LAN when
adding SAs and SPDs for encryption between 10.11.11.1 and 10.11.11.2.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Hans Rosenfeld
Could you use IPsec in transport mode and use a gif tunnel over that?
IIRC I read somewhere that this is functionally the same as IPsec tunnel
mode, and it would allow you to use NAT on the gif interface.

I've ventured in this direction, with gre instead of gif.
See my other mail for the results...


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Hubert Feyrer
Here is the detailled config that I use for NAT & GRE without IPsec

P.P.S.: This is with NetBSD 5.0/i386 on all machines.


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de