Replication and Imaging with Location Plugin

[blainey]

I’m have a storage node that exists on a separate network. For replication I have to put the WAN side IP for the master node to push replication to the node on the sub network. For imaging though, if I do not have the LAN side IP set for the node it tries to contact the WAN IP and fails.

Is there a way for replication to use the WAN IP and for imaging on that node to use the local IP?

It is failing at the point where it tries to mount the images folder and is using the WAN IP.

[EduardoTSeoane]

i’m doing that with only an ip, but loosing multicast., no special configurations needed if you have access to all services on the server. Maybe nfs ports are blocked on the router/firewall?

[blainey]

I do have NFS open on the firewall with port forwarding to the local ip.

When trying to mount the imaging folder is shows the path as “[external IP]:/images/ on /images failed: Connection Refused”

If on the master node i change the IP of the node from it’s WAN address to it’s Local address. This breaks replication but fixes imaging.

[EduardoTSeoane]

@blainey It is possible to access your internal server using the router’s public IP address/forwarded port, but your router must support loopback network address translation (a.k.a. hairpin NAT) and be configured accordingly.

Without loopback translation in effect, IP packets destined for your router’s public IP address will arrive on its private network interface. Here the packets are simply dropped, usually because the router requires packets destined for its public IP address to arrive on its physical WAN interface (there are other possible ways this traffic may be handled, including NAT occurring, but the end result is always that the connection cannot be completed).

However, with loopback translation configured, when the packets destined for the public address arrive on the private interface, their destination address will be rewritten to be that of the internal server. Then the normal port translation will be applied, further resulting in the destination port being rewritten as well.

There are other options.

[blainey]

OK so understood about configuring using Hairpin NAT. If some of my sites/labs do not have the ability to do the hairpin NAT, is there no way to have the Master use the WAN IP for replication and then have it pass the local LAN IP of the node during imaging to the client being imaged?

This would let me support the sites that cannot do the Hairpin Nat and also just in general stop me from altering the routers at 50+ sites.

[george1421]

I’m not sure I understand your problem just yet.

Let me see if I understand it using my words.

"I have fog servers and storage nodes with 2 network interfaces. One interface is dedicated to imaging on an isolated imaging network at each location. I want to setup a master->storage node replication between the fog server, but I want the replication to happen over the second network interface and not the isolated imaging network. "

Did I describe the situation?

[blainey]

@george1421

Here is my setup:

Master Server: 10.10.1.3
Node : 192.168.1.2(Local Network)
IP of node from Master Server Network: 10.10.1.4 (ports forwarded to 192.168.1.2)

I don’t actually have 2 network cards in the node. The servers are on two separate networks. I have opened ports to allow the replication and set the node ip to 10.10.1.4 but then when I go to image it tries to mount the image location on the node using the “public ip” (10.10.1.4) side of the gateway. This causes a connection refused message due to no loopback.

On the other hand. I can tell the Master server the node ip is 192.168.1.2.
This results in replication not working but imaging via the local node is successful.

Your example of 2 nics though would produce the same issue I believe.

[EduardoTSeoane]

@blainey @george1421 Ok, i do some experiments with this.
I do that with a few modifications on default.ipxe and bootmenu.class.php to get the boot information from dnsmasq as proxydhcp. Take care with internal server routing.

[Sebastian Roth]

@blainey Probably best if you post pictures of the storage node and location settings from the FOG web UI here.

[blainey]

@Sebastian-Roth Below is the configuration I am using. If I changes the storage node IP Address to the internet networks IP it will work but then replication does not work. ![0_1561473109851_Image Attempt.png]

[Sebastian Roth]

@blainey Ahh, now I see. I’ll need to check the code to see why the behavior of the different parts seem to be the way you describe it.

If I changes the storage node IP Address to the internet networks IP it will work but then replication does not work.

Can you possible as well post the full fogreplication.log so we have more information on what’s going on. The more information we have the better we are able to understand the issue. Your setup is kind of special in a way and I won’t be able to set this up here in my lab for testing and replicating the issue - simply as of limited time I have.

[Sebastian Roth]

@blainey While reading through the whole topic again and again I get the impression that it might be easier than expected. I think Eduardo is right about what he calls “hairpin NAT” but I think the term might be a bit missleading. When you use 10.10.1.4 as storage node IP the clients within the 192.168.1.x network try to contact their default gatway to reach out to that. Those requests come into your gateway on the wrong interface and usually get dropped.

On the other hand. I can tell the Master server the node ip is 192.168.1.2.
This results in replication not working but imaging via the local node is successful.

What if we tackle it from this side. I guess it still won’t be easy but can give it a try. Set the storage node IP in the web UI storage node settings to 192.168.1.2. Now with that you “only” need to make sure two things:

1. the Linux OS on your main FOG server needs to know how to reach 192.168.1.2 -> ip route add 192.168.1.0/24 via 10.10.1.4 dev eth0 (probably you need to set a different network interface than eth0 - just the one where 10.10.1.3 is configured to)
2. you have port forwards and rules on the gatway to allow FTP traffic through -> this might be a bit of an issue because FTP uses random ports as well as connections going both ways depending on the FTP mode used (active or passive - not sure which one we do really)

This setup will only work if the gateway doesn’t do NATing. If it does we need to find a different solution.