asa vpn client

[marypoppins]

Hi EveryBody,

I would like to ask some help in order to correct a client vpn tunnel. I'm not familiar with asa, so please don't laught if I write something stupid

So I inherit an asa, which has two used phisical interface, and more vlan. Outside, office, branch and management. I use my computer on the management vlan, and I can reach computers on the office (192.168.12.0/24) and branch (192.168.10.0/24). I would like to achieve that I connect from home thrught a vpn, and I should reach the 12.x and 10.x network as I was in those networks (because of the microsoft wirewall permit trafic only the local network).

I inherit a vpn config to which I added my user.

I try to quote only the relevant config part:

ssh 192.168.99.0 255.255.255.0 management

access-list nonat_management extended permit ip 192.168.99.0 255.255.255.0 192.168.99.0 255.255.255.0

access-list nat_management_branch extended permit ip 192.168.99.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list nat_management_office extended permit ip 192.168.99.0 255.255.255.0 192.168.12.0 255.255.255.0

ip local pool ippool 192.168.99.100-192.168.99.200

nat-control
global (outside) 1 interface

nat (management) 0 access-list nonat_management
nat (management) 5 access-list nat_management_office
nat (management) 10 access-list nat_management_branch

dhcpd address 192.168.99.50-192.168.99.79 management
dhcpd enable management

group-policy l2tp internal
username monty password ** == nt-encrypted
username monty attributes
vpn-tunnel-protocol l2tp-ipsec
vpn-framed-ip-address 192.168.99.99 255.255.255.0
tunnel-group DefaultRAGroup general-attributes
address-pool ippool
default-group-policy l2tp
tunnel-group DefaultRAGroup ipsec-attributes
pre-shared-key ****
tunnel-group DefaultRAGroup ppp-attributes
authentication ms-chap-v2

I don't quote the crypto parameters, because I can connect to asa, I think I have problems with the nat or access-rules.

I have a local ip pool 192.168.99.100-192.168.99.200, but I fix the ip with the vpn-framed-ip-address 192.168.99.99 255.255.255.0

When I connect and try to reach the computers the following happened:

I can reach only a freenas 192.168.12.2, and I can see in its log that I connected with 192.168.99.99 (vpn-framed-ip-address)

I can't reach the computers on the networks, however I have two nat rules, which are working when I'm in the office 99.0 network

access-list nat_management_branch extended permit ip 192.168.99.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list nat_management_office extended permit ip 192.168.99.0 255.255.255.0 192.168.12.0 255.255.255.0

It looks that these two nat rules don't work with my vpn client.

And It is very important to reach the asa with ssh through the tunnel, but I can't.

I'm not sure if it is good that vpn client ip is in the management network, maybe a should change it to a separate network:

forexample 192.168.95.0/24

An asa vpn for dummies or Any help is appreciated,

thanks a lot

[Shrikant Sundaresh]

Hi Chris,

There are two things which need to be corrected for the nat rules.

1. no matching global statements

2. the nat is applied for the wrong interface (i think)

If i am not mistaken, when you VPN to the ASA from home, you would be connecting to the outside interface. Thus the VPN pool exists on the outside interface, and that should be the source interface for nat.

So the nat rules should be:

nat (outside) 5 access-list nat_management_office
nat (outside) 10 access-list nat_management_branch

global (office) 5 interface

global (branch) 10 interface

I think this will achieve what you are looking for.

Secondly, if you want ssh access to management over the VPN, then you need to have the following command:

management-access management

If it says that a command like this already exists, then do "show run management-access", and a "no ____________" for whatever shows up in the output.

Hope this helps.

-Shrikant

P.S.: Please mark this question as answered, if it has been resolved. Do rate helpful posts. Thanks.

[Antonio Knox]

You should definietely change the network addressing for your VPN users.  You want traffic to route through the correct interface, and VPN traffic will come from the outside interface.  This will cause routing issues because the 192.168.99.0/24 network will have routes pointing to the Management interface and the outside interface.

I'm not certain of the method of authentication that you are planning to use, but you can still get a feel for the type of configuration that you should be working towards here:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080930f21.shtml

If this doesn't help, let me know. I will tailor answers to more specific questions about what you may not understand.

Please rate helpful posts.

[marypoppins]

Thank you for your answers.

I use pre-shared key remote access vpn. I have three inside network:

192.168.12.0/24  (office) (can use internet)

192.168.10.0/24  (branch) (can use internet)

192.168.99.0/24 (can use internet)

global (outside) 1 interface
global (branch) 10 interface
global (office) 5 interface

nat (outside) 5 access-list nat_vpn_office outside (***)

nat (branch) 1 192.168.10.0 255.255.255.0
nat (office) 0 access-list nonat_office (some PC have to reach the office PCs)

nat (office) 1 192.168.12.0 255.255.255.0 (to reach the internet)
nat (management) 0 access-list nonat_management (it is a rule for hairpinning, but I don't know it is used, i have to test it)
nat (management) 5 access-list nat_management_office (I have to reach the branch and office network, as if I had been on that network)
nat (management) 10 access-list nat_management_branch

I changed the pool and remove my  user vpn-framed-ip-address, so my client pc ip is 192.168.90.100

ip local pool ippool 192.168.90.100-192.168.90.110 mask 255.255.255.0

The rule I added last, in order to reach the office as if my pc had been there (I can't reach the shares if I use nat 0)

nat (outside) 5 access-list nat_vpn_office outside

access-list nat_vpn_office extended permit ip 10.10.10.0 255.255.255.0 192.168.12.0 255.255.255.0

(my home network is 10.10.10.0/24)

When I tried this the log said:

Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside:192.168.90.100/42852 dst office:192.168.12.2/445 denied due to NAT reverse path failure
Apr 16 2011 16:10:00: %ASA-7-609002: Teardown local-host buno:192.168.12.2 duration 0:00:00
Apr 16 2011 16:10:00: %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x1FE35368, sequence number= 0x41) from x.x.213.97 (user= monty) to x.x.217.184.  The decapsulated inner packet doesn't match the negotiated policy in the SA.  The packet specifies its destination as 192.168.12.2, its source as 169.254.24.21, and its protocol as 6.  The SA specifies its local proxy as x.x.217.184/255.255.255.255/17/42246 and its remote_proxy as x.x.213.97/255.255.255.255/17/42246.

I don't know how is it possible asymmetric nat?

Could you give me any advice? Why this error message is?

Could you help me to interpret the 'show nat' results:

match ip outside 10.10.10.0 255.255.255.0 pubwlan 192.168.12.0 255.255.255.0
    dynamic translation to pool 5 (No matching global)

What does it mean exactly?

thank you

[marypoppins]

nobody knows the secret?

[Shrikant Sundaresh · Accepted solution]

Hi Chris,

The following command should help:

access-list nonat_office permit 192.168.12.0 255.255.255.0 192.168.90.0 255.255.255.0

This way, traffic returning from office subnet to the VPN pool will be exempted from nat. And thus you wont get the rpf-check failure.

Also, you need to change this:

access-list nat_vpn_office extended permit ip 10.10.10.0 255.255.255.0 192.168.12.0 255.255.255.0

(traffic coming over the remote access VPN would be sourced from the VPN pool. Not your home network.)

so you should have:

no access-list nat_vpn_office extended permit ip 10.10.10.0 255.255.255.0 192.168.12.0 255.255.255.0

access-list nat_vpn_office extended permit ip 192.168.90.0 255.255.255.0 192.168.12.0 255.255.255.0

nat (outside) 5 access-list nat_vpn_office outside

Hope this helps, and sorry for the delay.

-Shrikant

P.S.: Please mark the question as answered if it has been resolved. Do rate all helpful posts. Thanks.

[marypoppins]

You wrote: "and sorry for the delay. ", never mind I say thank you, and thank you

You did it so Thank you very much!

I would like to ask some details

access-list nonat_office permit 192.168.12.0 255.255.255.0 192.168.90.0 255.255.255.0

Does the above rule mean, that my cremote computer is accessible from the 192.168.12.x, while the vpn is online?

I am confused about nat, I thougth when a packet arrives from an interface, and nat occures, the translation will be stored, so the asa automaticly knows where the return packet have to forward (in my case to the vpn tunnel)...

Could you help me to interpret a line from the 'show nat' results: (now there is no 10.10.10.0 in my config, it just an example)

match ip outside 10.10.10.0 255.255.255.0 pubwlan 192.168.12.0 255.255.255.0
    dynamic translation to pool 5 (No matching global)

Does it mean: packets comming from the outside interface with source network 10.10.10.0/24 which want to travels to the interface pubwlan destination network 192.168.12.0/24 should be translate, but there is no global pool? But what does it mean the dynamic translation to POOL 5? What is the pool 5?

And a final question: When I connect to asa, on my client pc the default route change to forward all packets to the asa. I would like if my default route remain untouched, and route only the 192.168.12.0/24 and the 192.168.10.0/24 packets into the tunnel. Is it possible to control the client side route via the asa config or should I use something batch file on my client to correct it?

[Shrikant Sundaresh]

Hey Chris,

Great to know that everything's working

Here are explanations to the questions you asked.

The nonat_office access-list is used to exempt the traffic mentioned in the acl from being natted. However, this does not mean that they have access to the device on your remote site. It would be true in a Lan-Lan tunnel scenario, but not in a remote access VPN setup.

You are right about the nat translation being stored on the ASA.

Consider this scenario:

Packet arrives on VPN: 192.168.90.100 -> 192.168.12.10

This packet is on the outside interface. So now for it to go to the inside, it will see what all NATs apply to the packet.

nat(outside),global(office) applies, so the packet now becomes: 192.168.12.1 -> 192.168.12.10

no NAT rules apply for the destination, so the NAT part is done. Now it does a reverse path check, to see if the same nat rules are hit.

Reverse packet: 192.168.12.10 -> 192.168.12.1

Source NAT rule nat (office) global (outside) applies, and 192.168.12.1 gets UN-NAT to 192.168.90.100.

So it sees that incoming traffic and outgoing traffic are matching different sets of nat rules. (Outgoing has 1 extra).

Thus to make the same NAT rules apply to the return traffic, we apply a NAT exempt, and as a result the source ip does not get natted.

I will get back to you on the interpretation of the "show nat"

Meanwhile, you can find the config guide for configuring Split Tunnel for the Remote VPN clients. This way, only traffic that matches the Split-tunnel-ACL, goes over the tunnel while rest of the traffic go directly to the internet.

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080975e83.shtml

Hope this helps.

-Shrikant

P.S.: Please mark the question as answered if it has been resolved. Do rate helpful posts. Thanks.

[Shrikant Sundaresh]

Hi Chris,

In the following configuration: nat (intf1) X ____ , global (intf2) X ____;  the X refers to the pool id.

I think it says no matching pool found since we are patting it to the interface. I will have to check it out on an actual device before I can confirm this though.

I will let you know as soon as I do that.

Hope this helps.

-Shrikant

P.S.: Please mark the question as answered if it has been resolved. Do rate helpful posts. Thanks.

[marypoppins]

Thank you for your kind Shrikant! You helped me a lot!