portmapper reply in SG configuration.

[JI HUI]

HP-UX 11.0 SG configuration. (host1 and host2)

My client sends RPC request to the portmapper running on a SG cluster. The destination IP address is the SG's Virtual IP address.

But, the reply from the SG a cluster (assuming the active one is host1) uses host1's physical IP address as the source IP address.

This cause a problem in the firewall in between as the reply packet was dropped. Is there any fix or workaround?

thank you.,

[Robert-Jan Goossens]

Hello,

Found this "old" thread,

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=149302

Hope this helps,

Robert-Jan

[JI HUI]

Hi Robert,

Thank you for the prompt reply.

But,
1. the firewall would not recognize it as valid reply as the SA (source address) is different from the DA (destination address), so the reply is considered as new connection!
If I need to add a new rule, it may post security hole to my system as the source port would be different.
2. assuming I could configure the firewall and packet with host1' IP as SA passes, will client accept the reply as its SA is not from the server the client know.

any comment?

[Dietmar Konermann]

Well, the portmapper (i.e. rpcd/dced) binds its sockets using INADDR_ANY , which -- in general -- causes outgoing traffic to use the stationary IP address. That's the way it works.

However, the SA of outgoing traffic can usually be changed by adding/removing (host) routes that use the relocatable IP as gateway, e.g. from customer_defined_run/halt_commands(). However, this change affects _all_ outgoing traffic that uses the new route.

Best regards...
Dietmar.

[JI HUI]

Dear Dietmar Konermann,

Thank you for the reply.

Do you mean that I need to add route command?

Do you have a bit detailed example?

thank you in advance.

[Sanjay_6]

Hi,

I don't think there is a workaround. I ran into similar issues when i was sending traffic from behind the F5 load balancers to the SG virtual ip and the reply was coming from the ip address of the system. We ended up using the ip address of the system as the destination ip address.

Hope this helps.

Regds

[JI HUI]

has anyone tried IPfilter?

does it work if I have a NAT rule such as:
map lan0 10.10.1.1/32 -> 10.10.2.1/32

Assuming the host1's IP is 10.10.1.1 and SG virtual IP is 10.10.2.1/32

thank you.

[Colin Topliss]

This is a 'feature'.

The firewall packets will all contain the 'real' NIC IP address as opposed to the VIP.

We have similar problems - we ended up having to add the real IP addresses (for both sides of the cluster) for this to work.

The firewall drops the connection as it has no corresponding initiator entry (basically the return address doesn't match the address that the connection was initiated with).

Client initiates the connection using the VIP (initiator IP address) but the reply comes from the NIC IP - the two don't tie up, the firewall denies the connection....