rpcbind does not reply on the address that getport was requested.

[J Bartram]

Hi,

HP-UX 11.23 ia64 problem.

We have found that when our servers have been given a second network address on lan0:1 the address of lan0 is used in the return packet of the rpc getport request issued to lan0:1 from our client application.

Here is an example of the packet details

No. Time Source Destination Protocol Info
3 0.000130 1.0.0.141 1.0.0.95 Portmap V2 GETPORT Call (Reply In 4) Unknown(1073742128) V:1 TCP
No. Time Source Destination Protocol Info
4 0.000630 1.0.0.18 1.0.0.141 Portmap V2 GETPORT Reply (Call In 3) Port:4520

We request the getport from 1.0.0.95 but the packet is sent back from 1.0.0.18.

We only noticed this when trying to connect to our application aver a VPN. The firewall blocks the return packet.

I have tried getting our server application to only listen on 1.0.0.95 but this did not help.

$ rpcinfo -p | grep 4520
1073742128 1 tcp 4520
$
$ netstat -an | grep 4520
tcp 0 0 1.0.0.95.4520 *.* LISTEN

I did try it with a totally different address on the card. With lan0 set to 1.0.0.18 and lan0:1 set to 172.29.32.20 it worked as expected. Packets for getport requests to 172.29.32.20 were returned from 172.29.32.20.

Does anyone know how rpcbind decides which address to reply on when you have several on the same network adapter? Can it be made to always reply on the address that the request was made?

Regards,
Jason Bartram

[Craig Gilmore · Accepted solution]

Hi Jason,

This is a routing question. What does the routing table look like?

A guess is that the routing table has a route to the 1.0.0.0 network through the 1.0.0.18 address.

Regards,

Craig

[J Bartram]

Craig,

It is a routing problem.

Here is the table from another server with the same problem.

# netstat -rn
Routing tables
Destination Gateway Flags Refs Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 lo0 4136
172.29.32.20 172.29.32.20 UH 0 lan0:1 4136
172.29.32.23 172.29.32.23 UH 0 lan0 4136
172.29.32.0 172.29.32.23 U 3 lan0 1500
172.29.32.0 172.29.32.20 U 3 lan0:1 1500
180.213.0.0 172.29.32.5 UG 0 lan0:1 0
1.0.0.0 172.29.32.14 UG 0 lan0:1 0
10.41.0.0 172.29.32.5 UG 0 lan0 0
160.213.0.0 172.29.32.5 UG 0 lan0:1 0
127.0.0.0 127.0.0.1 U 0 lo0 0
default 172.29.32.2 UG 0 lan0 0

I am connecting from 1.0.0.141

When I delete the route for 172.29.32.0 172.29.32.23
the getport comes back from 172.29.32.20.
But then requests on 172.29.32.23 also come back on 172.29.32.20.

Ideally if I connect to 172.29.32.23 I need a return packet from 172.29.32.23 and if I connect to 172.29.32.20 I need a return packet from 172.29.32.20. Can this be achieved?

[Dave Olker]

Hi Jason,

Can you confirm how you have the ip_strong_es_model ndd tunable configured? This tunable, in many cases, can control which IP address is used for the reply of an inbound packet.

It may not work in all cases, especially with UDP traffic. But you could try changing this value to 2 and see if it gives you the desired behavior.

Regards,

Dave

[J Bartram]

Hi Dave,
I have tried ndd -set /dev/ip ip_strong_es_model 2 and it still responds on the other address.
Regards,
Jason.

[J Bartram]

I have retested this today and deleting the route for the primary address does not make rpcbind reply on the other address.

There appears to be no way of making this work so I'm going to log it with HP.

[TomasEdwardsson]

As far as I can see, this is still an issue. Was this ever resolved?

Output from wireshark:

405 2.092682 10.1.1.12 -> 10.11.9.101 Portmap V2 GETPORT Call NFS(100003) V:3 UDP
406 2.092699 10.1.1.12 -> 10.11.9.101 Portmap [RPC retransmission of #405]V2 GETPORT Call NFS(100003) V:3 UDP
407 2.094071 10.11.8.3 -> 10.1.1.12 Portmap V2 GETPORT Reply (Call In 405) Port:2049

The IP 10.11.9.101 is a extra IP on a HP-UX machine with the IP 10.11.8.3. The machines are both on the same subnet, mask is 255.255.248.0.

This makes firewalling quite hard to accomplish between NFS clients and a HP-UX NFS server.