Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
andreac
Participant
Jump to solution

Managing gateways using IPSEC site2site VPN

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

 

 

 

0 Kudos
1 Solution

Accepted Solutions
AmirArama
Employee
Employee

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

 

View solution in original post

(1)
16 Replies
AmirArama
Employee
Employee

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

 

(1)
the_rock
Legend
Legend

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

Best,

Andy

0 Kudos
andreac
Participant

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

0 Kudos
the_rock
Legend
Legend

100%...works even on R81.20

Andy

0 Kudos
the_rock
Legend
Legend

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

Best,

Andy

0 Kudos
andreac
Participant

Thank you Amir.

I didn't found that sk.

0 Kudos
RamGuy239
Advisor
Advisor

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.

Certifications: CCSA, CCSE, CCSM, CCSM ELITE, CCTA, CCTE, CCVS, CCME
the_rock
Legend
Legend

Super valid point @RamGuy239 

Best,

Andy

0 Kudos
andreac
Participant

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
Legend
Legend

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

Andy

0 Kudos
andreac
Participant

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

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
andreac
Participant

VPN.png

 

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

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
andreac
Participant

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

0 Kudos
the_rock
Legend
Legend

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

Best,

Andy

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events