outward ftp connection never gets password prompt

[Jim Wallace]

Hi,

I have a customer site with two servers sat behind a firewall (onto single ADSL line out to t'internet). The servers and firewall are all on same subnet.

First server is Windows based and has default gateway pointing to the firewall - and ftp out to a supplier's system (running ProFTPD) works fine.

Second server is HP/UX 11.23, is on same subnet as the windows box and has a route for the suppliers IP address pointing to the firewall as gateway (have also tried this setting default gateway from unix box to be the firewall too).

When we open ftp connection from the 11.23 box out to supplier's site, we get connected and get login prompt, but never get password prompt back.

If I then CTRL+C the ftp session on the 11.23 box, I get;
421 service not available, remote server has closed connection.
Login failed.
No control connection for command: Interrupted system call.

If I leave it to time out (set at 300 seconds), I get expected timeout and the 'no control connection' and showing Error 0 on the end.

Customer assures me their firewall is set to allow all outbound traffic from any host on the subnet (and ruleset they sent over seems to bear this out too).

AND: If I try from any other hp-ux machines on my own LAN here, or other of my customers, it works every time!

I've checked the usual allow/deny for ftp, the inetd.conf settings and can't see anything different on this 11.23 server than all the others at my other customer sites.

Suggestions as to where problem may lie would be most welcome please!

(I'm currently waiting on customer telling me if they can put a trace/log on the firewall for all port 20/21 traffic too).

[Jose Mosquera]

Hi,

At the customer side,Is there a route that tells the data-packet by where it should return to the source (HP-UX box)?

Rgds.

[Jim Wallace]

Thanks Jose,

The firewall should be sorting out the return route, based on the source of the outward ftp request. It's working fine for any ftp session started from other servers - just not this hp-ux server.

From what I know of firewall rules, with them allowing all outbound traffic anyway, then the firewall should be working out that ftp traffic on ports 20/21 from the unix server should be routed back to that same server when it gets a reply from the remote end?

Regards.

[Jose Mosquera]

Hi,

The answer must be No. If in your ftp session the "open" request achives answer then you have stablished your continuous source route (from HP-UX side).

Then please Could you check from costumer side the behavior of a "traceroute" command against your HP-UX box?

Rgds.

[Jim Wallace]

Hmmmm - traceroute just returns ***, ping just sits there.

tracert and ping working fine from the windows servers.

[Jose Mosquera]

The traceroute command must be reach your HP-UX box using the correct connection points, in the same way that computers where works fine. Then please identifies in which point the trace is wrong or lost...

[Bill Hassell]

ping and traceroute are often blocked by firewalls. Try a traceroute to hp.com to see if you can even get beyond your internal firewall. For the hp.com trace, it will travel for a few hops then be blocked, but at least can verify that there are several in between hops found.

[Jim Wallace]

Thanks again Jose and also Bill.

tracert and ping are getting out fine from windows server via firewall to external sites.

traceroute and ping from the unix server going out get absolutely no response (other than the ubiquitous "***" back from traceroute).

[Jose Mosquera]

Hi,

Please check your routing tables at HP-UX side:
#netstat -an
Is there present a necessary route to access out your customer side?

Rgds.

[Bill Hassell]

> traceroute and ping from the unix server going out get absolutely no response (other than the ubiquitous "***" back from traceroute).

If you get no response at all then your HP-UX box is very likely blocked at your router or firewall, especially if the Windows boxes are on the same subnet and they work. The assumption is that your default route (netstat -rn) matches your Windows settings.