stf and NAT

[Rodolphe De Saint Leger]

Hi,

I wrote a patch for if_stf.c in order to accept DMZ type setup.

http://82.67.230.130/patch.diff
http://82.67.230.130/if_stf.c (the full file)

Did I make any mistake in processing ?
Any comments ?

Actually, I'm using it without any problem.

This patch should not disturb existing setups (as the only exception
is tolerance about our local address on emission or reception) and can
be activated or not using a define (so it can be a kernel option like
IPSEC_NAT_T).

I encountered this problem by the past and I use to resolve it using
NAT tricks (also if aliases tricks). Accepting 'dmz' behavior may be a
cleaner way to use 6to4.

I did this for me so the patch is against the 3-1-release branch, but
I'll work for a patch for -current if needed.

Regards,

[Zafer Aydogan]

Post by Rodolphe De Saint Leger
Hi,
I wrote a patch for if_stf.c in order to accept DMZ type setup.
http://82.67.230.130/patch.diff
http://82.67.230.130/if_stf.c (the full file)
Did I make any mistake in processing ?
Any comments ?
Actually, I'm using it without any problem.
This patch should not disturb existing setups (as the only exception
is tolerance about our local address on emission or reception) and can
be activated or not using a define (so it can be a kernel option like
IPSEC_NAT_T).
I encountered this problem by the past and I use to resolve it using
NAT tricks (also if aliases tricks). Accepting 'dmz' behavior may be a
cleaner way to use 6to4.
I did this for me so the patch is against the 3-1-release branch, but
I'll work for a patch for -current if needed.
Regards,
--
There is currently insufficient research to definitively conclude that
unix overuse is an addiction.

Looks good.
Can you please write a patch for current.
Thanks, Zafer.

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

[Rodolphe De Saint Leger]

Post by Zafer Aydogan
Looks good.
Can you please write a patch for current.
Thanks, Zafer.

Here is (almost) the same patch for current,

http://82.67.230.130/strict/current/cpatch.diff
http://82.67.230.130/strict/current/if_stf.c

I added another option (strict checking of 6to4 traffic) and ingress
filtering for ipv6 addresses.

I made some tests, it seems to work.
Any comments ?

Could it be commited to head ?

Regards

[David Young]

Post by Rodolphe De Saint Leger

Post by Zafer Aydogan
Looks good.
Can you please write a patch for current.
Thanks, Zafer.

Here is (almost) the same patch for current,
http://82.67.230.130/strict/current/cpatch.diff
http://82.67.230.130/strict/current/if_stf.c
I added another option (strict checking of 6to4 traffic) and ingress
filtering for ipv6 addresses.
I made some tests, it seems to work.
Any comments ?
Could it be commited to head ?

I am not sure I understand the problem you are trying to solve. It seems
that your host has an ethernet (say) with an RFC1918 address assigned;
your host plugs into a router that translates the host's RFC1918 number
to and from some globally-routable IPv4 address. You want for your host
to use that globally-routable IPv4 address for 6to4. The address in
the encapsulated IPv6 packet has to embed the global IPv4 adddress; the
encapsulation IPv4 header needs to contain the host's RFC1918 address,
which the router will translate. The stf(4) pseudo-interface does not
provide for that. Is that about right?

Can you meet your needs using IP Filter or PF? Or, if a general-purpose
tool will not do, doesn't it make sense to isolate the "DMZ adaptation"
in its own pseudo-interface? That may benefit more NetBSD applications
in a DMZ than a stf(4) modification alone.

Dave

[Rodolphe De Saint Leger]

Post by David Young
I am not sure I understand the problem you are trying to solve. It seems
that your host has an ethernet (say) with an RFC1918 address assigned;
your host plugs into a router that translates the host's RFC1918 number
to and from some globally-routable IPv4 address. You want for your host
to use that globally-routable IPv4 address for 6to4. The address in
the encapsulated IPv6 packet has to embed the global IPv4 adddress; the
encapsulation IPv4 header needs to contain the host's RFC1918 address,
which the router will translate. The stf(4) pseudo-interface does not
provide for that. Is that about right?

Yes

I encountered this problem several times before. I had a direct
unfiltered natted address for my host, but I could not use 6to4
because of addresses restrictions. I had a global address seen from
the internet world, but not from stf. Of course, I could not change
the router configuration or take it's place...

Post by David Young
Can you meet your needs using IP Filter or PF? Or, if a general-purpose
tool will not do, doesn't it make sense to isolate the "DMZ adaptation"
in its own pseudo-interface? That may benefit more NetBSD applications
in a DMZ than a stf(4) modification alone.

Yes it's possible, but it may not work in all routers configuration
(because of ingress filtering) and your machine may be unreachable in
some cases. To make it working, you can add an alias of the global
address on one of your interface, and one bimap rule in your ipnat. I
found several peoples which had this problem and I tried to implement
a cleaner solution (there are also other patches avalaible for freebsd
on some posts).

What do you mean by a dmz pseudo interface ?

The dmz part is quite small (just two tests to exit) and is really
about... tolerance of packet source (in input) or missing global ip
(to emit). I added lots of security checks wich are not done actually
and ingress filter for v6 packets (these checks represent most of the
code). I spent lots of time about security checks. I don't think that
a packet filter could do such tests which are specific to the 6to4
traffic.

Rodolphe