Date: Wed, 8 Sep 2010 12:03:34 +0200
From: Kristof Gajsek
Subject: Re: [twsocket] PASV fallback to public IP
To: twsocket@elists.org
>>I have a nagging feeling that NAT address manipulation may only happen
>>with FTP clients, if it fails then people use passive mode.
>This i
Angus Robertson - Magenta Systems Ltd wrote:
>>> Or simply:
>>> >> echo $_SERVER[REMOTE_ADDR];
>
> This still needs be running on a public server somewhere!
> I don't have PHP on mine.
>
>> BTW: The NAT trouble will stop with IPv6.
>
> And introduce lots of new problems instead. My new Sonicwal
>> I have a nagging feeling that NAT address manipulation may only
>> happenwith FTP clients, if it fails then people use passive mode.
>
> This issue happens in passive mode. When FTP client sends PASV
> command it gets a response which contains private IP address...
Irrelevant, we are talking
If it is all the NAT to blame, how could NAT devices translate the FTPS PASV
responses?
SZ
On Wed, Sep 8, 2010 at 1:03 PM, Kristof Gajsek wrote:
> >I have a nagging feeling that NAT address manipulation may only happen
> >with FTP clients, if it fails then people use passive mode.
>
> This issue
>I have a nagging feeling that NAT address manipulation may only happen
>with FTP clients, if it fails then people use passive mode.
This issue happens in passive mode. When FTP client sends PASV command it
gets a response which contains private IP address...
>Adding the same feature as FileZilla
> > Or simply:
> > > echo $_SERVER[REMOTE_ADDR];
This still needs be running on a public server somewhere!
I don't have PHP on mine.
> BTW: The NAT trouble will stop with IPv6.
And introduce lots of new problems instead. My new Sonicwall pass IPv6,
but not process it.
Angus
--
To unsubs
Arno Garrels wrote:
> Angus Robertson - Magenta Systems Ltd wrote:
>
>> Doing the
>> same on an FTP server is much harder, and really needs a public STUN
>> server (as used for SIP for the same reason).
>
> Or simply:
>
> echo $_SERVER[REMOTE_ADDR];
BTW: The NAT trouble will stop with IPv6.
-
Angus Robertson - Magenta Systems Ltd wrote:
> Doing the
> same on an FTP server is much harder, and really needs a public STUN
> server (as used for SIP for the same reason).
Or simply:
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://l
> This issue was reported by one of my users, who later determined
> the cause
> by himself, so I have no such public server available. I will ask
> if this is
> a public server that can be checked. I guess in his case replacing
> private
> with public IP may work, since FileZilla works, however
>...
>Do you have a specific example of a live public server returning a
>private IP that we can test? It will be very difficult to set-up, since
>it needs a crappy NAT router.
Thanks for the explanation, Angus.
This issue was reported by one of my users, who later determined the cause
by himsel
> -Original Message-
> From: Angus Robertson - Magenta Systems Ltd
> [mailto:an...@magsys.co.uk]
> Sent: 07 September 2010 09:47
> To: twsocket@elists.org
> Subject: Re: [twsocket] PASV fallback to public IP
>
>
> > Some FTP servers return wron
> Some FTP servers return wrong IP for PASV command (private instead
> of public). In such cases, obviously, FTP component can't connect to
> the server.
This is not really an FTP server issue, but a poorly designed NAT router
that has not replaced the private IP address with a public IP.
>
Some FTP servers return wrong IP for PASV command (private instead of
public). In such cases, obviously, FTP component can't connect to the
server.
Filezilla is smart enough to detect this and switch to public IP, instead:
...
Command:TYPE I
Response: 200 Type set to I.
Command:
13 matches
Mail list logo
