Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] selecting a subnet



On Wed, Sep 10, 2014 at 06:59:51PM -0400, Bill Horne wrote:
> If by "Firewall" you mean Network Address Translation-enabled
> wired-only router, then it's a non issue. You plug the "WAN" port
> into your corporate network and set it for DHCP (or whatever fixed
> address your IT guys assigned to the port).  The router will
> translate whatever "detached" IP range you choose, e.g.,
> 192.168.255.0/24, and you'll be in business.

It is not a non-issue if you choose an IP subnet behind the NAT that
conflicts with the same/overlapping IP subnet somewhere else outside
the NAT.  For example, consider what would happen if you choose
8.8.8.0/24 as your inside NAT address space.  You wouldn't be able to
reach Google's nameserver on the Internet at 8.8.8.8 because that
address would be routed locally by your local hosts, rather that being
routed out to the Internet.  Now, hopefully no one would be silly
enough to choose a "public" non-RFC1918 network address for use behind
their NAT, but the issue is the same if you have a double-NAT scenario
and you choose an RFC1918 subnet that is already in use anywhere
outside your NAT (such as inside the outer NAT).  If you happen to
choose badly, you may not be able to reach some corporate server you
may need to access.

I was once visiting a friend who had set up their local RFC1918
network to use 192.168.122.0/24.  Unfortunately, this was also the
default subnet used by Fedora's KVM virtualization stack libvirtd,
which started up a virbr0 network bridge on the host addressed as
192.168.122.0/24 even if there were no guest VMs at all yet.  Hilarity
ensued when both wlan0 and virbr0 were configured with the same
subnet, but weren't actually the same physical network.  Nothing at
all worked in this "split-brain" scenario.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org