07-09-2013 07:48 AM - edited 02-21-2020 07:00 PM
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
Solved! Go to Solution.
07-10-2013 05:17 AM
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
07-12-2013 02:04 AM
Hi,
The only reason for seeing a NAT rule that is configured at the very top for not getting applied are
If there is no clear obvious reason for the NAT rules not matching then I would suggest opening a TAC case and/or upgrading/downgrading to some other software level to determine if a software bug is the cause.
I am not sure if you have mentioned the software level you are using?
- Jouni
07-09-2013 07:58 AM
Hi,
If you dont have a large NAT configuration, could you provide it in CLI format.
I am not sure about the setup either.
You are trying to connect from a VPN Client connection to a remote network behind a L2L VPN connection?
What is the encryption domain of the L2L VPN? What are the source and destination networks?
Can you clarify the situation a bit.
- Jouni
07-09-2013 08:34 AM
Thanks Jouni,
yes, there are nearly 200 NAT rules... and they have all been configured through ASDM, so they are all object groups of some sort... to print out the config would be very confusing for anyone! lol
So, to clarify...
Yes, we have an anyconnect client which gets handed an IP out of a pool of addresses from say 10.200.200.0/24
The VPN client tries to access a web server with IP address of 192.168.40.10 which is on a remote site to site VPN.
The VPN networks are...
Remote network: 192.168.40.0/25
Local network: 192.168.40.128/25
There is a NAT rule which is configured as below...
source 10.200.200.0/24 dest 192.168.40.0/25 serv ANY -> xsource 192.168.40.129 (PAT) xdest Original xserv Original
Both the Anyconnect clients & Site to Site VPNs terminate on the same ASA interface, Outside.
With the NAT rule configured above, the PAT does not happen. When looking at the logs, the source address of 10.200.200.x is maintained and not changed to 192.168.40.129.
Maybe there is a NAT rule conflict or something?
I hope that makes more sense.
Mario
07-09-2013 09:01 AM
Hi,
Essentially if I were to configure a NAT rule on the basis of the information given by you it would look something like this
object network VPN-POOL
subnet 10.200.200.0 255.255.255.0
object network REMOTE-LAN
subnet 192.168.40.0 255.255.255.128
object network VPN-POOL-PAT
host 192.168.40.129
nat (outside,outside) source dynamic VPN-POOL VPN-POOL-PAT destination static REMOTE-LAN REMOTE-LAN
This should work just fine for the VPN Client users towards the Remote LAN network behind the L2L VPN.
Which leads me to believe that there might be problem with the NAT ordering. Some earlier NAT rule might be using parameters/objects which match the traffic and therefore override this new NAT rule.
Naturally you could just enter the above NAT configuration by addint the order/priority number of 1 which would enter it at the very top of the NAT rules. In other words it would be the first NAT configuration to be matched. In CLI format it would mean basically adding this configuration.
nat (outside,outside) 1 source dynamic VPN-POOL VPN-POOL-PAT destination static REMOTE-LAN REMOTE-LAN
The typical way I would troubleshoot this would be to use "packet-tracer". Especially in the cases of NAT problems its a very valuable tool and instantly tells you which NAT rules are hit.
So using your given information you could do the following
You could basically use the following type of "packet-tracer" command
packet-tracer input outside tcp 10.200.200.x 12345 192.168.40.10 80
Naturally interface names, IP address (10.200.200.x) and destination ports etc might change.
Then if you could post the output of that command here we would probably know what the problem is
- Jouni
07-12-2013 01:35 AM
Ok, i have created a new nat rule at number 1... i have duplicated the object groups so that I am not using the same ibjects more than once...
Manual NAT Policies (Section 1)
1 (outside) to (outside) source dynamic any obj-vpn-host-kier2 destination static Obj-Subnet-KierIntegration2 Obj-Subnet-KierIntegration2
translate_hits = 0, untranslate_hits = 0
07-12-2013 02:04 AM
Hi,
The only reason for seeing a NAT rule that is configured at the very top for not getting applied are
If there is no clear obvious reason for the NAT rules not matching then I would suggest opening a TAC case and/or upgrading/downgrading to some other software level to determine if a software bug is the cause.
I am not sure if you have mentioned the software level you are using?
- Jouni
07-12-2013 04:21 AM
Hi Jouni,
I have resolved this by following up your suggesting about using duplicate object groups in NAT not being a good thing.
essentially, I have no proof, but i think that the issue was the following...
since in the new NAT format, every rule your create does both source and destination nat. i think we had two rules which were both Outside,Outside and they were both using the same object group for the static deestination NAT.
On the new rule, as soon as I created a new object for the same subnets but with a different name, it seems to work fine now...
Thanks very much!!
Mario
07-12-2013 04:26 AM
Hi,
Glad to hear you got it working
- Jouni
07-09-2013 10:13 AM
Thanks very much!
I will try your recommendations and get back to you.
Can you quickly explain the new nay syntax?
Cheers
Mario
Sent from Cisco Technical Support iPhone App
07-09-2013 10:14 AM
Sorry *nat syntax :)
Sent from Cisco Technical Support iPhone App
07-09-2013 10:16 AM
Hi,
I wrote a document about NAT 8.3+ here on the CSC. You can take a look at it.
Still need some updating at some point when I have a energy for that.
https://supportforums.cisco.com/docs/DOC-31116
Then there is document comparing the old and the new NAT format
https://supportforums.cisco.com/docs/DOC-9129
- Jouni
07-10-2013 04:58 AM
Hi Jouni,
OK, I have done what you recommended and I can definately see a difference in a working NAT rule and a non working NAT rule, but I still dont quite understand what is happening.
I have posted two screenshots, one with a working NAT rule and a Not working NAT rule...
On the working NAT rule you can see that the source IP does get dynamically changed.
But on the not working NAT rule you can see that the source does not get changed and infact, it seems to hit an "any, any" NAT rule.
can you spot why the not working NAT rule is different from the working NAT rule?
Mario
07-10-2013 05:03 AM
NOT Working
Working
07-10-2013 05:09 AM
Ah now they are there,
Well the first one seems to be showing 2 different NAT rules.
I would much rather see the full output in the CLI format if possible
You could for example run the following commands
packet-tracer input outside tcp 10.127.252.100 24654 192.168.40.10 80
Also even though I cant see the contents of the objects in the RPF check of the NAT that is not working it has source and destination interface configured as "any" which I wouldnt really suggest. I am not quite what the purpose of that NAT configuration even is.
- Jouni
07-10-2013 05:13 AM
the NAT rule is right at the toip of the list and as you can see, there are no hits at all...
vpngw1# sh nat
Manual NAT Policies (Section 1)
1 (outside) to (outside) source dynamic Obj-AnyConnectDC1Subnet obj-vpn-host-kier destination static Obj-Subnet-KierIntegration Obj-Subnet-KierIntegration
translate_hits = 0, untranslate_hits = 0
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