[isalist] Re: Publishing a SSH Server (The solution)
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isalist@xxxxxxxxxxxxx>
- Date: Sat, 13 May 2006 11:56:01 -0500
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.
Other related posts:
