-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Mipam" == Mipam  <mipam@ibb.net> writes:
    Mipam> In NetBSD ipf only looks to native wire packets.  On inbound
    Mipam> traffic a packet first needs to pass though ipf and then the ipsec
    Mipam> process follows. You still need to pass ipsec traffic though.  Ie
    Mipam> protocol 50 for esp and 51 for ah (rfc 1700 for a list of protocol
    Mipam> numbers). Its very nice, this way you can use the machine as nat
    Mipam> gateway but you can also use ipsec tunnel mode without nat
    Mipam> touching the packets. It worked for me (netbsd 1.5 release
    Mipam> branch).  Bye,

  Yes, but in this case, he has to NAT the packets to get them to a useful
address, and then tunnel them out. That way he can run his legacy win32
apps under VMware, and still access the corporate SMB server.

  We need to better integrate ipf into the IP stack, and we need two sets of
ipf/ipnat rules. One before IPsec processing, and the other after. 

  BETTER, we need to use IPF to implement the IPsec SPD, and combined ipnat
and ipf into a single list so that "NAT" is an action for IPF. 

  The FreeSWAN KLIPS2 redesign to use Linux netfilter is struggling with
the same issues.

Canadian Commuter Challenge Project -- GNU Potato Caboose 
Michael Richardson, Sandelman Software Works, Ottawa, ON  
EMAIL: mcr@commuterchallenge.net
for help, email or page at 1-866-231-8608


  


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface

iQCVAwUBOyDs9YqHRg3pndX9AQF1OgP+Mu/VE2HHTF8Zw+OJjmty9thlvuxZIgF+
fO4TfiJ3dUmN7eT1WVE3dYpQQwaS4cyJBDYZ4mvVq5UmaaakoMl4bu1B2UbOHI9l
k+/ZxrZKH5QZe99idYhsiRUYOKtJcMyBTZ8JW9Y6G9RLbJKJiEwHlHFrPD4giUI8
SDfrsHm7gpg=
=DyHd
-----END PGP SIGNATURE-----