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