On Mon, Apr 2, 2012 at 9:39 AM, Peter Eckel <li...@eckel-edv.de> wrote: > >> So what does that mean for a client application (http/ftp,etc.) where >> you might have local firewalls permitting things for internal-subnet >> source ranges but you also have external targets that only accept >> pre-configured static sources? > > Are you referring to the situation where you have several clients on the > internal network that use NAT to appear as one single IPv4 host to an > external server, which allows access based on that global outside NAT address?
Yes, we have relationships with outside services that require pre-registering the source addresses that will be used for access. In the NAT scenario, these become the public side of the gateways that might be used - a manageable number, even for a large cluster of internal hosts. And we have internal firewalling among subnets based on the private address ranges of the hosts. I'd assume this is a common, if not universal situation for organizations. > The situation is a bit different without NAT. Instead of filtering on a > single IPv4 address the external server would filter on a /64 IPv6 network. > Security-wise there is no difference as you'll never get smaller allocations > than /64 per site anyway, so what with respect to filtering was was a single > IPv4 address with IPv4/NAT is a /64 subnet with IPv6: A unique identifier of > the network connecting to the external server. Both with IPv4/NAT and IPv6 > the server only knows which network you are coming from, not which specific > host is trying to connect. > > When there really is a requirement that the external server allows only a > single address to access it and that can't be changed, you could resort to > using a proxy. What is typical or reasonable for source address restrictions? That is, if there are 2 global organizations, and one wants to increase the security on access to a service by limiting to the source addresses that might come from the other, is there a sane way to specify it, and to make the application use those addresses at the right times if the interface has others? -- Les Mikesell lesmikes...@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos