site-site tunnel. question regarding interesting traffic of 0.0.0.0 / any

muzaffermohammed · ‎05-09-2016

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...

Philip D'Ath · ‎05-09-2016

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.

Aditya Ganjoo · ‎05-09-2016

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.

Jason Lingohr · ‎05-10-2016

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.