On Thu, Dec 06, 2001 at 10:22:05PM +0500, Dingo wrote: > ipfilters ipnat.... We ran into the IPSec intercept problem with 4.3, > can you tell me when the changes were MFCd ? it might just be a matter > of updateing Ipfilter on this specific server. its a 4.3 RELEASE box. > But If I am correct, your telling me i can create a standard VPN, in > tunnel or transport mode, with ipfs ipnat, no gif devices ?? like > > 10.0.xxx.xxx -> ipnat -> 4.23.122.100 -> IPSEC TUNNEL <- 4.22.121.101 <- > ipnat <- 10.20.xxx.xxx > [What's missing in this picture is how ipnat modifies the 10.0 -> 10.20 packets. I will assume it hides the 10.0.xxx.xxx addresses after a single 4.23.122.100.]
I'm not fluent in IPFilter (and IPNAT in particular), but I think there may be some difference between how IPNAT and IPDIVERT work. With IPDIVERT, a packet is first passed to a userland process, natd(8) in a similar scenario, and natd(8) writes the modified packet back to kernel which then passes this new packet back to ip_output(). ip_output() is organized so that IPSEC hooks are called before IPDIVERT and IPNAT hooks, but with IPDIVERT it's no problem, since the new packet is passed again to ip_output(), and if you tell your IPSEC to tunnel between 4.23.122.100 and 4.22.121.101, IPSEC will intercept that NATed packet. If IPNAT doesn't do the same, i.e., if it doesn't consider the NATed packet a "new" packet, and just continues with the modified packet, we have a trouble -- we have no way to IPSEC modified packet. Let IPFilter gurus speak up. :-) > On Thu, 2001-12-06 at 11:10, Ruslan Ermilov wrote: > > On Thu, Dec 06, 2001 at 10:02:38PM +0500, Dingo wrote: > > > can you enlighten me a bit, GIF devices are the only way I know how to > > > do tunnel mode IPSec along with NAT > > > > > What kind of NAT? What would you like to NAT: payload or armour? > > ipnat(1) or natd(8)? How, in your opinion, gif(4) devices help > > NAT? > > > > We're runnign an (over Inet) distributed VPN using IPSEC without > > any gif(s), and with NAT (using natd(8)). > > > > ISTR some problems in the past, where IPSEC intercepted packets > > (in ip_output()) before they were passed to "ipfw" and/or "ipf", > > but the order was fixed a later day. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
