I can't say for sure that this is directly related to the fact that
ipfilter and ipfw are used in conjunction. In theory, the afore
mentioned scenario should work.
Perhaps a possible resolution to this is to add a seperate Rules page
just for an IPSEC firewall? Unfortunately, that seems like a
temporary resolution. I'd like to see the regular Rules page
incorporate a way of filtering IPSEC traffic.
I know there is a way (according to the FreeBSD handbook) to put all
this IPSEC traffic through a virtual network interface (gif0, gif1,
etc). Similar to how the PPTP server works with the ng0, ng1
interfaces. If this was how things were done then traffic could
easily be filtered.
Just my 2 cents.
On Thu, 27 Jan 2005 10:42:02 +0100, Vincent Fleuranceau
<vincent at bikost dot com> wrote:
> > On my production FreeBSD VPN machine I am running ipfw as the
> > firewall. I have about 6 site-to-site vpn's going in and out of this
> > box. They are all attached to external clients
> > that I don't really want to give total access to my network. I would
> > like to replace this box with m0n0wall.
> > From the documentation on m0n0wall, I've gleaned that you cannot use
> > the firewall to limit access to specific machines if using the IPSEC
> > vpn. This seems strange to me, as I've beeing doing this for ages.
> > I used the /exec.php page to load the ipfw module, and did some tests
> > of my own. It seems that ipfw can block this access just fine. Is
> > there no way at all of having ipfilter do the same thing? I was using
> > a rule in ipfw such as this:
> > ipfw add allow all from 10.2.1.5 to 10.3.1.7
> > ipfw add deny all from 10.2.0.0/16 to any
> > This seems to block the traffic just fine. Is there a workaround to
> > make ipfilter work like this?
> I think the problem comes from the way ipfw and ipfilter are combined in
> m0n0wall: ipfilter does the actual traffic filtering and NAT. ipfw is
> used in combination with dummynet for traffic shaping only. It seems
> that ipfilter comes first for both incoming and outgoing packets.
> I guess (and hope) this limitation comes from m0n0wall's initial design
> and could be improved in future versions, but I may be wrong on this point.
> -- Vincent
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch