Archived

This forum has been archived. Please start a new discussion on GitHub.

Use of IceGrid on both sides of NAT device

Dear Ice Support Team,

I need to use IceGrid on both sides of NAT device, i.e. IceGrid nodes should run on these both sides creating one common domain. Moreover, IceGrid registry should be accessible on both sides. I know that I can use published endpoints feature. However, then all requests will be directed with the public IP address what is undesirable in my case (behind the NAT the public IP addresses used by it for translation are not routed). In any other case I usually use two adapters, one is configured with "endpoints", the oher with both "endpoints" and "published endpoints". Association between objects and servants is added to both OA's ASMs. In this case I am unable to use additional OA since I do not want to modify icegridnode and icegridregistry.

My question is: how to solve this problem (ideally, not using Glacier)?

Best regards,
Łukasz

Comments

  • benoit
    benoit Rennes, France
    Hi,

    It's difficult to answer without more information on your deployment. What are the applications on the public side of the NAT? Can there be IceGrid nodes and servers or is it just clients resolving endpoints with the IceGrid registry? A detailed description of the different applications of your IceGrid deployment (in the context of the NAT) and how they interact with each other would be good to see how this can be solved.

    Cheers,
    Benoit.
  • Hi Benoit,

    The application which I am going to run on the two sides of the NAT will consist both of IceGridNodes and servers deployed inside them (with no replication) as well as clients. More precisely: there are a few companies (each using NAT) which want to run an distributed application on their infrastructure using private IP addresses. One of the companies will host IceGridRegistry. This is why I need to have the possibility to contact the nodes and the registry using both private and public addresses. Unfortunately the "published endpoint" feature disables using private addresses when it is configured (callbacks are directed to the public socket). So, in my opinion the only possible solution is to have two separate OAs - as I wrote yesterday. This seems difficult/impossible when considering "closed" services such as IceGrid nodes.

    Best regards,
    Łukasz
  • benoit
    benoit Rennes, France
    Hi,

    It's also possible to publish both endpoints, the private and public one. However, this means that the Ice client might fail to connect to one of the endpoint depending on where it is, it could also possibly connect to a unexpected server if different private IP networks have the same IP addresses... So this solution isn't a good option either.

    The simplest in such a scenario is to create a virtual private network where IceGrid and the application servers would be deployed. Did you consider this option?

    Cheers,
    Benoit.
  • Hi,
    benoit wrote: »

    The simplest in such a scenario is to create a virtual private network where IceGrid and the application servers would be deployed. Did you consider this option?

    Yes, of course, but there can be a number of new issues connected with it (not concerning Ice).

    Thanks a lot,
    Łukasz
  • Possible solution

    Hi Łukasz,

    Based on your input I'm not certain if this is a solution that's applicable to your setup, but one way to solve this could be using split horizon DNS - making your icegrid services hand out host names instead of IP addresses and make those resolve to different IP addresses depending on if you're on the public or private side of the NAT.

    The most primitive way to deploy this is using entries in /etc/hosts, e.g.

    Ice grid master config:
    Ice.Default.Host=icegridregistry
    IceGrid.Registry.Client.Endpoints=default -p 4062
    ...
    

    Grid master /etc/hosts (and internal clients):
    192.168.100.200    icegridregistry
    

    External clients /etc/hosts:
    200.200.100.100    icegridregistry
    

    In case /etc/hosts is too much hassle or you have to scale to a larger number of clients you could deploy a real split horizon DNS solution, in which you run a special DNS cache that resolves to the public IPs when accessed from the public internet and to your local IP addresses when access from within the NAT. This is not too hard to setup, commercial firewall solutions (e.g. cisco) also provide such a functionality out of the box.

    References:
    Cheers,
    Michael