[j-nsp] JUNOS and MS RPC

[Clarke Morledge]

Glenn said:

> Is anyone running MS products through SRX firewalls? How are you getting
> RPC to work? According to engineering, the ScreenOS "ms-rpc-any" isn't
> included in JUNOS, although, I do see the ALG catching the info based
> off of endpoint mapper sessions.

---------------------------------------

Glenn,

I have been struggling with the MS-RPC ALG for weeks now in version 10.1R4 
without any success.   My workaround has been to leave the entire range of 
ephemeral ports above 1024/tcp open, which isn't ideal.

What I have been able to learn is that in addition to allowing the control 
session for RPC to go through via the "junos-ms-rpc" default application, 
you have to also specify the application for the dynamic port.  In my 
case, the UUID for my MS RPC application does not have a corresponding 
default defined in the hidden junos-defaults config group, so I have to 
define my own, "ms-rpc-epm-dynamic", as in my example below.

Here is how I found out what my version of Junos has defined for the 
defaults:

show configuration groups junos-defaults | find junos-ms-rpc
     application junos-ms-rpc-tcp {
         term t1 alg ms-rpc protocol tcp destination-port 135;
     }
     application junos-ms-rpc-udp {
         term t1 alg ms-rpc protocol udp destination-port 135;
     }
     #
     #  Microsoft RPC EPM (End Point Mapper)
     #
     application junos-ms-rpc-epm {
         term t1 protocol tcp uuid e1af8308-5d1f-11c9-91a4-08002b14a0fa;
     }

....etc....


Here is a snippet of the type of config I have been using (I am assuming 
this is all TCP, not UDP):

policy Test-Inbound {
     match {
         source-address Campus;
         destination-address MS-RPC-Servers;
         application [ ms-rpc-epm-dynamic junos-ms-rpc-tcp ];
     }
     then {
         permit;
         log {
             session-init;
             session-close;
         }
     }
}
application ms-rpc-epm-dynamic {
     term t1 protocol tcp uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx;
}


Unfortunately, the SRX is dropping the dynamic session (via subsequent 
deny policy, or the default deny policy) about a half a dozen or a dozen 
packets into the session.   And like you I see that the SRX is cotching 
the endport mapper sessions correctly, but it just isn't maintaining the 
context correctly throughout the life of the dynamic connection.

Supposedly, according to JTAC, there are MS RPC ALG fixes in 10.4R3, but I 
have not tested it that far yet.

I'd be curious to know if you have found any success.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187