> -----Original Message----- > From: Mitch (bitblock) [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 31, 2004 3:35 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: ipsec packet filtering > > But by adding the following option to the kernel conf > >file you can get the processing path I think you are asking for?? > > > > options IPSEC_FILTERGIF (documented in LINT) > > > > This then causes the decrypted packet to be passed thru > >IPFW again.Be aware this has significant consequences for where you > >do NAT in the ruleset and requires very careful crafting of the IPFW rules > > Pete > ok. > Will this allow me to do the following: > > Client 1 <--\ > FREEBSD ROUTER <----> Internet > Client 2 <--/ > > Client 1, although on the same subnet as client 2, can not > directly connect to Client 2. This is an underlying restriction of the ATM > transport of the telco we deal with. No option. > > I want to connect client 1, and client 2. I can create a > VPN from client 1 to central router, and client 2 to central router. In the > past, I could not route this traffic. Are you saying this should be possible now?
Taken me a while to think thru your Q. If the vpns have separate SAs and you use unique instead of require in the policy entry I think the answer is yes. That is assuming both vpns go out the one interface? You need that so the IPSEC code sees each VPN as different even tho' they use the one physical i/f However there may be an underlying packet routing issue here. I think you would need static routes defined for each client with the interface as the target rather than the IP eg: route add 192.168.1.0/24 -interface rl1 regards Pete _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
