I would like to connect to an FTP destination and write a file to it.
FTP abruptly closes after entering PASV mode. There is nothing wrong with the FTP server setting as such. I am not really sure what I can fix on the FTP server to fix this problem. Any ideas?
Q: Is the IP address in the client message the same as the servers IP the client accessed or is it the non-public IP address of the server? --- A: It is the non-public IP that the client gets.
This sounds like a FTP server behind a NAT which provides the internal private IP address in the reply for the PASV command. Since the client is probably not in the same private network this private address is not reachable by the client.
Thus the client gets the following error:
"java.net.SocketPermission" "10.xx.xxx.xxx:123456" "connect,resolve"
FTP where one side is behind NAT conflicts with the general architecture of the FTP protocol, that is dynamically created data channels where the endpoints get announced within the control connection. If only one of the peers is behind NAT you can usually work around it by using either passive mode (client behind NAT) or active mode (server behind NAT). If both peers behind NAT or if you want to use passive/active mode in an unsuitable scenario it gets more complicated and you usually need either helpers on the router/firewall or specific configurations for the client/server and lots of ugly port forwarding.
Related
When sending the FTP command "PASV", the FTP server responds with information on which host and port a data connection can be established.
This host information can be problematic if there is a NAT involved. Some clients resolve this by comparing the IP of the proposed data connection host with the one from the control connection: If the one proposed after PASV is a local one while the control connection is not using a local one, only the ports given by the PASV response are used while using the IP of the host connection.
As an example, see the Apache Commons implementation: http://svn.apache.org/viewvc/commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPClient.java?revision=1788985&view=markup#l3876
My question is now: Why use the host of the PASV answer at all? Why not just always only use the ports of the PASV answer but use the host of the control connection? As far as I know this is how it's done with IPv6 but I never see it with IPv4. Why?
At the time FTP was designed there were enough IP addresses and NAT was not a thing to be considered. But FTP was designed to support a use case where a client initiated a transfer between two different systems - see figure 2 in RFC 959 or read about File eXchange Protocol for details. And for this use case it was necessary that the IP addresses in the PORT or PASV command could be different from the (single) server resp. client IP.
As far as I know this is how it's done with IPv6 but I never see it with IPv4.
You are probably referring to the EPRT and EPSV commands which only take a port number and no IP address. While these commands were introduced since the original PORT and PASV commands did not support IPv4 these command can be used for both IPv6 and IPv4 and several clients use these for IPv4 too, thereby avoiding the problems with the wrong IP address in PORT/PASV.
I am using a call to ftp.exe to upload file to a FTP Server.
This program is running since many years and uploads to number of servers, so far without problems.
After one of the receiver servers has been updated, uploads are no longer possible.
This is the command sequence:
open ftp.xxx.de
<user>
<pw>
>230 User logged in, proceed
cd upload
bin
put <filename>
and in response to this the server replies:
501 PORT IP is not the same as 10.100.244.5
150 File Status okay, about to open Connection
That is it, after this the connection is stuck and gets closed after a certain timeout period.
Funny enough, a google search for "PORT IP is not the same as" return exactly one result, which explains that the IP seen by the server is different from the one expected.
Also, when using WinSCP, FileZilla or other FTP utility programs, the connection has no problem and does transfer files just fine.
So, why does this appear and how to solve it?
The ftp.exe uses an old-fashioned active mode command PORT, which requires the client to specify its IP address to which the FTP servers needs to connect back to open a data transfer connection.
If your are behind a firewall or a NAT, the client may not know its external IP address and uses its local network address. This causes troubles. Either the server fails to connect back as it obviously cannot connect to the client's local network. Or the server rejects the PORT command straight away, if the specified IP address does not match the IP address, from which the FTP client connects to the server. This is a security measure as the difference may indicate a man-in-the-middle attack. Your server does the validation. Some servers might be configured to ignore the IP address specified in the PORT command and connect to a known IP address of the client.
Another way to solve this is, if the firewall/NAT can inspect the FTP traffic and seamlessly modify the IP address in the PORT command. This is obviously not happening.
You do not get the problem with WinSCP or FileZilla, as these clients default to the passive FTP mode, which does not have the problem. Also in the active mode these clients can be configured to use the external IP address. FileZilla also supports the modern EPRT command, that does not need to specify the IP address at all (the server uses the known IP address of the client).
See my article about active/passive FTP mode for details.
I do not think there's any way to make it working with the Windows ftp.exe. It neither supports the passive mode, nor can be configured to use the external IP address, nor supports the EPRT command.
So unless you can configure the FTP server not to do the check and connect to the known IP address of the client or configure your firewall/NAT to modify the IP address in the PORT command, you have to use another FTP client.
As you know that WinSCP works, see the guide for converting the Windows ftp.exe script to WinSCP script.
(I'm the author of WinSCP)
I'm using BOOST-ASIO for a simple echo client-server (there is a separate link for the client and server). When I try to run the server I use this async_tcp_echo_server 4000. For the client I use blocking_tcp_echo_client #.#.#.# 4000 (with #.#.#.# as the ip address). I'm on XP-SP3 with my computer connected to my wireless dsl modem using a usb card. After a few seconds on the client side I get this error:
Exception: connect: A connection attempt failed because the connected party did
not properly respond after a period of time, or established connection failed be
cause connected host has failed to respond
Any ideas what it could be? I turned off my firewall including the windows firewall and still I get no response. Could my port be in the incorrect range? Do I need to include a computer name to specify the machine on the network( there are other machines on the network sometimes active)? I did try running this on another computer directly connected to the dsl modem and same issue. I did ping my address and that did work for 4/4 packets.
It could be a variety of issues. Thus, it can be worthwhile to use lower level networking tools, such as netcat to serve a port on the server, and try connecting with netcat from the client side. This can help simplify the problem by removing any potential problems introduced by an application's network programming code. If the problem is identified as being a network issue, then there are a few things to check:
Verify firewall exceptions on the server.
Verify firewall exceptions in the server's network gateway.
If the server and client are on different networks, with the client trying to connect to the server's external IP, then verify that the server's gateway knows what traffic to route to the server. This may require setting up rules, such as port forwarding, in the routing device.
If the server and client are on the same network, but the client is trying to connect to the server through the network's external IP, then verify that the gateway supports looping back internal traffic destined to the external IP.
Use a network analyzer tool, such as Wireshark, to verify that the time to live field in the packets is high enough that it will not be discarded.
you could try
$ telnet server-ip 4000
from your client and see if it is possible to establish the tcp connection.
Most proxy servers perform the job of forwarding data to an appropriate "real" server. However, I am in the process of designing a distributed system in which when the "proxy" receives a TCP/IP socket connection, the remote system actually connects with a real server which the proxy nominates. All subsequent data flows from remote to the real server.
So is it possible to "forward" the socket connection request so that the remote system connects with the real server?
(I am assuming for the moment that nothing further can be done with the remote system. Ie the proxy can't respond to the connection by sending the IP address of the actual server and the remote connections with that. )
This will be under vanilla Windows (not Server), so can't use cunning stuff like TCPCP.
I assume your "remote system" is the one that initiates connection attempts, i.e. client of the proxy.
If I get this right: when the "remote system" wants to connect somewhere, you want the "proxy server" to decide where the connection will really go ("real server"). When the decision is made, you don't want to involve the proxy server any further - the data of the connection should not pass the proxy, but go directly between the "remote system" and the "real server".
Problem is, if you want the connection to be truly direct, the "remote system" must know the IP address of of the "real server", and vice versa.
(I am assuming for the moment that nothing further can be done with
the remote system. Ie the proxy can't respond to the connection by
sending the IP address of the actual server and the remote connections
with that. )
Like I said, not possible. Why is it a problem to have the "proxy" send back the actual IP address?
Is it security - you want to make sure the connection really goes where the proxy wanted? If that's the case, you don't have an option - you have to compromise. Either the proxy forwards all the data, and it knows where the data is going, or let the client connect itself, but you don't have control where it connects.
Most networking problems can be solved as long as you have complete control over the entire network. Here, for instance, you could involve routers on the path between the "remote system" and the "real client", to make sure the connection is direct and that it goes where the proxy wanted. But this is complex, and probably not an option in practice (since you may not have control over those routers).
A compromise may be to have several "relay servers" distributed around the network that will forward the connections instead of having the actual proxy server forward them. When a proxy makes a decision, it finds the best (closest) relay server, tells it about the connection, then orders the client to connect to the relay server, which makes sure the connection goes where the proxy intended it to go.
There might be a way of doing this but you need to use a Windows driver to achieve it. I've not tried this when the connection comes from an IP other than localhost, but it might work.
Take a look at NetFilter SDK. There's a trial version which is fully functional up to 100000 TCP and UDP connections. The other possibility is to write a Windows driver yourself, but this is non-trivial.
http://www.netfiltersdk.com
Basically it works as follows:
1) You create a class which inherits from NF_EventHandler. In there you can provide your own implementation of methods like tcpConnectRequest to allow you to redirect TCP connections somewhere else.
2) You initialize the library with a call to nf_init. This provides the link between the driver and your proxy, as you provide an instance of your NF_EventHandler implementation to it.
There are also some example programs for you to see the redirection happening. For example, to redirect a connection on port 80 from process id 214 to 127.0.0.0:8081, you can run:
TcpRedirector.exe -p 80 -pid 214 -r 127.0.0.1:8081
For your proxy, this would be used as follows:
1) Connect from your client application to the proxy.
2) The connection request is intercepted by NetFilterSDK (tcpConnectRequest) and the connection endpoint is modified to connect to the server the proxy chooses. This is the crucial bit because your connection is coming from outside and this is the part that may not work.
Sounds like routing problem, one layer lower than TCP/IP;
You're actually looking for ARP like proxy:
I'd say you need to manage ARP packets, chekcing the ARP requests:
CLIENT -> WHOIS PROXY.MAC
PROXY -> PROXY.IP is SERVER.IP
Then normal socket connection via TCP/IP from client to server.
If I create a c++ server/client application, the port I used to communicate does it need to be open on the router of the server and client machine
Or what other approach could I take? the client computer needs to receive information from the server but I am not able to have any ports opened because it is on a school network....
[edit]
Hmm My setup is a php page running on a server say when I press hello, the server makes a ssh connection through php and sends shell commands to the machine. The server is running off of a school server which I do have ssh access to and run all my things from there. The client computer will be my pc running off of the school wifi which is not connected to the server. The server will try to make a ssh connection to the public ip of my computer running off of the school wifi(no ports open/can ssh out but no ssh in). Will these methods you mention make this possible, in particular the connect.c since I can't run putty off of the server, and the connect.c I could call from the php.
The choice of language is highly irrelevant here.
There don't need to be ports 'open' on any router, unless your traffic must pass through it. On normal peer hosts in the same network (or subnet) there would hardly be any firewall policy, not even in schools.
Technically it is possible for the switch to block peer-2-peer traffic (meaning traffic not destined to the outgoing gateway), but that is not very usual.
Of course, if the school doesn't allow outbound (WAN) traffic on most ports, tough luck, and they're absolutely right :)
You can look at
ssh (with tunnels -L, -D and -R options, perhaps -o GatewayPorts on)
stunnel
connect.c
http-tunnel
All very readily googled
To establish a TCP/IP connection, only the server port needs to be accessible by the client. The connection is full-duplex, therefore data can flow from the client to the server and vice-versa.
If you are using UDP for your application, which is a connection-less protocol, what happens depends heavily on the firewall or router and whether it performs connection tracking for your service or not.
Unless you provide some additional information on your service and the network setup on both the client and the server side, we cannot provide more concrete information.