What is RPC?
Remote Procedure Call (RPC) provides a different paradigm for accessing network services. Instead of accessing remote services by sending and receiving messages, a client invokes services by making a local procedure call. The local procedure hides the details of the network communication.
When making a remote procedure call:
- The calling environment is suspended, procedure parameters are transferred across the network to the environment where the procedure is to execute, and the procedure is executed there.
- When the procedure finishes and produces its results, its results are transferred back to the calling environment, where execution resumes as if returning from a regular procedure call.
The main goal of RPC is to hide the existence of the network from a program. As a result, RPC doesn't quite fit into the OSI model:
- The message-passing nature of network communication is hidden from the user. The user doesn't first open a connection, read and write data, and then close the connection. Indeed, a client often doesn not even know they are using the network!
- RPC often omits many of the protocol layers to improve performance. Even a small performance improvement is important because a program may invoke RPCs often. For example, on (diskless) Sun workstations, every file access is made via an RPC.
RPC is especially well suited for client-server (e.g., query-response) interaction in which the flow of control alternates between the caller and callee. Conceptually, the client and server do not both execute at the same time. Instead, the thread of execution jumps from the caller to the callee and then back again.
Resolution
The port assignment for Sun Remote Procedure Call (RPC) is not configurable. Sun RPC is used by the Network File System (NFS) and the Network Information Service (NIS).
Sun RPC services can run on any port on the system. When a client attempts to access an RPC service on a server, the client must know the port on which that service is running. To find this information, the client queries the portmapper process on the well-known port of 111. The client sends the RPC program number of the service, and receives the port number. From this point on, the client program sends its RPC queries to that new port.
Only frames going from inside to outside are inspected (for example, the portmapper service running on one of the internal servers has sent a reply). When a server behind the PIX Firewall (on the inside interface) sends out a reply, the PIX intercepts the packet, and opens both embryonic TCP and User Datagram Protocol (UDP) connections on that port.
Note: Network Address Translation (NAT) or Port Address Translation (PAT) of RPC payload information is not supported.
For PIXs that operate on a software code prior to PIX 7.0, refer to the Network File System and Sun RPC section of Configuring Application Inspection (Fixup).
For 7.x code, PIX introduced the inspect sunrpc command. For details on this command, refer to the Managing Sun RPC Inspection section of Applying Application Layer Protocol Inspection.
Note: Microsoft (MS) RPC services can run on any port on the system. When a client attempts to access an RPC service on a server, the client must know the port on which that service is running. To find this information, the client queries the portmapper process on the well-known port of 135 (unlike the port of 111 which is used by Sun RPC).
PIX does not currently support inspection of MS RPC packets. In order for MS RPC to work with PIX, the range of ports that Windows uses could be controlled. This range of ports can be made smaller if less ports are required to be opened. For more information on this, refer to How to configure RPC dynamic port allocation to work with firewalls, a knowledge base article from Microsoft.
Problem Type
How to (General Information)
Troubleshoot software feature
Product Family
Firewall - PIX 500 series
PIX Software Version
PIX version 6.x
PIX version 7.x
Features & Tasks
SUN RPC
Fixup protocols
