Managing gateways using IPSEC site2site VPN

[andreac]

Hi,

I need to connect my SMS with several gateways through an IPSEC VPN because the gateway are behind a third party firewall that act as VPN manager.

The scenario is:

Gateway A directly connected to SMS via LAN

Gateway A established an IPSEC (in a star topology in which the gateway A is the centre) connection with several VPN equipments of the customer that is directly connected to Checkpoint Gateways in the customer premises.

The IPSEC VPN work fine for all traffic (from the LAN connected to Gateway A is possible to reach all the nets configured in the VPN encryption domain of all the sites) but not for the management traffic (FW1, CPD, CPD_amon....) that is no admitted in VPN.

i.e. if I try to install the policies on a remote gateway, I have the error "Installation failed. Reason: TCP connectivity failure [port = 18191] [IP = xx.xx.xx.xx][error no. 10]" and looking at the traffic in the gateway with tcpdump or zdebug I can see that the gateway send ARP packets (with the IP address of the interface with the default gateway on) to resolve the IP xx.xx.xx.xx instead to put the traffic into the VPN tunnel that has xx.xx.xx.xx in the domain.

The following trace are:

zdebug of telnet from SMS to gateway on port 18192 in which you can see the ARP packet at the end of the sequence

@;94761243;[kern];[tid_0];[fw4_0];Physical dump for fwlinux_nfipin: packet ffff88027279cbc0 device bond0.200
<SMS IP> -> xx.xx.xx.xx TCP 53389->18192 (SYN), seq = 769166369, ack = 0;
--
@;94761243;[kern];[tid_0];[fw4_0];Physical dump for fwkdrv_enqueue_packet_user_ex: packet ffff88027279cbc0 device bond0.200
<SMS IP> -> xx.xx.xx.xx TCP 53389->18192 (SYN), seq = 769166369, ack = 0;
@;42775668;[vs_0];[tid_0];[fw4_0];Physical dump for fwuser_prepare_packet_ex: packet 0x7fc752881a20 device bond0.200
<SMS IP> -> xx.xx.xx.xx TCP 53389->18192 (SYN), seq = 769166369, ack = 0;
--
@;42775668;[vs_0];[tid_0];[fw4_0];fw_filter_locked: fwha_filter returned 2;
@;42775668;[vs_0];[tid_0];[fw4_0];<==fwzone_set_zones (inbound) src[<SMS IP>] inzone[External] dst[xx.xx.xx.xx2] outzone[Internal];
--
@;94761243;[kern];[tid_3];[fw4_0];Physical dump for fwkdrv_handle_packet: packet ffff88027279cbc0 device bond0.200
<SMS IP> -> xx.xx.xx.xx TCP 53389->18192 (SYN), seq = 769166369, ack = 0;
--
@;94761243;[kern];[tid_0];[fw4_0];Physical dump for fwlinux_nfarpout: packet ffff8802736f1280 device bond0.3000
ARP defGatewayItfIP -> xx.xx.xx.xx;

zdebug of telnet from SMS to the same gateway on port 18193, the packet is sent in IPSEC tunnel

@;94814970;[kern];[tid_0];[fw4_0];Physical dump for fwlinux_nfipin: packet ffff8802578309c0 device bond0.200
<SMS IP> -> xx.xx.xx.xx TCP 58770->18193 (SYN), seq = 3503414765, ack = 0;
@;94814970;[kern];[tid_0];[fw4_0];Physical dump for fwkdrv_enqueue_packet_user_ex: packet ffff8802578309c0 device bond0.200
<SMS IP> -> xx.xx.xx.xx TCP 58770->18193 (SYN), seq = 3503414765, ack = 0;
@;42800008;[vs_0];[tid_0];[fw4_0];Physical dump for fwuser_prepare_packet_ex: packet 0x7fc752882aa8 device bond0.200
<SMS IP> -> xx.xx.xx.xx TCP 58770->18193 (SYN), seq = 3503414765, ack = 0;
--
@;42800008;[vs_0];[tid_0];[fw4_0];fw_filter_locked: fwha_filter returned 2;
@;42800008;[vs_0];[tid_0];[fw4_0];<==fwzone_set_zones (inbound) src[<SMS IP>] inzone[External] dst[xx.xx.xx.xx] outzone[Internal];
--
@;94814970;[kern];[tid_3];[fw4_0];Physical dump for fwkdrv_handle_packet: packet ffff8802578309c0 device bond0.200
<SMS IP> -> xx.xx.xx.xx TCP 58770->18193 (SYN), seq = 3503414765, ack = 0;

The gateways are running Gaia R81.10.

Anyone can help me?

Regards

Andrea

[AmirArama · Accepted solution]

Hi,

are you trying to encrypt the Management traffic from the SMS to the GWs?

by default it sent in clear for a good reason.

did you see this sk?

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

[the_rock]

I recall TAC giving me that sk once, its definitely relevant in this case.

Best,

Andy

[andreac]

In the sk is not included r81.10; do you think I can apply also on r81.10?

[the_rock]

100%...works even on R81.20

Andy

[the_rock]

MAKE SURE to back up the file first, of course.

Best,

Andy

[andreac]

Thank you Amir.

I didn't found that sk.

[RamGuy239]

This should be a last resort. It sounds like managing the gateways via IPsec VPN will the primary way of managing them? This is a catch-22 waiting to happen. What are you going to do once the IPsec VPN breaks or requires changes that needs to be pushed from the management? Would be much wiser to at least attempt to fix the required firewall and NAT changes on the third-party gateway that sits in front of the Check Point gateway before attempting to force the traffic to utilise IPsec VPN.

At the very least you need to have solutions allowing you to access these security gateways directly in order to able to troubleshoot IPsec VPN, force resets of the IPsec VPN tunnel etc. If everything is relient on the IPsec VPN for both management traffic from the management server, and for yourself to be able to reach them using Gaia Portal and CLI/SSH, you are doomed to end up in scenarios where you are pretty much out of luck once you run into IPsec VPN issues down the line.

[the_rock]

Super valid point @RamGuy239 

Best,

Andy

[andreac]

This would be right if the VPN endpoint are CheckPoint Security Gatewys managed through VPN.

In this case, instead, the endpoint are: the central gateway (reached form SMS via LAN, not VPN) and third party gateway that are managed by the customer. The remote Checkpoint Gateways are connected via LAN to the third party gateways and they don't have any configuration related to IPSEC VPN.

In case of VPN problems, the troubleshooting is done on central CheckPoint gateway and thid party gateways; no risk to "cut the branch you are sitting on".

Andrea

[the_rock]

So there is nothing at all related to VPN as far as CP firewalls?

Andy

[andreac]

The CP firewall that act as centre of the star has VPN configuration to reach third party devices, but it is directly connected to SMS (not through VPN). If there would be problem on VPN, all the elements involved still reachable without VPN to troubleshoot and solve the problem.

Andrea

[the_rock]

K, sorry, not trying to be pain in the a**, but, would you be kind enough to send simple diagram of all this and point out EXACTLY what is NOT working? If I can see it via the diagram, Im sure it would make way more sense.

Best,

Andy

[andreac]

The dotted lines link the endpoint of the IPSEC VPNs, reprent the logical link between the Central site and the Remote sites.

The IPSEC connection endpoints are the CP Gateway in the Central site and the 3rd party gateways in the remote sites.

The CP Gateways in the remote sites are not aware of the existence of a VPN.

The VPN configuration on Central CP Gateway is managed by CP SMS.

The VPN configuration on 3rd party Gateways is managed by the customer.

Andrea

[the_rock]

Ok, so whats presented by a dotted line does NOT work? You cant communicate between 3rd party gateways and CP side? Those are 2 separate VPN tunnels?

Best,

Andy

[andreac]

There is one tunnel for each site.

The VPN works fine for all the traffic (the host in the remote sites are correctly reachable from central site) except the management traffic between SMS and remote gateways because this traffic is not encapsulated in the tunnel but is sent over the Internet.

In the next days I'll apply the sk indicated by Amir that seems address exactly my situation.

Andrea

[the_rock]

I think that might be a good idea, I hope it will help.

Best,

Andy