So for example if the Palo is manually set for 192.168.1.0/24 as a Proxy-ID and the Check Point proposes a subset of 192.168.1.0/25 it will fail, whereas a Cisco or Check Point would accept that subset proposal. Just like on Juniper (strange coincidence there!), a Phase 2 proposal by the Check Point that is a subset of the manual Proxy-IDs will NOT be accepted by the Palo. On the Palo side typically static routes are used to route traffic bound for the Check Point side into the VPN tunnel interface leading to the peer.Ģ) Set explicit Proxy-IDs for the tunnel on the Palo side to mimic a domain-based setup, but then the Check Point subnet proposals in Phase 2 must EXACTLY match how the Proxy-IDs are defined on the Palo side. In this case there should not be any manual Proxy-IDs specified on the Palo side.
This will cause the Check Point to propose a universal tunnel in Phase 2, yet still use the VPN Domains for tunnel and peer determination. When attempting an interoperable VPN between a Check Point and a Palo Alto you have basically two options:ġ) In your VPN Community settings on the Check Point end under "VPN Tunnel Sharing" set "One tunnel per gateway pair". Palo Alto firewalls employ route-based VPNs, and will propose (and expect) a universal tunnel (0.0.0.0/0) in Phase 2 by default however the Palo can be configured to mimic a domain-based setup by configuring manual Proxy-IDs.
0 kommentar(er)
