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]