I have a Checkpoint Spark 1570 appliance at the primary site. We have 2 site-to-site tunnels configured and working properly. Tunnel A is a routed VTI tunnel (required because the third party “A” we are connecting to requires BGP – which was another adventure in learning). Tunnel B is a policy-based tunnel connecting another third party “B”. From the primary site we can access hosts over both tunnels. It is our responsibility to route traffic between the two tunnels so a host on tunnel A can communicate with a host on tunnel B.
I don’t have diagnostic or configuration level access to the hosts on either end of the tunnels, only a web interface to setup a connection between the two from host B. It either fails or is successful - right now it’s failing. I can ping and access both devices web portals from the primary site.
There is a route in the route table of the Checkpoint appliance to the local subnet of tunnel A, the VTI tunnel.
I’ve included that same tunnel A local subnet in the “Site to Site Local Encryption Domain” manual topology which seems to be a system wide setting for all policy-based tunnels. Which, I believe, means under normal circumstances – or for policy-based tunnels – a route is created for that subnet (although it does not appear in the route table).
Anyway, I feel like the device on tunnel A does not have a route (it’s getting all its routes via BGP?) to tunnel B. I’ve tried adding an additional BGP route redistribution to party A’s AS number but did not seem to change anything. Anyone ever had a situation like this?
You would need to check with the bgp peer and see if they are receiving your route for the traffic assuming they negotiated a 0.0.0.0 phase 2 that should be all that is needed
I will check with them. So does a policy-based VPN subnet not get included in the “Default” BGP advertisement from a Check Point then?
No. Because it’s policy based there is no specific route in kernel, it would be part of the default 0.0.0.0/0 route.
Assuming you are distributing all ipv4 static routes into the AS, the BGP peer is either filtering out the 0.0.0.0/0 route, or more likely it has a local static default route which takes priority.
The simpliest fix would be to add a static route on your end for the policy-based VPN subnet via the same route as the default route.
i.e. if your default route goes to 1.1.1.254, and the tunnel b subnet is 192.168.1.0/24 add a static route for 192.168.1.0/24 via 1.1.1.254.
Thank you for sharing knowledge. It looks like the BGP is now advertising. A ping from the host on tunnel A to the host on tunnel B is now making it back to the Check Point at the primary site and being dropped by the Check Point - that pretty much proves the BGP is working I think. I’ve added accept rules on both the incoming and outgoing sections of the firewall policy list but it does not want to let it through. The log says the interface the ping is coming in on is WAN. Any ideas on the firewall policy?
That enturely depends on how your policy currently is.
-
If you have the community in the “VPN” column, then it will need both communities in it (or “Any”).
-
Both the the communities may need the VPN routing option “To center or through center to other satellites, to Internet and other VPN targets”
Ok, looks like I’m entirely missing community as part of this. It looks like that is something I need to buy an activation key for. I’ll look into that.
Ah sorry, I forgot you said it was a 1570 (embedded GAIA) and not a “proper” (full GAIA) mainline appliance, so it’s locally managed through the WebUI I presume?
To be honest I haven’t managed an SMB appliance locally in years and can barely remember what the interface is like. All of the Spark appliances I have access to are fully centrally managed with on-prem management servers.
In theory, in the policy “Site to Site Local Encryption Domain” for tunnel A, you would probably need to put the subnet for site B into it. This might break the Site B tunnel, but give it a try. You will also need the other end of tunnel A to add site B subnet into their local encryption domain.
Or you might have some luck if they were both route based tunnels.
Otherwise get a Smart-1 Cloud Spark Management instance and manage it through that as it will give you option closer to a full blown appliance, but i still couldn’t gaurantee that it would work as I’ve never seen the Spark Management, only the full feeature Smart-1 Cloud.
smart-1 cloud for embedded GAIA works the same, but not really required
run “fw ctl zdebug + drop” in expert mode and check what the traffic is dropping on
Thanks for the help everyone. Turns out tunnel A (VTI) was set to “Encrypt according to routing table” which I changed to the manual setting and the policy-based tunnel B was set to manual and I changed it to “Automatically determine local network topology”. Traffic is now passing from one tunnel to the other.