Problem with Windows Cluster IPs

[Ivangi]

Hi all
We have a Microsoft Windows cluster with two nodes, with IPs xxx.yyy.zzz.12 and xxx.yyy.zzz.13, and a resource on that cluster with IP xxx.yyy.zzz.11, which can run on any of both nodes.
The problem we have with recent versions of FZS is that when we connect with a client against the resource (xxx.yyy.zzz.11), FZS send the response via node physical IP (.12 or .13), and this causes our corporate firewall reject that response because it doesn't correspond to the same session (different IPs).
Version of FZS 0.9.60 worked fine, responding allways from the same IP that receive the request.
Is there any tweek to make new versions to act as that old one?
Thanks in advance

[oibaf]

When FileZilla Server is configured to listen on the IP address 0.0.0.0 (which means listening on all available network interfaces) or a specific address like xxx.yyy.zzz.11, and a client initiates a connection to this server at xxx.yyy.zzz.11, FileZilla Server will send its responses from the source address xxx.yyy.zzz.11. This behavior is consistent with standard TCP operations and is expected from any TCP-based server.

If you observe that the responses from FileZilla Server are originating from a different IP address, it implies that an intermediate network device or service is modifying or rerouting the traffic between FileZilla Server and the client.

[Ivangi]

Hi Fabio
Version 0.9.60 acts in that manner, but all recent versions I have try responds allways from IP of physical node, and servers, network and all other hardware and software are exactly the same.
Do you know about any software that could be doing that change of source IP?

[oibaf]

I would first like to understand why you say that FileZilla Server is responding from a different address, can you show logs or other kind of diagnostic that makes you say that?

[Ivangi]

I've attached the firewall log. FTP client is on the machine with IP .167.11, and the FileZilla server is on a physical machine with IP .36.12, but cluster IP is .36.11.
First two lines corresponds to an FTP made against Filezilla Server 0.9.60, and as you can see, FZS reply comes from IP .36.11.
Next 6 lines corresponds to FZS 1.7.3, and here you have a conection from .167.11 to .36.11, but replies come from .36.12, and our corporate firewall rejects them because there are not from the same "session".

[botg]

Please clarify what exactly you mean by "reply".

[Ivangi]

Sorry, it should be answer.

[botg]

Please clarify, what exactly do you mean by "answer"?

[oibaf]

Hello,

Assuming that by "response" you refer to what the server sends back to the client, I have some questions.

1. Do you have different rules for the old server and the new server?
2. Is there some NAT'ing going on?
3. Is the old server using TLS?
4. Is the new server using TLS?
5. Does the "faulty" response come on the data connection, or the control connection?
6. Which firewall are you using?

[Ivangi]

Hi Fabio
"Response" is exactly that.
1. The server is allways the same. The only thing that changes is the version of FZS installed on it.
2. No NATing.
3. No TLS.
4. No TLS.
5. I think that it's on data connection.
6. Our corporate firewall is FortiGate.

[oibaf]

Ok, we might have a lead.

Which is the mode of the data connection? Active or passive?

[Ivangi]

In both versions of FZS we use active mode.

[oibaf]

Ok, thank. We've found the issue, we'll publish a potential fix in the next nightly build. Would be awesome if you could test it and let us know.

[Ivangi]

Sorry, but I didn't know that the "Nightly Build" versions existed, I thought you were referring to the Beta ones.
Today I tested with the latest stable version (1.8.0) and the problem has been resolved.
Thank you very much Fabio