Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


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

[Discuss] selecting a subnet



If youe corp network uses addresses in the 192.168.0.0 range, how about
using an address in the 10.0.0.0 range?

---
Steven Santos
Director
Simply Circus, Inc.
86 Los Angeles Street
Newton, MA 02458

P: 617-527-0667
F: 617-934-1870
E: Steven at SimplyCircus.com

On Wed, Sep 10, 2014 at 11:17 PM, Chuck Anderson <cra at wpi.edu> wrote:

> 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.
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>
>



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