---
title: "IPSec Troubleshooting"
slug: "troubleshooting"
updated: 2026-04-07T09:08:36Z
published: 2026-04-07T09:08:36Z
canonical: "support.perimeter81.com/troubleshooting"
stale: true
---
> ## Documentation Index
> Fetch the complete documentation index at: https://support.perimeter81.com/llms.txt
> Use this file to discover all available pages before exploring further.
# IPSec Troubleshooting
The following guide presents a methodical way through which you'll be able to self diagnose and resolve some of the common errors encountered when setting up an IPSec site-to-site connection.
Examining the logs from your router/firewallThe most important tool that can assist you in analyzing networking issues is of course the logs derived from the edge device (your firewall or router).
We highly recommend exporting it and looking for errors and for details related to the topics mentioned below for an optimized workflow.
## The console indicates the tunnel is down
### Mismatched Parameters
Every site-to-site connection depends on filling in the above fields with the exact same values in both the Check Point SASE Management Platform **AND** your firewall/router Management Interface. A mismatch that occurs between any of these would prevent the tunnel from establishing, so your very first step should be making sure that they are absolutely identical in both platforms. When filling in **IKE Mode** choose **Main Mode**(aggressive mode is not supported).
In addition to these steps, it is important to verify that you've entered the same **shared secret** (sometimes referred to as PSK) on both platforms.
### Network Addresses
Another common error may occur due to confusing terminology used to describe the different addresses involved in the process of a tunnel establishing.
When filling in the parameters inthe Check Point SASE platform:
- **Public IP/Remote ID** refers to the public IP address through which your on-premises network/VPC connects to the internet.
- **Check Point SASE Gateway Proposal Subnet** refers to your Check Point SASE subnet (in CIDR notation). This value must be identical to the value set as **Remote Subnet** in your router/FW/IaaS platform, therefore if you choose to set it to 0.0.0.0/0 on one platform you must set on the other.
- **Remote Gateway Proposal Subnet** refers to your on-premises/cloud network subnet (in CIDR notation). This value must be identical to the value set as **Local****Subnet** in your router/FW/IaaS platform, therefore if you choose to set it to 0.0.0.0/0 on one platform you must set it to the same on the other.
Important
Unless specified differently in our designated guide, we recommend setting up the exact address range and not 0.0.0.0/0 (any).
## The console indicates the tunnel is up, but I am still unable to access internal resources
### Route Table
While some router/firewall interfaces automatically adjust the route table upon the creation of a tunnel, others do not. Make sure you have an inbound rule allowing traffic from your Check Point SASE subnet to your internal network, as well as an outbound rule allowing traffic from your internal network to the Check Point SASE subnet.
### Firewall Rules/Security Group
- IPSec based connections utilize the following ports: UDP 4500; UDP 500.
Make sure that these are open for both inbound and outbound traffic.
- Check your current firewall rules/the security group associated with the resource that you're trying to reach, and verify that no rules prevent access to it. Rules hierarchy may also affect this.
### Subnets
A subnet overlap would interfere with traffic flow.
Make sure that:
- Your Check Point SASE address range does not overlap with a subnet within your VPC/internal network.
- Each branch within the VPC/on-premises network has its own unique subnet.