Re: Why is Listener Next to From in Firewall Rules? Building a Custom RPC Protocol....
- From: "Will" <DELETE_westes@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 24 Nov 2005 11:49:39 -0800
Well, the ISA 2004 help file specifically discusses server publishing with a
routed network and how its behavior is different than with NAT, and the same
documentation states outright that if you use server publishing with a
network NAT rule that clients *outside* the server's network will see the
available ports as being on the ISA 2004 computer, and in the case of a
routed network rule the clients will see the server using its real IP
address. The problem is they don't back up all that theory with good
examples of how to actually do it. Your statement that server publishing
only applies to clients inside the same network baffles me. If the client
and server are behind the firewall on the same network why would I need any
rule on the firewall at all? In that case the two machines talk to each
other directly or through a router.
Let's put aside the whole issue of server publishing, because I never wanted
to use it in the first place. My real problem is that custom RPC protocols
for outbound connections appear to be badly broken in ISA Server 2004, or
simply not supported. I only resorted to exploring the server publishing
features because it was the only way I could get a custom RPC protocol to
work. There are numerous bugs or misfeatures here that are driving me
crazy.
1) If I configure a custom RPC Protocol for an outbound connection, and then
configure the Interfaces tab and save the protocol, the Interfaces tab is
*disappearing*. The next time I edit this protocol there is no Interfaces
tab!! Now, if they didn't want Interfaces to be supported for outbound
connections, they have a misfeature. They should be removing that tab as
soon as I selected Outbound for the protocol direction and not waste my time
in setting up complex UUID and port assignements on the Interfaces tab. If
they don't intend for Interfaces to disappear, then I guess I just have a
bug.
2) If I configure the Interfaces tab and specify a fix port value above
32767 (or maybe 32768...can't remember the exact value now), you save it but
when you reenter the Interfaces dialog the port shows as dynamic!! Don't
just Apply the change. You have to actually save it with OK and then
re-enter the custom protocol by editing it. It looks like someone is
storing port values in an integer variable, which is of course limited to
fewer possible values than a TCP port can have. The Interfaces tab will
save the port fine at a smaller number. This one is just an annoying
programming bug, and easy to workaround.
3) In the cases where we did create outbound protocols with Interfaces
limited by specific services, and included those custom RPC protocols in
firewall rules, what we see in the Monitor log is NOT the custom protocol
that we created and used in the firewall rule. What we see is the "RPC
(All Interfaces)" that comes with ISA Server 2004 as a standard protocol.
It looks like ISA Server 2004 looks at a protocol definition in a custom
protocol, and (at least for RPC) if the custom protocol definition matches
the standard protocol definition then it confuses the two and misrepresents
in the monitor log which one is in your rule. Maybe it is not a
functional bug, but it is certainly a misfeature and does misrepresent the
literal expression of your firewall rule.
What I am trying to accomplish here is that I want to put a "filter" on RPC
requests so that only certain RPC services can be supported through the
firewall. I don't want outside networks to inquire on RPC and have access
to every possible RPC service running on the server. Maybe ISA Server
2004 simply doesn't support that functionality for outbound connections?
We have wasted enormous time discovering that if true. If there is a way
to make it work, I'm here to tell you that it is not obvious, ridden with
bugs, obviously not well tested and not well designed.
So then the question becomes can I achieve the same objective through the
use of a publishing rule of a custom RPC protocol? In the case of an
inbound RPC protocol, the interfaces tab is saved and preserved the next
time I edit the protocol. So apparently it was Microsoft's intent to only
support custom RPC interfaces on server publishing rules. If I do use
server publishing, the client and server in question have a routed
relationship between them. I need to have a way for the client to contact
the server at its true IP address, yet be limited in which RPCs it sees
running on that server.
Since I obviously just don't understand server publishing rules, maybe you
could point me to an overview that includes the actual steps for setting one
of these rules up for a routed network? One good example would be worth a
thousand words.
--
Will
----- Original Message -----
From: "ZVR" <nospamever@xxxxxx>
Newsgroups: microsoft.public.isa
Sent: Thursday, November 24, 2005 6:30 AM
Subject: Re: Why is Listener Next to From in Firewall Rules?
> "Will" <DELETE_westes@xxxxxxxxxxxxxxxxxx> wrote in message
> news:7OmdnU--cJyJPBjeRVn-vQ@xxxxxxxxxxxxxxx
> > I'm not sure I do understand you yet. Are you saying that in the case
of
> > a
> > publishing rule, the from and to fields are in effect reversed, and the
> > server goes in the From field and the network that is contacting the
> > server
> > goes in the To field?
>
> No, what he's saying is that the Listener field is linked to the "From"
> section because in ISA 2004 you configure listeners individually from each
> network ISA is joined to, and when a request comes to a specific listener
it
> comes FROM the network the listener is bound to. In other words the
listener
> HAS to be on the same network as the clients that will be accessing it.
And
> clients are always on the FROM side.
>
> > Assume for a second that I have two networks that have a network rule to
> > route between them (so no NAT). The clients in network A initiate
> > connections to some specific RPC services in network B. I have created
a
> > custom RPC protocol that is incoming on port 135 and contains two
> > specific
> > UUIDs on the Interfaces tab.
>
> If you have a ROUTE relationship between networks A and B then you don't
> need to 'server-publish' anyting, publishing rules are for when there is a
> NAT relationship between networks as in that case you can't go directly
from
> an address in A to an address in B (because all addressed in B will be
> exposed to the network A as a single address on A - the address that is
used
> for NAT).
>
> So you should scrap your server publishing rule and configure an access
rule
> (firewall rule) instead, allowing access to that custom protocol of yours
> for requests originating FROM A and going TO B.
>
> Oh, and one more thing: the protocols employed in access rules MUST have a
> direction of outgoing (not incoming) for the rules to work. That is
because
> an access rule is always parsed in the FROM-TO sequence (all access rules
> are configured from a client point of view). In your case clients are on A
> and destination is on B. What all this means is that you need to re-define
> the custom protocol with a direction of outgoing, since you'll be using
that
> in an access rule not a server publishing rule.
>
>
> > The network rule to route from network A to
> > network B is clear. Are you saying that my server publishing rule in
> > firewall rules is going to place the machines in network B (the server
> > network) in the From/Listening field, and the machine in network A that
> > are
> > clients are entered into the To field in the firewall rule?
>
> See above. Give up the server publishing idea if you have a NAT
relationship
> between networks.
>
> > What I don't want to do is create an open ended publishing rule that
> > allows
> > any machine on any network to contact the published protocol.
>
> Putting aside for a moment the fact that you won't be using server
> publishing rules, you have plenty of mechanisms to ensure that doesn't
> happen for your future server publishing rules (not this one):
>
> a) You can specify a certain client set in the server publishing rule.
Only
> requests coming from those clients will be allowed "into" the listener.
>
> b) As I mentioned before listeners are bound to specific networks and only
> requests coming from those networks can make it to a listener. That is to
> say, no "loop-back" through ISA is allowed. This was possible in ISA2000
(I
> used it several times... it can come handy at times), but not anymore - at
> least not to my knowledge (and I did try).
>
> > Personally I would prefer to see two different dialogs: for outgoing
rules
> > use From/To, and for incoming connection rules use Listener and Client
or
> > Server and Client.
>
> The ISA2004 GUI is actually very clear once you absorb the paradigm shift
> from ISA2000. In ISA 2000 everything was LAN-centric, meaning that you
would
> always 'judge' the direction of traffic relative to your LAN ("internal"
> network). ISA 2004 is "network-centric": the direction of traffic is
always
> relative to the side the connection originates from, regardless what
> side/network is that.
>
> Virgil
>
>
.
- Follow-Ups:
- References:
- Why is Listener Next to From in Firewall Rules?
- From: Will
- Re: Why is Listener Next to From in Firewall Rules?
- From: A. Klimkin
- Re: Why is Listener Next to From in Firewall Rules?
- From: Will
- Re: Why is Listener Next to From in Firewall Rules?
- From: ZVR
- Why is Listener Next to From in Firewall Rules?
- Prev by Date: Re: Why is Listener Next to From in Firewall Rules?
- Next by Date: Why ping is getting denied ?
- Previous by thread: Re: Why is Listener Next to From in Firewall Rules?
- Next by thread: Re: Why is Listener Next to From in Firewall Rules? Building a Custom RPC Protocol....
- Index(es):
Relevant Pages
|
