* NAT to one net, bridge to another
@ 2006-09-08 11:50 Mike Williams
2006-09-14 6:51 ` Jan Engelhardt
2006-09-14 11:41 ` Pascal Hambourg
0 siblings, 2 replies; 5+ messages in thread
From: Mike Williams @ 2006-09-08 11:50 UTC (permalink / raw)
To: netfilter
Hey,
Sometime in the next couple months we're going to be replacing a large part of
our infrastructure to increase the already excellent reliability (dual nics
and psus everywhere, etc).
I'm just speccing up some kit for quote, and I'm slightly undecided as to the
best things I can do with the firewalls.
At the moment I'm looking at NATting stuff to 3 different zones (private
networks), and hopefully bridging to a 4th zone.
It'll have 10 nics, all paired off into round-robin bonds, so 5 usuable
interfaces. 1 colo facing, 3 private, 1 "public".
Can you DNAT packets to IPs X, and Y, Z assigned to a bridge, while bridging
those IPs not assigned to it?
(There is probably going to be a small amount of firewalling on the bridged
IPs)
Thanks
--
Mike Williams
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NAT to one net, bridge to another
2006-09-08 11:50 NAT to one net, bridge to another Mike Williams
@ 2006-09-14 6:51 ` Jan Engelhardt
2006-09-14 11:41 ` Pascal Hambourg
1 sibling, 0 replies; 5+ messages in thread
From: Jan Engelhardt @ 2006-09-14 6:51 UTC (permalink / raw)
To: Mike Williams; +Cc: netfilter
>Can you DNAT packets to IPs X, and Y, Z assigned to a bridge, while bridging
>those IPs not assigned to it?
I don't get it from your description, but DNATing packets that will
be bridged after DNAT rather than routed will not work.
>(There is probably going to be a small amount of firewalling on the bridged
>IPs)
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NAT to one net, bridge to another
2006-09-08 11:50 NAT to one net, bridge to another Mike Williams
2006-09-14 6:51 ` Jan Engelhardt
@ 2006-09-14 11:41 ` Pascal Hambourg
2006-09-14 12:07 ` Mike Williams
1 sibling, 1 reply; 5+ messages in thread
From: Pascal Hambourg @ 2006-09-14 11:41 UTC (permalink / raw)
To: netfilter
Hello,
Mike Williams a écrit :
>
> At the moment I'm looking at NATting stuff to 3 different zones (private
> networks), and hopefully bridging to a 4th zone.
> It'll have 10 nics, all paired off into round-robin bonds, so 5 usuable
> interfaces. 1 colo facing, 3 private, 1 "public".
What interfaces do you plan to bridge ?
> Can you DNAT packets to IPs X, and Y, Z assigned to a bridge, while bridging
> those IPs not assigned to it?
First, bridging and DNAT don't take place at the same network layer.
Bridging takes place at layer 2 and DNAT at layer 3 or 4. You bridge
ethernet frames (possibly transporting IP packets but it doesn't matter)
according to their MAC addresses, and this process is transparent for
the TCP/IP stack. You DNAT IP datagrams (possibly transported in
ethernet frames) according to their IP addresses and TCP or UDP ports. A
bridge can be considered as a virtual ethernet switch whose ports are
the bridged interfaces. On the host, it creates a bridge interface
"hiding" the bridged interfaces, just as a bond interface hide the
enslaved interfaces. So the kernel routing and Netfilter/iptables will
only see packets from the bridge interface, not those from the bridged
interfaces.
I assume you plan to bridge the "colo" and "public" interfaces.
colo public
| |
| |
bridge interface
|
|
TCP/IP stack (routing, iptables, NAT, filtering)
| | |
| | |
private interfaces
The bridge catches incoming ethernet frames before the IP stack can see
them. So an ethernet frame forwarded from colo to public does not hit
the IP stack, unless it is an ethernet broadcast.
To try to answer your question, you can DNAT IP datagrams transported by
ethernet frames which are not bridged to another interface.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: NAT to one net, bridge to another
2006-09-14 11:41 ` Pascal Hambourg
@ 2006-09-14 12:07 ` Mike Williams
2006-09-14 12:53 ` Pascal Hambourg
0 siblings, 1 reply; 5+ messages in thread
From: Mike Williams @ 2006-09-14 12:07 UTC (permalink / raw)
To: netfilter
On Thursday 14 September 2006 12:41, Pascal Hambourg wrote:
> > It'll have 10 nics, all paired off into round-robin bonds, so 5 usuable
> > interfaces. 1 colo facing, 3 private, 1 "public".
>
> What interfaces do you plan to bridge ?
bond0 to bond4 (probably). bond0 being the link to the colo, bond4 to
the "public" servers.
bond{1,2,3} private networks.
[snip lots of very useful information]
> I assume you plan to bridge the "colo" and "public" interfaces.
Yes, your diagram is correct.
> The bridge catches incoming ethernet frames before the IP stack can see
> them. So an ethernet frame forwarded from colo to public does not hit
> the IP stack, unless it is an ethernet broadcast.
Or destined for an IP/MAC assigned to the bridge interface?
That also explains the necessity for ebtables in addition to ip[6]tables.
> To try to answer your question, you can DNAT IP datagrams transported by
> ethernet frames which are not bridged to another interface.
Thanks very much, exactly what I wanted to hear.
--
Mike Williams
--
Mike Williams
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: NAT to one net, bridge to another
2006-09-14 12:07 ` Mike Williams
@ 2006-09-14 12:53 ` Pascal Hambourg
0 siblings, 0 replies; 5+ messages in thread
From: Pascal Hambourg @ 2006-09-14 12:53 UTC (permalink / raw)
To: netfilter
Mike Williams a écrit :
>
>>The bridge catches incoming ethernet frames before the IP stack can see
>>them. So an ethernet frame forwarded from colo to public does not hit
>>the IP stack, unless it is an ethernet broadcast.
>
> Or destined for an IP/MAC assigned to the bridge interface?
If a unicast ethernet frame is destined for the MAC address assigned to
the bridge interface, there is no reason that it is forwarded from an
interface of the bridge to another. Ethernet broadcast is an exception
because the frame is forwarded to all the other interfaces of the bridge
and to the IP stack. I guess that multicast ethernet frames have a
special processing too, but I don't know much about this subject.
> That also explains the necessity for ebtables in addition to ip[6]tables.
Yes, ip[6]tables works at the the network layer (routing) and ebtables
at the link layer (bridging).
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-09-14 12:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-08 11:50 NAT to one net, bridge to another Mike Williams
2006-09-14 6:51 ` Jan Engelhardt
2006-09-14 11:41 ` Pascal Hambourg
2006-09-14 12:07 ` Mike Williams
2006-09-14 12:53 ` Pascal Hambourg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.