Cisco ASA 5525x - IPSEC Tunnel - Allow other networks across the tunnel

[brandon2320]

Hello,

I have an ASA set up with an IPSec tunnel to another host site on our network. The ASA peers with a Fortinet device at our corporate office. The IPSEC tunnel is up and I can get traffic from the subnet 10.2.0.0/16 on the inside interface just fine. However, I have other subnets that get routed to the ASA and need to go through the tunnel. Trying to get traffic sourced from the 10.10.7.0/24 subnet routed to the ASA and through the tunnel to corporate. The routing is good to the ASA as I can ping the inside interface of the ASA but just cannot get to the 192.168.8.0/24 LAN from the 10.10.7.0/24.

There are other posts I found that say you just need a NAT rule and to adjust the crypto map ACL, which I have done and the traffic is still not going over the tunnel. When I use packet tracer in ASDM it shows my traffic dying at the VPN process, so I am stumped as to what the issue would be.

Also, I have verifed the routing between the networks

Any help would be greatly appreciated.

See below for pertaining config:

-The 10.2.0.0/16 is the inside interface subnet that is working

-The 192.168.8.0 is the subnet on the other side of the IPsec

-The 10.10.7.0/24 is the subnet that stops at the ASA

object network NETWORK_OBJECT_192.168.8.0
 subnet 192.168.8.0 255.255.255.0
object network NETWORK_OBJECT_10.2.0.0
 subnet 10.2.0.0 255.255.0.0
object network NETWORK_OBJECT_10.10.7.0
 subnet 10.10.7.0 255.255.255.0

nat (inside,outside) source static any any destination static NETWORK_OBJECT_10.10.7.0 NETWORK_OBJECT_10.10.7.0
nat (inside,outside) source static NETWORK_OBJECT_10.2.0.0 NETWORK_OBJECT_10.2.0.0 destination static NETWORK_OBJECT_192.168.8.0 NETWORK_OBJECT_192.168.8.0 route-lookup
!
access-list CRYPTO_ACL extended permit ip 10.2.0.0 255.255.0.0 192.168.8.0 255.255.255.0 log
access-list CRYPTO_ACL extended permit ip 10.10.7.0 255.255.255.0 192.168.8.0 255.255.255.0 log
!
crypto map OUTSIDE_MAP 1 match address CRYPTO_ACL

Thanks,
Brandon

[Marvin Rhoads]

Can you share the packet-tracer output?

Is there a reason why you didn't specify the destination network in your NAT exemption? As is, it would always exempt 10.10.7.0 - even if the traffic was internet-bound.

Also. both ends need to have the crypto map (or 3rd party equivalent in the case of the Fortinet) in order to for the necessary IPsec SAs.

Have a look at "show crypto ipsec sa" and see if you see one for local network 10.10.7.0 to remote network 192.168.8.0.

[brandon2320]

Hi Marvin,

Thanks for the input. I adjusted the NAT to include the destination. I had it like this before and changed it to test. I am trying everything now ;)

No, I am not seeing any SA's for the network 10.10.7.0. Only for the 10.2.0.0 when I am generating traffic from inside to the 192.168.8.0 network.

See attached for the packet tracer.

Thanks,

Brandon

[Marvin Rhoads]

The packet-tracer GUI seems to be saying an ACL is causing it to fail on the VPN phase. That doesn't make sense given what you shared above though. I've know the GUI to sometimes mislead though.

Can you run it from cli so we can see more detail? e.g.:

packet-tracer input inside tcp 10.10.7.10 http 192.168.8.96 http detail

...assuming your inside interface is named "inside"

[brandon2320]

Here you go - see attached.

[rizwanr74]

Does remote-tunnel administrator allow your subnet "10.10.7.0 255.255.255.0" traverse via the tunnel ?

[brandon2320]

Yes, I just posted the policy above from the remote end.

[Marvin Rhoads]

I'm with rizwanr74 on this - it looks like the remote side doesn't have a matching crypto map entry so there's not a corresponding IPsec SA that the VPN can put the encrypted packets into.

The packet tracer output and the fact that "show crypto ipsec sa" doesn't show the SAs for the 10.10.7.0/24 network both lead to that conclusion.

[brandon2320]

Okay, thanks guys. I think you guys are right :)

I just checked the Fortinet Policy at the remote device and it looks like I did not set a policy allowing anything from source 10.10.7.0/24 to the 192.168.8.96. I will adjust the policy tomorrow and let you know the results.

[brandon2320]

Actually, after reviewing the Firewall policy on the other side it looks right.

See below output from the CLI "sh firewall policy" on the Fortigate:

"internal1" = 192.168.8.0/24
"SERVER" = 192.168.8.96/32
"DATA CENTER" = 10.2.2.0/24
"MPLS" = 10.10.7.0/24

edit 69
        set srcintf "internal1"
        set dstintf "wan1"
            set srcaddr "SERVER"             
            set dstaddr "DATA CENTER" "MPLS"             
        set action ipsec
        set schedule "always"
            set service "ANY"             
        set inbound enable
        set outbound enable
        set vpntunnel "DATACENTER-WINDSTREAM"

The Data Center subnet 10.2.2.0/24 works and the the 10.10.7.0/24 is not working. Could this be failing because I am only
allowing traffic to the host .96 IP address? The policy for the 192.168.8.0/24 and 10.2.2.0/24 is naming the entire network
and I have the non-working policy to only permit traffic from the 10.10.7.0/24 network to the host IP 192.168.8.96. I would not think so,
but it is a difference in the policy

Thanks,

Brandon

[rizwanr74]

Hi Brandon,

"Could this be failing because I am only allowing traffic to the host .96 IP address?"

Whether it is host IP address or entire subnet mask that you include in the tunnel at one end and you must match them at other end as well, eye for an eye match.

"I have the non-working policy to only permit traffic from the 10.10.7.0/24 network to the host IP 192.168.8.96."

If you can permit the missing subnet "10.10.7.0/24" on Fortigate gear should resolve your problem and if that is not doable on Fortigate device, then you can put in place a dynamic-policy nat on ASA and this is an alternate solution could work as well.

Hope that answers your question.

Thanks

[brandon2320]

I have confirmed the policy on the Fortinet posted above and the crypto ACL matches. I am permitting 10.10.7.0/24 to host 192.168.8.96/32 on the ASA side. And the policy on the Fortinet is allowing traffic to the 192.168.8.96/32 from the 10.10.7.0/24.

In the fortinet, there is another policy permitting traffic between entire subnets 192.168.8.0/24 and 10.10.7.0/24. But the policy permitting the traffic between 10.10.7.0 and 192.168.8.96 is first in the policy rules.

See attached Text with ACL/Policy for each side. I have attached  snippet of both relevant configurations.

Anything else it could be?
 

[rizwanr74]

Hi Brandon,

Line "A":  "I am permitting 10.10.7.0/24 to host 192.168.8.96/32 on the ASA side. And the policy on the Fortinet is allowing traffic to the 192.168.8.96/32 from the 10.10.7.0/24."

If the line "A" is true, then please make sure that you have nat exemption in is placed for source and destination mentioned in the line "A", and you make sure that ASA can reaches the subnet  "10.10.7.0/24" via the inside interface, a static route for sake, can you confirm this?

thanks

[brandon2320]

Hi Rizwanr74, thanks for the suggestion. Yes, the nat exempt is there and the routing is good. I have a static route on the inside interface to the 10.10.7.0 network and I can ping the inside interface of the ASA from the 10.10.7.0/24 network. And vise versa.

Here is what I have for the NAT exemption:

object network NETWORK_OBJECT_192.168.8.0
 subnet 192.168.8.0 255.255.255.0

!

nat (DATA_VLAN,outside) source static NETWORK_OBJECT_10.10.7.0 NETWORK_OBJECT_10.10.7.0 destination static NETWORK_OBJECT_192.168.8.0 NETWORK_OBJECT_192.168.8.0 route-lookup.

Does that look right to you?

Thanks,

Brandon

[brandon2320]

While troubleshooting this, should I see hits on the ASA crypto ACL if at least that side was right. I am sourcing the traffic from the 10.10.7.0 network and not seeing any hits.

FLDC-ASA-2# sh access-list | inc CRYPTO_ACL
access-list CRYPTO_ACL line 2 extended permit ip 10.10.7.0 255.255.255.0 host 192.168.8.96 log informational interval 300 (hitcnt=0) 0xf36c2de4