Hi.
Nathan: Yes, telnet to ports 135 and 7575 works fine.
We've figured out the following thing: Between the clients and the F5 there is a cluster of Stonegate Firewalls. There is a rule that allow port 135 between the subnet of the clients and the F5 services subnet. If we change that rule to allow any port, it works!!. It's clear that it has to do with the MSRPC protocol, and specifically with the negotiation of the Transfer Syntax.
Content of a "successful" packet:
Frame: Number = 115, Captured Frame Length = 170, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-E8-4C-84-41],SourceAddress:[00-50-56-B1-00-12]
+ Ipv4: Src = 10.33.4.216, Dest = 10.34.253.76, Next Protocol = TCP, Packet ID = 20945, Total IP Length = 156
+ Tcp: Flags=...AP..., SrcPort=2542, DstPort=DCE endpoint resolution(135), PayloadLen=116, Seq=1879818234 - 1879818350, Ack=3166776705, Win=64240 (scale factor 0x0) = 64240
- Msrpc: c/o Bind: EPT(EPMP) UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
- Bind: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)
RpcVers: 5 (0x5)
RpcVersMinor: 0 (0x0)
PType: 0x0B - Bind
+ PfcFlags: 3 (0x3)
+ PackedDrep: 0x10
FragLength: 116 (0x74)
AuthLength: 0 (0x0)
CallId: 1 (0x1)
MaxXmitFrag: 5840 (0x16D0)
MaxRecvFrag: 5840 (0x16D0)
AssocGroupId: 0 (0x0)
- PContextElem:
NContextElem: 2 (0x2)
Reserved: 0 (0x0)
Reserved2: 0 (0x0)
- PContElem: 0x1
PContId: 0 (0x0)
NTransferSyn: 1 (0x1)
Reserved: 0 (0x0)
+ AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)
+ TransferSyntaxes: {8A885D04-1CEB-11C9-9FE8-08002B104860} NDR
- PContElem: 0x1
PContId: 1 (0x1)
NTransferSyn: 1 (0x1)
Reserved: 0 (0x0)
+ AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)
+ TransferSyntaxes: {6CB71C2C-9812-4540-0100000000000000} BTFN - Security Context Multiplexing Supported
AuthVerifier: 0x1
Content of a "failed" packet:
Frame: Number = 109, Captured Frame Length = 214, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-E8-4C-84-41],SourceAddress:[00-50-56-B1-00-07]
+ Ipv4: Src = 10.33.4.99, Dest = 10.34.253.76, Next Protocol = TCP, Packet ID = 25893, Total IP Length = 200
+ Tcp: Flags=...AP..., SrcPort=49426, DstPort=DCE endpoint resolution(135), PayloadLen=160, Seq=884801470 - 884801630, Ack=1053259839, Win=256 (scale factor 0x8) = 65536
- Msrpc: c/o Bind: EPT(EPMP) UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Call=0x2 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
- Bind: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)
RpcVers: 5 (0x5)
RpcVersMinor: 0 (0x0)
PType: 0x0B - Bind
+ PfcFlags: 3 (0x3)
+ PackedDrep: 0x10
FragLength: 160 (0xA0)
AuthLength: 0 (0x0)
CallId: 2 (0x2)
MaxXmitFrag: 5840 (0x16D0)
MaxRecvFrag: 5840 (0x16D0)
AssocGroupId: 0 (0x0)
- PContextElem:
NContextElem: 3 (0x3)
Reserved: 0 (0x0)
Reserved2: 0 (0x0)
- PContElem: 0x1
PContId: 0 (0x0)
NTransferSyn: 1 (0x1)
Reserved: 0 (0x0)
+ AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)
+ TransferSyntaxes: {8A885D04-1CEB-11C9-9FE8-08002B104860} NDR
- PContElem: 0x1
PContId: 1 (0x1)
NTransferSyn: 1 (0x1)
Reserved: 0 (0x0)
+ AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)
+ TransferSyntaxes: {71710533-BEBA-4937-8319-B5DBEF9CCC36} NDR64
- PContElem: 0x1
PContId: 2 (0x2)
NTransferSyn: 1 (0x1)
Reserved: 0 (0x0)
+ AbstractSyntax: {E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)
+ TransferSyntaxes: {6CB71C2C-9812-4540-0300000000000000} BTFN - Security Context Multiplexing Supported
AuthVerifier: 0x1
It seems that when the client negotiates more types of transfer syntax, it fails. Is the F5 device modifying the packet? Any idea?
Thank you very much.
P.D.: When doing the test directly to the CAS server, it works, following the same way through the same firewall. F5 device is in a "one-arm" configuration, same internal and external VLAN.