Simple Proxy Arp / NAT config failing

[DekPlent]

Hi There

I am struggling with a basic Manual NAT set up on a clustered pair of Quantum 1590s Runnung R81.10.10 where I am trying to set up a NAT on local network for a system on a remote network at the end of a VPN

So I have a system A 192.168.232.10 trying to reach a remote system at the end of an IPSEC VPN IP 10.10.10.1 via the checkpoint IP gateway address 192.168.232.254 mac aa:bb:cc:dd:ee:ff for example

Now I would like to set a NAT of 192.168.232.50 for 10.10.10.1 system so that system A contacts 192.168.232.50 instead of the 10.10.10.1 real IP.

I have tried with a manual NAT rule:

SystemA to  dest:192.168.232.50  translate destination to 10.10.10.1

I have checked the checkpoint to : Serve as ARP Proxy for the original destination's IP Address

But this does not appear to work as the checkpoint is not replying to  ARP requests for 192.168.232.50 and so I am assuming that I'll need a proxy arp entry . The document :

https://support.checkpoint.com/results/sk/sk114531

is not clear as to what should go in the local.arp file could someone please elaborate? And is it always necessary to reboot as I will be unable to reboot this clustered pair.

I tried to use standard arp commands like:

arp -i LAN3 -Ds 192.168.232.50 LAN3 pub

or

arp -s 192.168.232.50 xx:xx:xx:xx:xx:xx pub

or

arp -i LAN3 -Ds 192.168.232.50 LAN3

which I tried but now have these entries in arp:

? (192.168.232.50) at xx.xx.xx.xx.xx.xx [ether] PERM on LAN3
? (192.168.232.50) at * PERM PUP on eth0
? (192.168.232.50) at * PERM PUP on LAN3

(I cannot remove the last 2 entries)

Could anyone please shed any light on this , especially how to remove the PERM PUP  entries please?

Thanks and Regards

Dek

[JP_Rex]

How do you manage the cluster?
local or central?

Regards
Peter

[DekPlent]

Hi Peter,

These are managed locally. I connect to the active device's UI using the floating VIP (or ssh)

Thanks

[PhoneBoy]

local.arp is only relevant if the IP you are proxy arping for is on the same subnet.
The MAC you use should be relevant to the interface on the LAN you wish to proxy arp on.
Otherwise, this should be handled through routing.

A simple network diagram would be helpful.

[DekPlent]

Hi There,

The proxy arp is for a local IP which I am hoping the checkpoint with advertise and respond on behalf of.

The network diagram attached shows system A wanting to contact system B (which is currently remote but will eventually be on the local net with A - shown as the dotted box) but in the meantime I would like the checkpoint to provide a NAT with the IP that system B will eventually have  (192.168.232.50) when it is eventually installed locally.  But for now, when system A contacts 192.168.232.50 I would like the traffic for this NAT IP on the checkpoint to be routed to 10.10.10.1 (where system B curretnly resides).

 

I also tried creating system B  as a web or custom server having a NAT of 192.168.232.50 so that the NAT rules were automatically generated to be routed to 10.10.10.1 but this also failed in that I saw nothing newly added to the arp tables for IP 192.168.232.50.

I hope the diagram helps to explain

Regards

Dek

[PhoneBoy]

What does fw ctl arp say?
This is probably going to require a TAC case: https://help.checkpoint.com 

[DekPlent]

Hi There,

I have set up a different NAT IP now but with the server configuration wizard which should create the automatic arp entries, the fw ctl arp shows:

[Expert@GW2]# fw ctl arp
.....
(192.168.232.70) at 00-xx-xx-xx-xx-xx interface 192.168.232.253

Which is the mac address of the checkpoint on that local lan, as expected

The following command from server A contacting the NAT 192.168.232.70 eventually times out

# ssh -p 80 -v 192.168.232.70

tcpdump generated on the checkpoint from the command above :

18:45:08.227136 ARP, Request who-has 192.168.232.70 tell ulive, length 46
18:45:08.227182 ARP, Reply 192.168.232.70 is-at 00:xx:xx:xx:xx:xx (oui Unknown), length 46

18:45:41.670006 ARP, Request who-has 192.168.232.70 tell my.firewall, length 28
18:45:44.752975 ARP, Request who-has 192.168.232.70 tell ulive, length 46
18:45:44.753029 ARP, Reply 192.168.232.70 is-at 00:xx:xx:xx:xx:xx (oui Unknown), length 46
18:46:13.681121 IP ulive.37472 > 192.168.232.70.www: Flags [S], seq 2802536161, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
18:46:13.683147 ARP, Request who-has 192.168.232.70 tell my.firewall, length 28
18:46:14.694007 ARP, Request who-has 192.168.232.70 tell my.firewall, length 28
18:46:15.722018 ARP, Request who-has 192.168.232.70 tell my.firewall, length 28
18:46:18.801058 ARP, Request who-has 192.168.232.70 tell ulive, length 46
18:46:18.801109 ARP, Reply 192.168.232.70 is-at 00:xx:xx:xx:xx:xx:xx (oui Unknown), length 46
18:46:22.962116 ARP, Request who-has 192.168.232.70 tell 192.168.232.70, length 28
18:47:31.530069 ARP, Request who-has 192.168.232.70 tell 192.168.232.70, length 28

No traffic emerges at the other end of the IPSEC tunnel.

I will open a ticket as suggested but I am still very interested to hear from others who may have successfully set this up.

Thanks for your time

Regards

Dek

[PhoneBoy]

Looks like we are actually replying to the arp whois with a MAC address.
It doesn't appear to be received by the remote end, thus why the repeated arp whois requests.

Can you try putting a static arp on the client to see if that resolves the issue?

[DekPlent]

Hi There,

The client ulive has the arp entry from the checkpoint:

root@ulive:~# arp -an
....
? (192.168.232.70) at 00:xx:xx:xx:xx:xx [ether] on eth0

The strange packets in trace is the

19:11:46.609646 ARP, Request who-has 192.168.232.70 tell my.firewall, length 28
19:11:47.622716 ARP, Request who-has 192.168.232.70 tell my.firewall, length 28
19:11:48.642635 ARP, Request who-has 192.168.232.70 tell my.firewall, length 28

I am assuming my.firewall is the checkpoint itself but then also these packets:

19:05:47.794699 ARP, Request who-has 192.168.232.70 tell 192.168.232.70, length 28
19:06:56.402683 ARP, Request who-has 192.168.232.70 tell 192.168.232.70, length 28
19:08:04.846690 ARP, Request who-has 192.168.232.70 tell 192.168.232.70, length 28
19:09:14.466704 ARP, Request who-has 192.168.232.70 tell 192.168.232.70, length 28

I don't quite understand those either...

Regards

Derek

[PhoneBoy]

That sounds like a bug.
TAC is definitely your best bet.