On 11/29/2011 11:27 AM, Ugo Bellavance wrote:
On 2011-11-29 10:59, David Burgess wrote:
On Tue, Nov 29, 2011 at 6:36 AM, Ugo Bellavance<u...@lubik.ca> wrote:
Did I fail to provide enough info?
I don't understand the question; you make some statements that don't
appear logical to me, for example, "we'd use NAT because we don't want
the traffic to go through core switches". I don't see how NAT is a
logical replacement for a core switch. Next example, "I know NAT is
not perfect, but it would keep things on L2". NAT is a L3 function; it
is an acronym for "Network Address Translation". If it were L2 then it
would more likely be called "Ethernet Address Translation", but that
doesn't really make sense and I don't think that's what you're talking
about.
Perhaps it would help if you included a diagram of what you are trying
to accomplish.
Ok, I must have expressed me incorrectly. Here is take 2:
We want to make a SIP trunk between the phone systems of Corp 1 and
Corp 2, which can be physically connected (in the same building).
Since the two corps have their own subnets, they would like to NAT.
I attached a diagram of what I would like to achieve.
BTW there was a mistake in my first subnet address in my original
post. It should state 172.30.100.0/24.
_______________________________________________
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list
Maybe you could bridge the left and right pfsense interfaces, disable
all filtering on bridged interfaces, and add IP aliases as needed to any
of the servers that needed to communicate at layer 3. If I remember
correctly, however, a bridged interface will not forward broadcast
traffic (and multicast???). At the same time, however, if you are
going to go to all of this trouble, a switch or hub would probably be a
much better fit.
_______________________________________________
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list
