Wierd NAT behaviour with AnyConnect clients

[marioderosa2008]

Hi there,

I have a problem with our AnyConnect clients not being able to access a particular resource that exists on a 3rd party VPN network.

Both AnyConnect clients & 3rd Party Site to Site VPN terminate on the Outside Interface of the ASA.

There is a NAT setup between the 3rd Party network and our ASA so that we share the 192.168.40.0/24 subnet. The first /25 is for 3rd party hosts & the second /25 is for our hosts.

We are trying to access a service on 192.168.40.10             

The NAT rule that I have in place to achieve this is

Source = VPN-Subnet Dest = 192.168.40.0/25 Service = any

XLate Source = 192.168.40.129(PAT) XLate Dest = Original  XLateService = Original  

With the NAT rule like this, the webpage DOES NOT work. We get a SYN Timeout, and when looking at the logs, the AnyConnect client source address does not get PAT'd to 192.168.40.129

BUT....

if I change the NAT rule to this....

Source = VPN-Subnet Dest = 192.168.40.0/25 Service = any

XLate Source = 192.168.40.129(PAT) XLate Dest = 192.168.40.10  XLateService = Original 

THIS WORKS! The source address does get PAT'd to 192.168.40.129.

BUT.... the problem is now, that if the AnyConnect client tries to access any other IP in 192.168.40.0/25, the destination address gets changed all the time to 192.168.40.10.

I am new to ASA 8.3, so I was wondering whether I am missing something with how NAT rules have changes since earlier versions of ASA...

Can anyone help?

Thanks

Mario De Rosa

[marioderosa2008]

you can see that the RPF check is hitting a generic rule further down the list of NAT rules... I dont know why that rule is there or what it is doing.

vpngw1# packet-tracer input outside tcp 10.127.252.100 24654 192.168.40.10 80

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (any,any) source static grp-vpn-ssl-enc-domain grp-vpn-ssl-enc-domain destination static ssl_vpn_assigned_network ssl_vpn_assigned_network
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.40.10/80 to 192.168.40.10/80

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit ip object Obj-AnyConnectDC1Subnet object obj-host-Wearekier
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (outside,outside) source dynamic Obj-AnyConnectDC1Subnet obj-vpn-host-kier destination static Obj-Subnet-KierIntegration Obj-Subnet-KierIntegration
Additional Information:

Phase: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (any,any) source static grp-vpn-ssl-enc-domain grp-vpn-ssl-enc-domain destination static ssl_vpn_assigned_network ssl_vpn_assigned_network
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 196710245, packet dispatched to next module

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

[Jouni Forss · Accepted solution]

Hi,

There has been some known bugs with Twice NAT / Manual NAT configurations in the new softwares. For example some problems have been caused by using same "object-group" in multiple NAT statements and some have been caused by using "object-group" inside other "object-group".

Result could have been for example that the NAT rules arent processed in the correct order.

- Jouni

[marioderosa2008]

I just dont understand why the RPF check uses a completely different NAT rule in the NOT working screenshot, and uses the correct NAT rule in the working screenshot

I will try and create object groups with different names...

its a pitty you cannot just specify the subnet rather than naming an object group all the time.

[marioderosa2008]

Hi,

I have tried renaming all groups in this new rule, but it still does not work...

the new rule is rule number 1, so it shouldnt even be reaching rule 10 during NAT. The packet is not matching rule 1 when it should be.

Any other ideas?

thanks

Mario

[marioderosa2008]

I do not understand why there are two NAT rules being hit every time... is the ASA doing an RPF check or something?

[Jouni Forss]

Hi,

The ASA check that the same NAT rule is matched on the return direction also.

Usually though this results in a failure if they dont match. But in this case it doesnt seem to.

- Jouni

[Jouni Forss]

Hi,

I cant see any screenshots

- Jouni