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: ste...@simplycircus.com On Wed, Sep 10, 2014 at 11:17 PM, Chuck Anderson <c...@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@blu.org > http://lists.blu.org/mailman/listinfo/discuss > > _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss