Site-Site tunnel between Cisco ASA and Check Point Security Gateway.
Local network: (Cisco ASA)
0.0.0.0 / 0.0.0.0
Remote network: (Check Point)
10.80.0.0 / 24
10.16.5.0 / 25
Reason for using 0's/0's: Conflict in local and remote subnets. Remote end subnet of 10.16.5.0/25 is covered by local subnet of 10.16.0.0/12.
(NAT over the VPN tunnel is not preferred in our case neither we want to split 10.16.0.0/12 to exclude 10.16.5.0/25 out)
object-group network LOCAL_NETWORK
network-object 0.0.0.0 0.0.0.0
object-group network REMOTE_NETWORK
network-object 10.80.0.0 255.255.255.0
network-object 10.16.5.0 255.255.255.128
access-list VPN-TEST extended permit object-group LOCAL_NETWORK object-group REMOTE_NETWORK object-group TCP_UDP_ICMP
access-list VPN-TEST extended permit object-group REMOTE_NETWORK object-group LOCAL_NETWORK object-group TCP_UDP_ICMP
crypto map VPN 340 match address VPN-TEST
Would there be any issues with this setup in terms of tunnel stability and security?
I haven't done such setup myself yet, if anybody had such experience before would be glad if I could get some assistance/advise.
You'll be able to build the VPN, but you are still going to have the addressing issue.
You'll send a packet from your 10.16.5.0/25 range to the remote end. When they reply they'll think it is a local address and wont send it over the VPN.
Conversely, when they send you a packet from 10.16.5.0/25 it will go over the VPN but you wont send a packet back over the VPN, you'll route it locally.
You need to either use NAT, renumber, or select a non-overlapping address range.
It should not be an issue if there are no conflicting VPN tunnels/subnets preceding this tunnel.
But you need to configure the NAT for the remote subnets only as it will not send it over the tunnel.
Please rate helpful posts.
The above responses are inaccurate. Using a more specific route for the 10.16.5.0/25 network works. So if the existing routes looked like this:
route outside 0.0.0.0 0.0.0.0 10.1.1.1 1
route inside 10.0.0.0 255.0.0.0 10.2.2.2 1
route inside 188.8.131.52 255.0.0.0 10.2.2.2 1
And you simply added this:
route outside 10.16.5.0 255.255.255.128 10.1.1.1 1
(Note the route for the specific network points to outside, and outside's next hop.)
This works, because the routing decision in the engine comes before crypto (and of course, furthermore, a more specific route would override the broader 10/8 route) -- this can be seen in this packet-tracer (reduced/redacted):
I know this works, because we're doing it right now on a live ASA/tunnel.