IPsec client matching s2s NAT issue

[the-lebowski]

Hi

We have a remote site (Paris) with a 5512 with a couple s2s tunnels and RA vpn client (anyconnect and IPsec).  Anyconnect has no issue but the ipsec client cannot pass traffic to the LAN.  The subnet behind the fw is 10.176.0.0/16 and the RA client pool is 10.172.28.0/24.  However we have a s2s tunnel that nat's 10.0.0.0/8 and it appears that the traffic destined for the RA vpn IPSEC clients is being matched to that rule and preventing connectivity to local resources via the ipsec vpn client.

......

        hits=485017, user_data=0x7fffa5d1aa10, cs_id=0x0, use_real_addr, flags=0x0, protocol=0

        src ip/id=10.176.0.0, mask=255.255.0.0, port=0

        dst ip/id=10.0.0.0, mask=255.0.0.0, port=0, dscp=0x0

        input_ifc=inside, output_ifc=outside

...

Manual NAT Policies (Section 1)

1 (inside) to (outside) source static Paris_Network Paris_Network   destination static Remote2_LAN_Networks Remote2_LAN_Networks no-proxy-arp route-lookup

    translate_hits = 58987, untranslate_hits = 807600

2 (inside) to (outside) source static Paris_Network Paris_Network   destination static DM_INLINE_NETWORK_2 DM_INLINE_NETWORK_2 route-lookup

    translate_hits = 465384, untranslate_hits = 405850

3 (inside) to (outside) source static Paris_Network Paris_Network   destination static Remote1_Networks Remote1_Networks route-lookup

    translate_hits = 3102307, untranslate_hits = 3380754

4 (outside) to (inside) source static Paris_RA_VPN Paris_RA_VPN   destination static Paris_Network Paris_Network route-lookup

    translate_hits = 0, untranslate_hits = 3

This works at other sites with almost identical configuration but for whatever reason it doesn't work here.  I cannot specify individual subnets for the s2s tunnel as there would be too many.  Can someone help me out and tell me why I can't get this working?

[Jouni Forss · Accepted solution]

Hi,

So you are saying that the AnyConnect is working but not IPsec? What is the VPN network of the AnyConnect? Is it outside the 10.0.0.0/8 network?

You should be able to override the L2L VPN NAT configuration by simply configuring a separate NAT for the LAN to VPN Pool traffic at the very top of your NAT configurations

For example

object network PARIS-LAN

subnet 10.176.0.0 255.255.0.0

object netwok PARIS-VPN-POOL

subnet 10.172.28.0 255.255.255.0

nat (inside,outside) 1 source static PARIS-LAN PARIS-LAN destination static PARIS-VPN-POOL PARIS-VPN-POOL

This should make sure that the first rule on the ASA is the NAT rule that matches the VPN Client to LAN traffic. Other traffic to the L2L VPN should still hit the original NAT rule meant for L2L VPN

If this doesnt work then we need to look at the configuration closer.

Hope this helps

Please do remember to mark a reply as the correct answer if it answered your question.

Feel free to ask more if needed

- Jouni

[the-lebowski]

YES! Thank you JouniForss...That did it.

Nat statement now looks like this:

nat (inside,outside) source static Paris_Network Paris_Network destination static Paris_RA_VPN Paris_RA_VPN route-lookup

Regarding the anyconnect client, it uses the same IP pool but per cisco because its anyconnect (SSL) it doesn't match the ipsec rules that the ipsec client does.   In my scenario the anyconnect and ipsec clients were identical, IE same pool, group policy, tunnel list, just different tunneling protocols.

....

[Jouni Forss]

Hi,

Glad to hear it worked.

I am not sure what the actual situation is. Now that I think of it since you are doing NAT0 configuration for both the L2L VPN and VPN Client connections then the single NAT0 configuration for L2L VPN that contains the whole network 10.0.0.0/8 should already handle all that is needed for both the L2L VPN and VPN Client.

Main thing is that it works but as I said I am not sure what caused the actual problem since all the other 10.0.0.0/8 subnets are located behind "outside" interface.

Please do remember to mark a reply as the correct answer if it answered your question.

- Jouni

[the-lebowski]

I agree...it was an odd problem and seems to be unique to this FW.  Thanks again for your help.