All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.