Problem with Windows Cluster IPs
Moderator: Project members
-
- 504 Command not implemented
- Posts: 8
- Joined: 2023-11-15 09:59
- First name: Ivan
- Last name: Gonzalez
Problem with Windows Cluster IPs
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
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
Re: Problem with Windows Cluster IPs
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.
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.
-
- 504 Command not implemented
- Posts: 8
- Joined: 2023-11-15 09:59
- First name: Ivan
- Last name: Gonzalez
Re: Problem with Windows Cluster IPs
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?
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?
Re: Problem with Windows Cluster IPs
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?
-
- 504 Command not implemented
- Posts: 8
- Joined: 2023-11-15 09:59
- First name: Ivan
- Last name: Gonzalez
Re: Problem with Windows Cluster IPs
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".
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".
- Attachments
-
- FirewallLog.png (19.78 KiB) Viewed 11519 times
Re: Problem with Windows Cluster IPs
Please clarify what exactly you mean by "reply".
-
- 504 Command not implemented
- Posts: 8
- Joined: 2023-11-15 09:59
- First name: Ivan
- Last name: Gonzalez
Re: Problem with Windows Cluster IPs
Sorry, it should be answer.
Re: Problem with Windows Cluster IPs
Please clarify, what exactly do you mean by "answer"?
Re: Problem with Windows Cluster IPs
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?
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?
-
- 504 Command not implemented
- Posts: 8
- Joined: 2023-11-15 09:59
- First name: Ivan
- Last name: Gonzalez
Re: Problem with Windows Cluster IPs
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.
"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.
Re: Problem with Windows Cluster IPs
Ok, we might have a lead.
Which is the mode of the data connection? Active or passive?
Which is the mode of the data connection? Active or passive?
-
- 504 Command not implemented
- Posts: 8
- Joined: 2023-11-15 09:59
- First name: Ivan
- Last name: Gonzalez
Re: Problem with Windows Cluster IPs
In both versions of FZS we use active mode.
Re: Problem with Windows Cluster IPs
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.
-
- 504 Command not implemented
- Posts: 8
- Joined: 2023-11-15 09:59
- First name: Ivan
- Last name: Gonzalez
Re: Problem with Windows Cluster IPs
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
Today I tested with the latest stable version (1.8.0) and the problem has been resolved.
Thank you very much Fabio