05-09-2016 11:07 PM
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.
Regards,
Muzaffer...
05-09-2016 11:31 PM
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.
05-09-2016 11:35 PM
Hi,
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.
Regards,
Aditya
Please rate helpful posts.
05-10-2016 01:17 AM
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 172.0.0.0 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):
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Phase: 5
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Phase: 6
Type: VPN
Subtype: encrypt
Result: ALLOW
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
I know this works, because we're doing it right now on a live ASA/tunnel.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide