Publicly accessible EOS on hosts with private primary addresses

Hi,

We’ve been experimenting with the networking configuration for our EOS hosts, for our a CTA instance. One option that was preferred (from a site networking perspective) was to have the EOS hosts primary addresses as private addresses, and add externally accessible addresses to the hosts that need external access (e.g. the EOS nodes). This has a number of advantages for security and network design, but I have concerns about how EOS is going to cope with this setup.

In basic testing, we ran into the somewhat expected redirection issues with external clients being redirected to FST’s primary addresses, but also other odd issues (e.g. external ‘eos ls’ command work fine, but ‘xrdfs ls’ commands stall as the client gets redirected to the MGM’s private address).
We experimented with defining the split network topology in the various EOS XRootD config files, which didn’t seem to make a difference, FSTs and MGMs still appear in EOS as their ‘private’ hostnames, and redirections to the private addresses still occur.

Does anyone run EOS with this sort of network configuration, or are there good reasons why this isn’t going to work (e.g. it isn’t designed to work like this) and we should simplify our network configuration?

Thanks,
Tom

FSTs are registered by name in the MGM and the name is derived from the hostname configured. The hostname on the FST has to be resolved to the public address.
FSTs and MGM have to be public accessible by design, otherwise clients cannot talk to them. Another issue is that we run all connection in EOS by name and not by IP. To have SSS security between FSTs working, one has to have identical bidrectional lookups from IP<=>HOSTNAME.

Redirection in EOS is by name. So you can have the DNS lookup outside your institute pointing to the public addresse, while inside you overwrite them to the private addresses. That works. But you can not have different FQDNs for public and private addresses e.g. you cannot configure EOS with the private FQDN and assume that EOS returns the public address if the client is external to your site. This could be implemented, but it is not and I don’t see any real advantage in such a configuration complicating also the debugging since EOS xrootd services have anyway to be public. Cheers Andreas.

Hi Andreas,

Many thanks, I think that answers my question perfectly.

Cheers,
Tom