Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Feb 2007 08:50:21 -0800
From:      "Bruce A. Mah" <bmah@freebsd.org>
To:        freebsd-net@freebsd.org
Subject:   Re: Bridge and NAT problems
Message-ID:  <45DDC9CD.1020207@freebsd.org>
In-Reply-To: <45DDABA6.60407@netfence.it>
References:  <45DDABA6.60407@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)
--------------enig833EAB9C2153DA397D505D32
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If memory serves me right, Andrea Venturoli wrote:
> Hello.
> I've got the following problem...
> My host is configured like this:
>=20
> fxp0: internal interface, requires NAT
> rl1: public interface, with static IP
> xl0: bridged to rl1, with some public IP behind
>=20
> ipfw diverts any traffic through rl1 to natd, i.e. I have in ipfw
> 50 divert 8668 ip from any to any via rl1
>=20
>=20
> Internal <-> Internet works, as Internet <-> Bridged does.
> Internal <-> Bridged does not work.
>=20
> Let's suppose I'm pinging from the inside to a bridged machine: the ICM=
P=20
> packet comes in through fxp0 and is allowed, gets NATted going out by=20
> rule 50 and reaches the target hosts (I guess bridging is also happenin=
g=20
> to send it out via xl0 instead of rl1).
> The target answers to the public IP of this box and the packet comes in=
=20
> via xl0, so it's not back-NATted and gets lost.
>=20
> I then tought of diverting to natd every packet through xl0 (i.e. 60=20
> divert 8668 ip from any to any via xl0), but this doesn't work either. =

> The packet gets to natd by means of rule 60, but natd does not recogniz=
e=20
> it as an answer to a previously examined packet.
>  From man pages I understood that natd does not take interface into=20
> account, but only source and destination IP:port. Then, what's wrong?
>=20
> Any suggestion?

You didn't say which bridging driver or version of FreeBSD you're using,
but it sounds to me like you're using bridge(4), right?  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.html

(This message describes a scenario with ipf, but it applies equally well
I think to ipfw.)

If you can, try switching to using if_bridge(4).  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.

Bruce.


--------------enig833EAB9C2153DA397D505D32
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

iD8DBQFF3cnN2MoxcVugUsMRAqRSAJ0Vhuo9W1jVAialwnteIzNFGEszPQCfbBy8
wNml5KF/g9GqOssUNb26JZo=
=3aLo
-----END PGP SIGNATURE-----

--------------enig833EAB9C2153DA397D505D32--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45DDC9CD.1020207>