irods behind NAT/PAT

[alsmith20000]

Hello

I see that there is in fact a related chat here: https://groups.google.com/g/irod-chat/c/GOQ2szx_OXA/m/iBxqA0loAwAJ

I've had a look at the man page for the hosts_config.json file also: https://docs.irods.org/4.2.8/system_overview/configuration/#etcirodshosts_configjson but I'm not sure that I properly understand it's usage.

My situation is that I have an irods server with co-located icat, which is presenting a unix resource. The VM has an non-routable IP address (10.x.x.x), which my institution is routing internally anyway. It can be accessed from outside for federation only to a specific other remote machine via a NAT/PAT (configured at my institution), where a 1:1 connection between the public address of the PAT has been made to the VM.

I now have federated access to iget/iput data to the remote iRODS machine. However the remote VM cannot run iputs or igets on my server because the resource ip address sent back is the internal one, not the public ip used for the external connection.

It isn't quite clear how I might use the hosts_config.json file to sort this out but it's hinted at the top of the chat that I mentioned that it can be used this way.

Unlike the chat above, I don't have direct access to the NAT/PAT as this is run by a different team and I don't anticipate that they have the same level of configurability as haproxy does.

Ideally, what I need is for some functionality where a server/client with a public ip address requests a resource to be given the public NAT/PAT ip address for the resource server and if the client/server is an internal one to just be given the 10.x.x.x ip address.

It may be possible to set things up so that even internal client traffic came in through the public ip address.

I want to be careful though that even traffic internal to the irods VM has to go out to the edge NAT/PAT.

Could any one advise me please? If I've been unclear then (sorry), I will try to answer questions though.

Many thanks

Alastair

[Tony Edgin]

Hi Alastair.

If you set the "irods_host" field in iRODS server's irods_environment.json to the public IP address the VM presents as, you should be able access the resource server. This works outside of federation. I haven't tested this with federation though.

Cheers,

Tony

--
--
The Integrated Rule-Oriented Data System (iRODS) - https://irods.org
 
iROD-Chat: http://groups.google.com/group/iROD-Chat
---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/irod-chat/c6de6d10-3b84-487e-a381-24ce0f5025a4n%40googlegroups.com.

[Tony Edgin]

Hi again.

I only gave you half the solution.  You need to edit hosts_config.json as well. As you suspected, an entry in hosts_config is needed. It should look something like the following

        {
            "address_type": "local",
            "addresses": [
                { "address": "129.1.6.1" },
                { "address": "10.x.x.x" }
            ]
        }

I'm sorry about that.

[alsmith20000]

Thanks very much for this Tony. I haven't implemented this yet as the firewall rules for the external IP are managed by another team and a little illusive.
Is the expected behaviour if I connect with the irods client to this machine, that it will push me over to the public IP address?

Would it just be for large file transfers or also for basic irods lookups and other metadata based communications (ils, iquest, etc.)?

I have forgotten if you're a developer Tony but do you know if RenCI, considered something analogous to routing tables for iRODS. e.g. if you're IP matches this subnet mask then you can use IP A for a certain resource and if another mask matches then use IP B for the resource?

Many thanks

Alastair

[Tony Edgin]

If the iRODS server has a domain name, you can use that instead of the public IP address.

I would expect all communication with the client to happen over the public network.  I thought your client was running on the public network. If it isn't that I misunderstood and gave you a solution to a different problem. I'm sorry for any confusion.

I'm not an iRODS developer, so I don't know if they've considered client IP based routing like you describe.  You could do that by setting up a proxy in front of iRODS though.

Cheers,

Tony

To view this discussion on the web visit https://groups.google.com/d/msgid/irod-chat/d9592ee9-a85d-4b68-b61f-181a9c597644n%40googlegroups.com.

[alsmith20000]

Hi again Tony

Sorry for the confusion, there are basically two problems: there will be a small number of local users and there will be a remote irods server that is part of a federation. The remote irods server will need to come in through the public IP and the user clients may come in through the local IP (10.x.x.x)

Thanks again

Alastair

[Tony Edgin]

Oh, ok. I think I understand your setup. I haven't tried anything exactly like that. Have you tried modifying your configurations like in the following example?

Pretend you have the following setup.

Your local iRODS server:

zone: local

zone key:  localkey

private IP address: 10.0.0.1

FQDN: data.local.org (DNS maps to a public IP address, and institutional NAT translates address to 10.0.0.1)

The remote iRODS server:

zone: remote

zone key: remotekey

FQDN: data.remote.org

The shared federation negotiation key is negotiationkey.

On the remote iRODS server, the following object has been added to the "federation" array in /etc/irods/server_config.json.

{

    "catalog_provider_hosts": [ "data.local.org" ],

    "negotiation_key": "negotiationkey",

    "zone_key": "localkey",

    "zone_name": "local"

}

On the local iRODS server, the following object has been added to the "federation" array in /etc/irods/server_config.json.

{

    "catalog_provider_hosts": [ "data.remote.org" ],

    "negotiation_key": "negotiationkey",

    "zone_key": "remotekey",

    "zone_name": "remote"

}

Also, in /etc/irods/server_config.json, the "host_resolution"."host_entries" array has an object like the following in it.

{

    "address_type": "local",

    "addresses": [

        "10.0.0.1",

        "data.local.org"

    ]

}

If that doesn't work, you might need to make the local iRODS server think it is named data.local.org. To do this, set "irods_host" in /var/lib/irods/.irods/irods_environment.json to "data.local.org", and modify its /etc/hosts so that the server resolves "data.local.org" as 127.0.0.1.  I'm not certain, but you might need to change "catalog_provider_hosts" in /etc/irods/server_config.json to [ "data.local.org" ].

I hope this is helpful.

Tony

To view this discussion on the web visit https://groups.google.com/d/msgid/irod-chat/e1706c70-5f87-49ab-a960-713a1d501ff6n%40googlegroups.com.