Description

This article describes the issue of NIS traffic, which utilizes the SUN-RPC ALG, not passing through, when specific SUN-RPC applications are used.

Symptoms

The Network Information Service or NIS (originally known as Yellow Pages or YP) is a client–server directory service protocol for distributing system configuration data, such as user and host names, between computers on a computer network. At times, it is used to provide authentication support for systems.

All of the possible Sun RPC sessions are initiated over port TCP/UDP/111. Each host can then link the required RPC to an open TCP/UDP port and allow the client to connect to the port. This port information is communicated to the client over the TCP/UDP/111 control channel. The same RPC can be running on different ports on different hosts.

These data ports are negotiated between the client and server by using GETPORT messages. It is the job of the SUN-RPC ALG to parse these messages and pinhole the negotiated data-ports.

When NIS (yellow Pages) traffic is used, the closest SUN-RPC applications that are available in junos-defaults and expected to allow this traffic are:

  • junos-sun-rpc-ypbind
  • junos-sun-rpc-ypbind-tcp
  • junos-sun-rpc-ypbind-udp

You will see that the TCP/UDP 111 control session is successfully established. But, even if you use all of the above applications, the data traffic seems to drop. In fact, even after including all the SUN-RPC applications, the data traffic will not go through.

As soon as the application is changed to any or a custom application that allows the negotiated data port is created, the NIS traffic starts going through. But, this is not a feasible option, as the data ports are randomly negotiated and can vary over the higher TCP port range.

Explanation of the issue :

The gate approach that is used for most of the other ALG supported protocols is not appropriate here. In the case of RPC traffic, the control channel and the data channel do not have a parent child relationship. The PORTMAPPER (control channel) process is only used to direct the client to the appropriate RPC specific server port.

In addition, many different services can be initiated by the PORTMAPPER connection. Most other services are uniquely identified uniquely by the control channel layer 4 address; however, this is not the case with RPCs. The actual process being called is identified by the session level Program number and version. As a result, the firewall must maintain an RPC map table that associates a program number with a particular host and port. The RPC specific firewall policies will use the program number, rather than the port, to determine what traffic is allowed or dropped.

These programs to IP address and port mapping are maintained in the port-map table, which can be viewed by using the following command:
#show usp algs sun-rpc map-table
The above command is run by logging on to the SPC card. Here, you can see the exact mapping between the NIS server IP address and the data port that it has selected for the data connection.

Run the above command to see what data ports are mapped to what program numbers. This program number provides a match to the dynamic port number that is sent in the serverIP - 111 REPLY GETPORT .

Procedure:
root@FW-SJ-DMZ-SRX-1# run start shell
On branch devices:
root@650-1% vty fwdd
On high-end devices:
root@FW-SJ-DMZ-SRX-1% vty node0.fpc7.pic0
BSD platform (XLR processor, 4095MB memory, 16384KB flash)
Now run this command :
[flowd]FPC7.PIC0(vty)# sh usp alg sun-rpc map-table
Sun RPC service mapping - hashed by (ip, port, prot)
Bkt Lsys IP Port Prot Program
150 NULL 192.168.2.167 742 UDP 100004
153 NULL 192.168.2.167 743 TCP 100004
160 NULL 192.168.12.212 819 UDP 100004
193 NULL 192.168.3.41 632 TCP 100004
193 NULL 192.168.3.41 632 TCP 100004
5 record(s)

Solution

This issue is due to the unique design of SUN-RPC, in which it uses program numbers in the policy applications, rather that IP addresses ports. The applications that are defined in the policies must have a match of the program number with the corresponding program number in the sun-rpc map-table . If the match does not exist, the traffic is dropped.

There are two NIs flavors:

  • yellow pages (NIS) using 100004
  • SUN-RPC-PROGRAM-YPBIND using 100007

The issue is that none of the pre-defined Junos applications have the 100004 program number. So, even though you use all the applications, none of them have a mention of the 100004 program number. So, there is no way to associate this traffic with the map-table data and this traffic gets dropped.

A workaround for this issue is to create a customer application that opens the ports, which are learnt dynamically from the server; in this case, it is 632 . When this is explicitly allowed, there is no need for the dynamic table and program number association.

You can create a custom application that mimics SUN-RPC-PROGRAM-YPBIND ; except, the program number will be 100004 :

root@Replication# show applications application SUN-RPC-PROGRAM-NIS-yellow-pages
term t1 protocol udp rpc-program-number 100004;
term t1 protocol tcp rpc-program-number 100004;
Now you can issue this application in the security policy; this will provide an association to the map-table entries. After this, the NIS traffic should go through.