Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #4138 > unrolled thread

Separate two network bridges on linux

Back to article view | Back to comp.os.linux.networking

Contents

  Separate two network bridges on linux Kevin Osthoff <icepic1984@gmx.de> - 2018-06-21 22:11 +0200
    Re: Separate two network bridges on linux Grant Taylor <gtaylor@tnetconsulting.net> - 2018-06-21 12:30 -0600
      Re: Separate two network bridges on linux Kevin Osthoff <icepic1984@gmx.de> - 2018-06-21 23:52 +0200
        Re: Separate two network bridges on linux Grant Taylor <gtaylor@tnetconsulting.net> - 2018-06-21 16:37 -0600
        Re: Separate two network bridges on linux Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-06-22 21:27 +0200
          Re: Separate two network bridges on linux Kevin Osthoff <icepic1984@gmx.de> - 2018-06-23 00:16 +0200
    Re: Separate two network bridges on linux Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-06-21 19:36 +0000
      Re: Separate two network bridges on linux Kevin Osthoff <icepic1984@gmx.de> - 2018-06-21 23:59 +0200
        Re: Separate two network bridges on linux Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-06-21 20:39 +0000
        Re: Separate two network bridges on linux Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-06-22 11:14 +0300
          Re: Separate two network bridges on linux Kevin Osthoff <icepic1984@gmx.de> - 2018-06-22 20:18 +0200
            Re: Separate two network bridges on linux Grant Taylor <gtaylor@tnetconsulting.net> - 2018-06-22 12:35 -0600
              Re: Separate two network bridges on linux Kevin Osthoff <icepic1984@gmx.de> - 2018-06-23 00:10 +0200
                Re: Separate two network bridges on linux Grant Taylor <gtaylor@tnetconsulting.net> - 2018-06-22 14:36 -0600
                  Re: Separate two network bridges on linux Richard Kettlewell <invalid@invalid.invalid> - 2018-06-22 22:23 +0100
                    Re: Separate two network bridges on linux Grant Taylor <gtaylor@tnetconsulting.net> - 2018-06-22 15:37 -0600
                Re: Separate two network bridges on linux Grant Taylor <gtaylor@tnetconsulting.net> - 2018-06-22 15:46 -0600
                Re: Separate two network bridges on linux Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-06-22 22:45 +0000
                  Re: Separate two network bridges on linux Grant Taylor <gtaylor@tnetconsulting.net> - 2018-06-22 17:38 -0600
      Re: Separate two network bridges on linux Grant Taylor <gtaylor@tnetconsulting.net> - 2018-06-21 16:40 -0600
        Re: Separate two network bridges on linux Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-06-22 05:38 +0000
      Re: Separate two network bridges on linux Stefan Monnier <monnier@iro.umontreal.ca> - 2018-06-21 22:01 -0400
        Re: Separate two network bridges on linux Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-06-22 05:54 +0000
          Re: Separate two network bridges on linux Grant Taylor <gtaylor@tnetconsulting.net> - 2018-06-22 13:40 -0600
            Re: Separate two network bridges on linux Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-06-23 06:36 +0000
            Re: Separate two network bridges on linux Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-06-23 20:18 +0300

Page 2 of 2 — ← Prev page 1 [2]

#4147

On Thu, 2018-06-21, Grant Taylor wrote:
> On 06/21/2018 01:36 PM, Jorgen Grahn wrote:
>> Why not do it the straightforward way -- just a router with three networks 
>> attached, and NATing against the internet on a fourth interface?
>> 
>>      +-----+
>> world|     +---- 196.168.1/24 ethernet
>> -----+     +---- 196.168.2/24 wifi
>>      |     +---- 196.168.3/24 guest wifi
>>      +-----+

(I meant 192.168 of course, or some other private range.)

>> That would make it easier to reason about.
>
> It looks like Kevin has two sets of networks, both of which are wired 
> and wireless.  I'm guessing that he wants {home,guest} wired and 
> wireless to be connected so that wired and wireless devices can 
> communicate with each other.

For wireless I wouldn't want people nearby who know the guest password
and sniff all traffic, but I don't see the point of the /wired/ guest
network (for a home).

Personally I think I'd be comfortable allowing guests to use my main
wired network.  There are no hidden, vulnerable services there.

> home wired can talk to home wireless

Useful, and also the default way a router works.

> guest wired can talk to guest wireless
> home {wired,wireless} can't talk to guest {wired,wireless}.

So the purpose of attaching to the guest network is just to get
internet access, not use local services on the home network.  A simple
firewall rule on the router feels like the right choice.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#4146

> Why not do it the straightforward way -- just a router with
> three networks attached, and NATing against the internet on
> a fourth interface?
>
>      +-----+
> world|     +---- 196.168.1/24 ethernet
> -----+     +---- 196.168.2/24 wifi
>      |     +---- 196.168.3/24 guest wifi
>      +-----+
>
> That would make it easier to reason about.

Actually, his setup is already even simpler:

         +-----+
    world|     +---- 196.168.10.0/24 bridge0
    -----+     +
         |     +---- 196.168.20.0/24 bridge1
         +-----+

He needs iptables to stop the flow between the two bridges, just like in
your example, you'd need iptables rules to stop the flow between "guest
wifi" and "wifi".


        Stefan

[toc] | [prev] | [next] | [standalone]

#4148

On Fri, 2018-06-22, Stefan Monnier wrote:
>> Why not do it the straightforward way -- just a router with
>> three networks attached, and NATing against the internet on
>> a fourth interface?
>>
>>      +-----+
>> world|     +---- 196.168.1/24 ethernet
>> -----+     +---- 196.168.2/24 wifi
>>      |     +---- 196.168.3/24 guest wifi
>>      +-----+
>>
>> That would make it easier to reason about.
>
> Actually, his setup is already even simpler:
>
>          +-----+
>     world|     +---- 196.168.10.0/24 bridge0
>     -----+     +
>          |     +---- 196.168.20.0/24 bridge1
>          +-----+

Thanks.  I always have to be reminded what a bridge interface is.
(I think of it as two real interfaces and a fake one, connected by a
switch.)

That would give one actual benefit: a host can go from wireless to
Ethernet without dropping off the network or being renumbered.
So yes, bridging is better.  (Unless there are performance drawbacks
to bridging wired and wireless networks.)

I still don't get the talk about dnsmasq and special DHCP setups
though.  Either setup above should need just the usual services on the
router:

- DHCP (and IPv6 router advertisement) for two networks
- NAT
- DNS and possibly NTP

> He needs iptables to stop the flow between the two bridges, just like in
> your example, you'd need iptables rules to stop the flow between "guest
> wifi" and "wifi".

Yes.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#4153

On 06/21/2018 11:54 PM, Jorgen Grahn wrote:
> Thanks.  I always have to be reminded what a bridge interface is. 
> (I think of it as two real interfaces and a fake one, connected by 
> a switch.)

I think that's a fair way to think about bridging as that's often how 
it's used.

Though there is no hard requirement for physical interfaces.  It's also 
possible to have a bridge with one member interface.  Virtualization 
uses bridges in some less typical applications and ways.

> That would give one actual benefit: a host can go from wireless to 
> Ethernet without dropping off the network or being renumbered.

Bridging does connect the wired and wireless into a common network as if 
it was one big network.

However it is unlikely that a host will be able to move from wired to 
wireless directly.  Wireless NICs can't connect to wired ports and wired 
ports can't connect to wireless.  ;-)  You will very likely have two 
different NICs which means two different MAC addresses and extremely 
likely two different IP addresses.

> So yes, bridging is better.  (Unless there are performance drawbacks to 
> bridging wired and wireless networks.)

Bridging has it's uses.  I don't know if it's better or worse.  It 
really depends on what you are trying to do.

> I still don't get the talk about dnsmasq and special DHCP setups though. 
> Either setup above should need just the usual services on the router:
> 
> - DHCP (and IPv6 router advertisement) for two networks
> - NAT
> - DNS and possibly NTP

I do not recall seeing the talk about dnsmasq (which is a DNS and DHCP 
server) or special DHCP setups.  So I can't comment on that.

Any time you have multiple networks, you need to configure the DHCP 
server to be aware of the multiple networks.

Depending on how NAT is configured, this may or may not require a 
special configuration.

DNS and NTP should be fairly agnostic.  Though I can see a configuration 
that may require modification.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4162

On Fri, 2018-06-22, Grant Taylor wrote:
> On 06/21/2018 11:54 PM, Jorgen Grahn wrote:

[bridging wired and wireless on the router]

>> That would give one actual benefit: a host can go from wireless to 
>> Ethernet without dropping off the network or being renumbered.
>
> Bridging does connect the wired and wireless into a common network as if 
> it was one big network.
>
> However it is unlikely that a host will be able to move from wired to 
> wireless directly.  Wireless NICs can't connect to wired ports and wired 
> ports can't connect to wireless.  ;-)  You will very likely have two 
> different NICs which means two different MAC addresses and extremely 
> likely two different IP addresses.

Ah, yes, of course.  You'd get addresses in the same IP network both
when wired and wireless, but that's not useful in itself, as far as I
can tell.

>> So yes, bridging is better.  (Unless there are performance drawbacks to
>> bridging wired and wireless networks.)
>
> Bridging has it's uses.  I don't know if it's better or worse.  It
> really depends on what you are trying to do.

I meant "bridging is better /for the OP/", when I still believed it
would make it less of a pain for a user to go from wired to wireless
and back.

>> I still don't get the talk about dnsmasq and special DHCP setups though. 
>> Either setup above should need just the usual services on the router:
>> 
>> - DHCP (and IPv6 router advertisement) for two networks
>> - NAT
>> - DNS and possibly NTP
>
> I do not recall seeing the talk about dnsmasq (which is a DNS and DHCP 
> server) or special DHCP setups.  So I can't comment on that.

A dnsmasq setup was mentioned in the original posting; I think it has
been ignored in the replies.

> Any time you have multiple networks, you need to configure the DHCP 
> server to be aware of the multiple networks.
>
> Depending on how NAT is configured, this may or may not require a 
> special configuration.
>
> DNS and NTP should be fairly agnostic.  Though I can see a configuration 
> that may require modification.

Sounds right.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#4163

On 22.6.18 22:40, Grant Taylor wrote:
> 
>> I still don't get the talk about dnsmasq and special DHCP setups 
>> though. Either setup above should need just the usual services on the 
>> router:
>>
>> - DHCP (and IPv6 router advertisement) for two networks
>> - NAT
>> - DNS and possibly NTP
> 
> I do not recall seeing the talk about dnsmasq (which is a DNS and DHCP 
> server) or special DHCP setups.  So I can't comment on that.
> 

Here you are: dnsmasq.conf for a raspberry Pi running OpenVPN,
firewall, dnsmasq and NTP. To split the only Ethernet port to
outside and inside networks, a virtual LAN switch (3C17300)
is used, and the connection to the inside network is on vlan1.

The virtual private network by OpenVPn is on tun0.

Dnsmasq provides DNS cache and service from /etc/hosts, and
DHCP (could also provide BOOTP/TFTP booting, details dropped).
The local computer names (bigmac etc.) are taken from /ect/hosts.

NTP is handled by a separate daemon. The DHCP server directs
NTP questions from clients to the local NTP server.

NAT is taken care of by iptables.

--- clip clip ---

#	/etc/dnsmasq.conf for raspberry
#

# Never forward addresses in the non-routed address spaces.

bogus-priv

# Add local-only domains here, queries in these domains are answered
# from /etc/hosts or DHCP only.

local=/localdomain/
local=/openvpn/

# If you want dnsmasq to listen for DHCP and DNS requests only on
# specified interfaces (and the loopback) give the name of the
# interface (eg eth0) here.
# Repeat the line for more than one interface.

interface=vlan1
interface=tun0

# Set this (and domain: see below) if you want to have a domain
# automatically added to simple names in a hosts-file.

expand-hosts

# Uncomment this to enable the integrated DHCP server, you need
# to supply the range of addresses available for lease and optionally
# a lease time. If you have more than one network, you will need to
# repeat this for each network on which you want to supply DHCP
# service.

dhcp-range=192.168.42.16,192.168.42.22,2h

# Supply parameters for specified hosts using DHCP. There are lots
# of valid alternatives, so we will give examples of each. Note that
# IP addresses DO NOT have to be in the range given above, they just
# need to be on the same network. The order of the parameters in these
# do not matter, it's permissble to give name,adddress and MAC in any order

dhcp-host=00:20:18:80:f1:5e,greg,12h
dhcp-host=00:a0:24:43:89:2d,dustpuppy,12h
dhcp-host=00:23:32:2e:a7:e4,00:23:32:2e:a7:e5,bigmac,12h
dhcp-host=00:23:32:c8:9b:40,macbook,12h
dhcp-host=b8:27:eb:d3:4b:a1,pi2,12h
dhcp-host=08:00:20:78:6b:05,erwin,12h

# Set DNS server to clients from dnsmasq

dhcp-option=6,0.0.0.0

# Set the NTP time server address to be the same machine as
# is running dnsmasq

dhcp-option=42,0.0.0.0

# If you want dnsmasq to detect attempts by Verisign to send queries
# to unregistered .com and .net hosts to its sitefinder service and
# have dnsmasq instead return the correct NXDOMAIN response, uncomment
# this line. You can add similar lines to do the same for other
# registries which have implemented wildcard A records.

bogus-nxdomain=64.94.110.11

---clip clip ---

-- 

-TV

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.networking

csiph-web