the problem we have right now in FreeBSD is described below.
http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction
when IPsec tunnel packet comes in, normal ipfw/ipfilter/whatever looks
at it twice. once before the decapsuation, once after the
decapsulation. this is why ipfw/ipfilter/whatever chokes with IPsec
tunnel settings.
>PS: about the picture / language problems, you should be able to
>reproduce the problem using the SPD rules shown in my original
>message. The topology in a picture looks like this:
>
>Remote Site A
>10.1.1.0/24 gw 10.1.1.1
> alias 24.16.23.234 -----+ Central Site
> | 10.1.0.1 gw for 10.1.0.0/24
>Remote Site B Internet--- 123.44.55.1 alias
>10.1.2.0/24 gw 10.1.2.1 |
> alias 24.19.3.168 ------+
In this case, the change mentioned in the above URL helps. the
equivalent change is also integrated in kame/freebsd, waiting for
testers. there were attempts to do the similar thing for stock freebsd
on some of the freebsd mailing lists.
http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction
in the above diagram, you don't want both NAT and IPsec happen for
a particular packet. for example, from remote site A,
- a packet to 10.1.2.0/24 should go through IPsec tunnel to
remote site B
- a packet to 10.1.0.0/24 should go through IPsec tunnel to
central site
- other packets should go through NAT and go to the Internet
so if you put filtering rules to differentiate between the three cases,
and have a proper IPsec policy rule for the first and second,
you should be okay.
itojun
---------------------------------------------------------------------
The IPv6 Users Mailing List
Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]