[isalist] Re: Publishing a SSH Server (The solution)

  • From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
  • To: <isalist@xxxxxxxxxxxxx>
  • Date: Sat, 13 May 2006 11:54:51 -0700

We start boarding in about 1/2 hour, so I doubt I'll see your response for at 
least a day (not counting jet lag recovery).
 
Ben Gurion airport (Terminal 3) has complimentary 802.11g!
54MbS of gratis wireless ..!

________________________________

From: isalist-bounce@xxxxxxxxxxxxx on behalf of Thomas W Shinder
Sent: Sat 5/13/2006 9:56 AM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: Publishing a SSH Server (The solution)


Your ASCII art turned out pretty nicely :)
Let me chew on this and hopefully I'll be able to respond before you get on the 
plane. BTW -- do they give you Internet access on Internation flights?
 
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/> 
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> 
MVP -- ISA Firewalls

 


________________________________

        From: isalist-bounce@xxxxxxxxxxxxx 
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
        Sent: Saturday, May 13, 2006 11:29 AM
        To: isalist@xxxxxxxxxxxxx
        Subject: RE: [isalist] Re: Publishing a SSH Server (The solution)
        
        
        I'm on OWA, so my ASCII art will be a bit off:
         
        Correct - if you need a route relationship between two hosts, then they 
need "direct" or at least "routed" access to each other.  If their IP 
subnetting is such that they cannot reach each other except via a NAT device, 
the rule itself cannot work.
         
        
        
        ISA Server Publishing NAT scenario:
        Client IP == 123.123.123.123
        ISA Ext IP = 123.123.123.124
        
        ISA Int IP = 192.168.0.1
        Published SSH server =192.168.0.2
        
        External client sends:
         ------------------------------------
        |     Source IP    | Destination IP  |
        
         ------------------------------------
        |  123.123.123.123 | 123.123.123.124 |
        
         ------------------------------------
        ISA fwds to pub server:
         ------------------------------------
        |     Source IP    | Destination IP  |
        
         ------------------------------------
        |  123.123.123.123 |   192.168.0.2   |
        
         ------------------------------------
        In this scenario, the "standard" NAT-based server publishing applies.  
ISA == default gateway for the SSH server, etc...  If you change the rule to 
"use ISA address", then the source Ip will be the ISA defatul internal IP.

          
        ISA Server Publishing Route scenario #1:
        Client IP == 123.123.123.123
        ISA Ext IP = 123.123.123.124
        
        ISA Int IP = 192.168.0.1
        Published SSH server =123.123.124.124
        
        External client sends:
         ------------------------------------
        |     Source IP    | Destination IP  |
        
         ------------------------------------
        |  123.123.123.123 | 123.123.124.124 |
        
         ------------------------------------
        ISA fwds to pub server:
         ------------------------------------
        |     Source IP    | Destination IP  |
        
         ------------------------------------
        | 123.123.123.123  | 123.123.124.124 |
        
         ------------------------------------
        
        In this scenario, the "standard" route-based server publishing applies. 
 ISA == default gateway for the SSH server, and also performs routing for the 
client to the internal network (or just the SSH server as you like). However 
you confinger it, the client's routing path to teh internal network *must* use 
the ISA external IP as the "last hoop" in the routing path.
         
         
        ISA Server Publishing Route scenario #2:
        Client IP == 192.168.1.1
        ISA Ext IP = 123.123.123.124
        
        ISA Int IP = 192.168.0.1
        Published SSH server =192.168.0.2
        
        External client sends:
         ------------------------------------
        |     Source IP    | Destination IP  |
        
         ------------------------------------
        |    192.168.1.1   |   192.168.0.2   |
        
         ------------------------------------
        ISA fwds to pub server:
         ------------------------------------
        |     Source IP    | Destination IP  |
        
         ------------------------------------
        |   192.168.1.1    |   192.168.0.2   |
        
         ------------------------------------
        
        In this scenario, the "non-standard" route-based server publishing 
appears.  ISA == default gateway for the SSH server, and also performs routing 
for the client to the internal network (or just the SSH server as you like). 
However you confinger it, the client's routing path to the internal network 
*must* use the ISA external IP as the "last hoop" in the routing path.  This is 
much like the "BQOD" test I posed where an RFC-1918-assigned device lies 
outside ISA and must be acessible to/from the LAT.
         
________________________________

        From: isalist-bounce@xxxxxxxxxxxxx on behalf of Thomas W Shinder
        Sent: Sat 5/13/2006 9:05 AM
        To: isalist@xxxxxxxxxxxxx
        Subject: [isalist] Re: Publishing a SSH Server (The solution)
        
        
        Hi Jim,
         
        But I'm still not sure how it explains why adding a ROUTE Network Rule 
solves the problem. Since the Network Rules are evaluated from the top down, I 
would think that the NAT Network Rule would never trigger. So, in a publishing 
situation, if the ROUTE Network Rule is active, then the connection from the 
external host would have to be made to the actual public IP address of the SSH 
server, and then ISA would use its "port stealing" feature to grab the 
connection and forward it to the SSH Server.
         
        I'm so confused :)
         
        Thanks!
        Tom
         
        Thomas W Shinder, M.D.
        Site: www.isaserver.org <http://www.isaserver.org/> 
        Blog: http://blogs.isaserver.org/shinder/
        Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> 
        MVP -- ISA Firewalls

         


________________________________

                From: isalist-bounce@xxxxxxxxxxxxx 
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
                Sent: Saturday, May 13, 2006 10:21 AM
                To: isalist@xxxxxxxxxxxxx; isalist@xxxxxxxxxxxxx
                Subject: [isalist] Re: Publishing a SSH Server (The solution)
                
                
                According to RFC 4254, there are many instances where NAT could 
break SSH traffic.
                The protocol itself tolerates NAT just fine for the most part, 
but a few extensions to the base protocol don't.
                http://www.faqs.org/rfcs/rfc4254.html is your point of 
reference...

________________________________

                From: isalist-bounce@xxxxxxxxxxxxx on behalf of Thomas W Shinder
                Sent: Thu 5/11/2006 8:30 AM
                To: isalist@xxxxxxxxxxxxx
                Subject: [isalist] Re: Publishing a SSH Server (The solution)
                
                
                Wow. that is really whack. I hope we can someday figure out why 
this works!
                 
                Tom
                 
                Thomas W Shinder, M.D.
                Site: www.isaserver.org <http://www.isaserver.org/> 
                Blog: http://blogs.isaserver.org/shinder/
                Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> 
                MVP -- ISA Firewalls

                 


________________________________

                        From: isalist-bounce@xxxxxxxxxxxxx 
[mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Wilmar Perez
                        Sent: Thursday, May 11, 2006 10:16 AM
                        To: isalist@xxxxxxxxxxxxx
                        Subject: [isalist] Re: Publishing a SSH Server (The 
solution)
                        
                        

                        Hello Tom

                         

                        No, I didn't have to delete the NAT rule.  Right now it 
is working with the Route rule before the NAT rule, that is, the Route rule is 
higher.

                         

                        Thanks

                         

                        Wilmar

                All mail to and from this domain is GFI-scanned.


All mail to and from this domain is GFI-scanned.

Other related posts: