Forum Discussion

dirken's avatar
dirken
Icon for Nimbostratus rankNimbostratus
Mar 11, 2013

RPC payload nat (map response)

I have the following setup:

 

client === Checkpoint === F5 === Server

 

The client connects via rpc to the VS on the F5 and gets forwarded to the pool member. During the rpc communication the clients puts a "map request" and gets an answer from the pool member, instructing the client to connect to the pool member's ip on port XY. Now, ip header-wise the source ip in this answer is nattet back to the Virtual Server IP address, but the ip address in the rpc payload, the "map response", still has the pool member's real ip address, which now differs from the source ip address in the ip header. When this packet arrives at the Checkpoint firewall it is dropped because the two addresses do not match.

 

My workaround is to use a custom port object in the Checkpoint without any L7 information behind, so the IPS functionality does not apply its RPC intelligence and accepts the packet. Thus, however, I also loose the checkpoints capability of dynamically opening the ports negotiated via RPC and I have to open the whole upper port range, making the Checkpoint kind of a router for this IP.

 

However, in my workaround, the client gets the message indication the pool member's real ip but still the client connects back to the Virtual Server's ip address on the port negotiated via RPC, clearly visible in a tcpdump taken on server-side and one on client-side on the F5. I am kind of lost here, because I do not know how the client knows it has to connect to the VS, although the RPC message still contains the pool member's address????

 

F5 confirmed they do not have a profile for RPC, so I can only nat the RPC payload address manually via "TCP::payload replace". However, doing this without thorough knowledge of the RPC protocol is kind of risky, I think. I could look for the pool member's ip address and replace it, but I do not know in which other RPC messages I might have to change something. Also: if i change the IP, will it still work with the client that obviously had no problem with the non-reachable pool member's address in the RPC payload???

 

So:

 

- who can explain to me what the hell happens on the client so the RPC still works although there's a wrong address in the payload?

 

- who has a code example for this RPC situation (could't find anything in "code share")?

 

No RepliesBe the first to reply