[j-nsp] JUNOS and MS RPC

Glenn Krutsinger GKrutsinger at compassion.com
Wed Apr 13 23:10:41 EDT 2011


Clarke,

Thanks for the examples.

My first thought was to build custom UUID applications, but I soon decided
that wasn't an option. MS can't even provide a accurate list of UUID's,
without going to the individual product teams. Managing the list, with MS'
almost whimsical approach to standards and consistency, would also be a
nightmare.

With all the active JUNOS code lines, it's hard to find out where things
are patched, and what those patch comments really mean. I haven't tested
any code beyond the current JTAC recommended.

Glenn

On 4/13/11 9:03 AM, "Clarke Morledge" <chmorl at wm.edu> wrote:

>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
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp
>





More information about the juniper-nsp mailing list