[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re[2]: ipnat and port allocation problems
From:       Sen Nagata <sen () eccosys ! com>
Date:       1997-08-19 4:47:15
[Download RAW message or body]

first off, thanks to all who provided info about port allocation for
ssh (including compiling ssh w/ different options -- which we will
resort to as a workaround if we are forced to).

here is what we did this morning:

there are two scenarios:

(additional info: hosta and hostb only have one non-loopback interface
each)

scenario 1. 
(a remote port-forwarding first, followed by an attempted vanilla ssh
session)

-from hostb we set up a remote port-forwarding to hosta.
 (we used 'ssh -v -R ...' so we were able to see which ports were
  being chosen.  on hostb, port 1023 was chosen.  there is an entry in
  the nat table which is viewable via 'ipnat -l' as a result of this
  port-forwarding. the packet capturing showed a connection between port
  1023 on interface a of our box, and port 22 on hosta)
  
-next, we attempt to connect to hosta from our box using 'ssh -v', but
we are unsuccessful.
 (in the verbose output from ssh, we see 'Allocated port 1023' followed
  by several 'Connection timed out' messages.  this was followed by a
  notice of failure to set up a secure connection, and then the bit
  about reverting to an insecure method. we also see via packet
  capturing,  a syn-ack-syn sequence between port 1023 on interface a of
  our box and port 22 on hosta.)

-contrary to what we wrote earlier, the connection does not get
unresponsive in this scenario (however, it does the for the next one).
we apologize for this error in our reporting.

scenario 2.
(an ssh session from our box to hosta, followed by an attempted remote
port-forwarding from hostb to hosta (via nat))

note: before trying scenario 2, we stopped the ssh port forwardings, and
flushed the nat table of all entries.

-we connect from our box to hosta using 'ssh -v'
 (the verbose output shows that port 1023 was allocated on our box.
  packet capturing shows us that a connection has been set up between
  port 1023 on interface a of our box and port 22 of hosta.)
  
-we attempt to set up a remote port-forwarding from hostb to hosta, but
we are unsuccessful.
 (in the verbose output from ssh, we see similar output to what we saw
  in scenario 1 -- port 1023 allocated on hostb and several 'Connection
  timed out' messages, etc.. packet capturing shows us a syn-ack-syn
  sequence between port 1023 on interface a of our box and port 22 on
  hosta.  we also see a new entry in the nat table for (presumably) the 
  port-forwarding.)

-our existing ssh connection between our box and hosta is not responsive.
we try typing a number of different things but there is no echoing of
what we type on the screen.

we also tried terminating the first ssh session in the midst of the
second ssh attempt's sequence of 'connection timed out' messages, and
this allowed the second attempt to succeed.

we also noticed that as long as the port being used for nat on interface
a was different from the port allocated for the ssh connection (also on
port a), we could simultaneously have the remote port-forwarding and
vanilla ssh session set up (as expected).  we mention this just as
additional data.

now for some clarification of what we mentioned in our first message...

At about Mon, 18 Aug 1997 23:05:04 +1000 (EST)
Darren Reed <darrenr@cyber.com.au> mentioned:

> In some mail I received from Sen Nagata, sie wrote
> [...]
> >   please correct me if i am wrong, but shouldn't the kernel allocate a
> > port from among available ports?  that is, since ipnat was using port
> > 1023, shouldn't that port have been unavailable from the point of view
> > of the kernel?
> 
> No.  ipnat doesn't interact at all with TCP's list of ports that are in
> use.  

we think our statement above may have been phrased poorly. what we meant
was:

'since ipnat was using port 1023 on interface a of our box (for the
remote port-forwarding na translation from hostb to hosta) shouldn't
port 1023 on interface a of our box have been unavailable from the point
of view of the ssh (actually the kernel) when we try to set up an ssh
session between our box and hosta?'

thanks for your attention.

-sen and others


[prev in list] [next in list] [prev in thread] [next in thread]