Date: Thu, 22 Feb 2007 22:06:29 -0800 From: "Bruce A. Mah" <bmah@freebsd.org> To: freebsd-net@freebsd.org Subject: Re: Bridge and NAT problems Message-ID: <45DE8465.8090507@freebsd.org> In-Reply-To: <45DDD156.3020805@netfence.it> References: <45DDABA6.60407@netfence.it> <45DDC9CD.1020207@freebsd.org> <45DDD156.3020805@netfence.it>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB793ED9C54D3406FEB908C49 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Andrea Venturoli wrote: > Bruce A. Mah wrote: >=20 >> You didn't say which bridging driver or version of FreeBSD you're usin= g, >> but it sounds to me like you're using bridge(4), right? >=20 > Yes. >=20 >=20 >=20 >> This is a >> fairly well known problem, which I wrote a little bit about here: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006075.ht= ml >> >> (This message describes a scenario with ipf, but it applies equally we= ll >> I think to ipfw.) >=20 > Read that. > So I guess my analysis was wrong in that I thought natd was not=20 > reconverting packets; from what you say I understand the problem is tha= t=20 > this packets are not diverted to natd, right? > The details are right now beyond my understanding... Without more details it's difficult to say. Not to be overly critical, but "does not work" from your original post isn't real helpful, unfortunately. If you had packet traces of, say, attempted pings, that would give a lot more data to help say exactly what the problem is. It just sounds *very* similar to a problem I spent a lot of time working on.= >> If you can, try switching to using if_bridge(4). >=20 > I cannot right now, since I have to wait to be physically at this box, = > but I could try in the future. Do you see any drawback? None I can think of. Note that bridge(4) is deprecated in RELENG_6 and is gone entirely from HEAD (in favor of if_bridge(4)). if_bridge(4) is also more featureful and is being actively worked on. >> You (probably) want to >> assign the public NAT address to the bridge0 interface, and leave the >> physical interfaces making up the bridges (xl0 and rl1 in your case) >> unnumbered. I've had good experiences with this type of configuration= =2E >=20 > Ok. > So I would only need to > create the bridge0 interface as per man page > sysctl net.link.bridge.ipfw=3D1 > sysctl net.link.bridge.pfil_onlyip=3D0 > change every reference to rl1 in my ipfw ruleset to bridge0 >=20 > Anything else? > Would everything work the same as now (apart from this "feature" which = > is causing me troubles)? I think that'll work, yes. (Caveat: If you are doing other filtering in ipfw you might need to make some additional adjustments, but if all you're doing is NAT/divert, "change every reference to rl1 ... to bridge0" should work just fine.) Bruce. --------------enigB793ED9C54D3406FEB908C49 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF3oRo2MoxcVugUsMRAgNXAKDjMr75CynlS6dPtMdTdE0Cg6hn1QCfWz6W YBphZyECbTdX2CTpQKKI9G8= =DtSh -----END PGP SIGNATURE----- --------------enigB793ED9C54D3406FEB908C49--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45DE8465.8090507>