cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1811
Views
0
Helpful
29
Replies

Bizzare VPN behaviour?

marcosgeorge
Level 1
Level 1

Hi Guys, I'm struggling to get my VPN up and running correctly. I'm not sure if its an issue with my setup or understanding. Any help will be VERY much appreciated.

I have the following setup

Outside:

ip:172.16.1.1 - assigned by my router

netmask: 255.255.255.0

gateway: 172.16.1.254

Inside:

192.168.1.1

255.255.255.0

Inside Hosts:

192.168.1.0 newtwork.

255.255.255.0

gateway: 192.168.1.1

DNS : 172.16.1.254

My inside hosts can access the internet.

Now when I VPN in. I get an ip address 192.168.1.X.

I can ping 192.168.1.1 , which should be my ASA inside interface.... but for some reason I get a reply from 172.16.1.1 :s.

Also I can see another computers file shares on //192.168.1.2 however I cannot ping the dns server (the asa outside inferface) and I therefore cannot surf the web etc..etc... I also cannot access the ADSM via https, telnet or ssh.

I have attached my running config.

I understand the I could probably set up a split-tunnel to access the internet but I don't want to do that. plus that won't solve my ADSM issues.

Many many thanks

Marc.

29 Replies 29

husycisco
Level 7
Level 7

Hi Marcos

Using a VPN pool subnet which is covered by an interface IP subnet of one of your interfaces is always a handicap.

Your VPN connections are terminated at outside interface of ASA. Although they get an IP address of 192.168.1.x, they are not considered as inside. That clarfies the ping response issue also. Thats why following command will not cover your VPN clients

http 192.168.1.0 255.255.255.0 inside

I suggest you using a different IP pool for VPN clients and amend your exempt nat statements accordingly. Then issue the following command

http vpnippool vpnpoolmask outside

Regards

Thank you very much for your reply.

You response makes sense to me.

I am still new to the ASA appliance and think in a way I have made a mistake in relying so heaviy on the ASDM for configuration and management.

I think i will fccus on the cli from now on.

Just a quick question in regards to your repsonse. I thought one of the main ideas of a VPN is to allow remote access and let you become part of a protected inside network? Doesn't the idea of creating a vpn pool in a differnet network mean I'll now have to setup ACL's so my VPN network can get to my inside network?

thank you.

"I thought one of the main ideas of a VPN is to allow remote access and let you become part of a protected inside network"

No it isnt. Idea here is, a private network which can communicate with a protected network. The protected network, your inside network ends where internet connection or internetworking begins. Rest of your inside network you provide physical security, connectivity, managability, authorization locally, is totally unsecure. Especially the internet.

And VPN is generally established over Intenet. You can not ensure the security of remote clients (Improved VPN technologies that currently exist which appliy policies/topologies on Client PC via Client software. These technologies strenghten the security but does not change the generel term described above). Also you can make sure that no one can break the door of cabinet, plug a cable to your switch and hack your system, but you can not make sure that a hacker attempts to hack your VPN encryption hash and break into your system over internetworks.

Cisco's all security appliences' core algorithm, the Adaptive Security Algorithm, relys on the facts above. The key component for Adaptive Security Algorithm to work, is the security level. ASA protects the network(s) connected to the interface with higher security level, from the network(s) connected to the interface with lower security level. In general, outside interface is always set to 0 (most unsecure), inside 100 (most secure), DMZ 50 (unsecure for inside but secure for outside).

Regards

*Please do not forget to rate the post and choose "resolved my problem" which was helpful and resolved your problem.

ok that makes sense, but it doesn't answer my question, what I am trying to achieve is the following;

I want to be able to access the files within my inside network shares aswell as the internet via

the VPN(not directly using split tunneling).

Now in my current setup I can access shares from my inside network but cannot access the ASDM or internet access. Thats what I'm trying to achieve and perhaps thats what the propose solution you gave me in your fist post will achieve? However you have suggested that I put my VPN clients on a seperate network. So what I was asking is will I know have to setup accesslists for my VPN client to know acess the inside network shares?

Thanks again. :)

PS - yes ofcouse I will rate the post and chose 'resolved my problem'

Yes, the answer in my first post will make you achieve exactly what you want.

As long as you specify this network in your exempt nat rule, you wont need to setup access-lists for reaching shares etc.

"aswell as the internet via

the VPN"

That means you want your VPN clients to connect internet using ASA's internet bandwidth instead their local internet. Then simply add the following

group-policy vpngroup attributes

split-tunnel-policy tunnelall

Keep in mind that this will make VPN clients lose their local LAN connectivity

Thank you very much for your patience with me.

Its all makes sense however I'm curious about the following. You said in your first post the because the VPN is terminated on the outside interface that even though my VPN client has a 192.168.1.X address, it isn't REALLY on the the inside. This raises 2 questions in my mind.

1) If this is the case, how come I can access file shares on 192.168.1.3(as an example)?

2) If put my VPN clients in a different network say 10.1.1.X for instance. Won't it still be the case that the are not really on the inside and the same issues will occur? What is the difference?

Apologies if these are silly questions, I'm just trying to learn how this all works.

I am actually on holidays at the moment but will be accessing the ASA tonight.

Thanks again. I look forard to your reply.

Marcos.

A1) Here comes networking. Being on a different interface does not mean you can not communicate to hosts in other interface. This is what interface for, serving between different networks, internetworking. In your case, VPN client is located at outside, and 192.168.1.3 is in inside. ASA knows that. And when you try communicating between interfaces connected to ASA, it takes the packet from x interface's buffer to RAM, checks its destination, if the destination exist in route table, it switches the packet from x interface's buffer to y interface's buffer. This is more like a router behaviour, in ASA, this is more secured with ACLs and security levels.

Above is the explaination in theory, for a little background. What is the answer in yor config? Answer is the following lines

access-list inside_nat0_outbound extended permit ip any 192.168.1.192 255.255.255.224

nat (inside) 0 access-list inside_nat0_outbound

Above lines are about exempt NAT, and NAT (Network Address Translation) is a routing protocol. If VPN pool was really in inside, why did you need to configure this routing protocol explicitly? A packet which is destined to an IP in same subnet does not use a gateway so why is it there? Do you have any entry like above for your inside hosts? No. If you remove one of the lines above, you will no more be able to access file shares in inside from VPN network.

I couldnt understand the question number 2, would you please explain, which same issue?

I read your original question and there are some little mistakes also.

"I cannot ping the dns server (the asa outside inferface)"

ASA does not have the DNS server functionality. You should point to a global DNS server or an internal DNS server in which root hints or forwarders configured.

To be able to ping correctly from outside to interface IP, you should issue the following command

management-access- inside

Thanks again.

In response to your answer (A1). I understand that concept of routing between directly connected interfaces( and various routing proctols, distance-vector or link-state).

I also think I understand the reason the Nat exemption rules are there, to allow inbound and outbound connections to initiate between my inside hosts and the VPN termination point without doing a nat translation?

Unfortunatley I wasn't very clear in my question, and what I was trying to discover is why was I able to access a file share but NOT my internet via the tunnel. I understand the reasoning why I can't access the ASDM.

To clarfiy my second question, your reccomendation was that I

"I suggest you using a different IP pool for VPN clients and amend your exempt nat statements accordingly. Then issue the following command

http vpnippool vpnpoolmask outside "

I understand why the 'http vpnippool vpnpoolmask outside' is neccesary, as you pointed out the VPN connection isn't really on the inside. But why do I need to change the IP range? Why can't for example, my inside host in a range of 192.168.1.2 - 192.168.1.20 and my vpn clients be in 192.168.21 - 192.168.1.40 ? Or were you not sugesting that? I didn't understand why you thought it should be in "a different ip pool".

You see I still don't understand why I am unable to access the internet through my VPN tunnel ( I can configure split tunnelling but that not what i want for security reasons).

my default gateway on my VPN client is 192.168.1.1 and the DNS server is configured to 172.16.1.254.

Even though I can't access the ASDM http interface at the moment shouldn't I be able to route traffic still? just like my inside clients?

"ASA does not have the DNS server functionality. You should point to a global DNS server or an internal DNS server in which root hints or forwarders configured.

To be able to ping correctly from outside to interface IP, you should issue the following command "

Yes thats right, I was wrong when I stated my DNS server was the ASA's outside interface. its actually my routers inside (172.16.1.254) My current inside hosts are configured with this as there DNS and they can resolve DNS requests fine.

Many thanks.

First of all, I want to clarify one thing. My suggestion of using different subnets is not a must so your config can work. But definitely is the best practise.

"Why can't for example, my inside host in a range of 192.168.1.2 - 192.168.1.20 and my vpn clients be in 192.168.21 - 192.168.1.40 "

I didnnt say you cant, and above is a great idea for ideally using the host portion and not wasting IP address BUT! your inside interface has the subnet of 255.255.255.0, which means it is not really in between the range you specify. And this will cause serious problems in a mid-sized network architecture for routing and acl filtering. If you want to keep inside and VPN client in the ranges you mention, you can use 255.255.255.240 subnetmask and there will be usable 14 hosts IPs in each subnet.

"You see I still don't understand why I am unable to access the internet through my VPN tunnel ( I can configure split tunnelling but that not what i want for security reasons).

my default gateway on my VPN client is 192.168.1.1 and the DNS server is configured to 172.16.1.254.

Even though I can't access the ASDM http interface at the moment shouldn't I be able to route traffic still? just like my inside clients?

"

For achieving this, you should do the following modification to force all traffic pass through the tunnel

group-policy yourpolicyname attributes

split-tunnel-policy tunnelall

After doing this, when a client connects and you right-click VPN icon at right-bottom >click statistics> click route details. In right-pane you will see the destined traffic which will flow through the tunnel. You will see 0.0.0.0 which means all traffic including internet traffic will flow through the tunnel.

Another dilemma about the IP pool 192.168.1.x, which you use in both inside and VPN clients is, most internet modems/routers come out of the box with a default IP configuration of 192.168.1.1. This will again cause problems.

Hi Husycisco,

Thanks for the clarification.

I have made the suggested changes.

My inside hosts are on 192.168.1.16/28

My VPN clients are on 192.168.1.32/28.

I also have ensured that the tunnel is tunneling all traffic. If I check the client, the destined traffic is 0.0.0.0 like you suggested it would be.

My INSIDE ip is 192.168.1.17

and my vpn client is assigned something between 33 and 46 (in the last octet).

The gateway for the VPN client seems to be set to the next available from the VPN pool( is this correct behaviour?).

My modem router is configured on 172.16.1.0/24. But you are correct out of the box it was 192.168.1.1.

I am connecting with IPsec/TCP on port 10000.

once again. I can see my file shares, but CANNOT access the internet or resolve any addresses via the tunnel.

I have attached the current running-config AND the debugging syslogs from my ASDM.

This is starting to get rather frustrating.

I am unable to resolve DNS through the tunnel. I have tried configuring my dns with both the routers ip ( which is how my inside clients are setup) and with a my public dns, they both fail.

When I turn on debug level logging, I am noticing the following line appear when I try to ping anywhere. for example "ping www.google.com".

They appear to be NetBios (port 137) broadcasts to my VPN subnet?

I get 3 of them, then my ping command fails. with

"Ping request could not find host www.google.com....."

6|Feb 14 2008|15:36:29|302016|192.168.1.33|192.168.1.47|Teardown UDP connection 1004 for outside:192.168.1.33/137 to outside:192.168.1.47/137 duration 0:00:00 bytes 0 (vpnusername)

6|Feb 14 2008|15:36:28|302016|192.168.1.33|192.168.1.47|Teardown UDP connection 1003 for outside:192.168.1.33/137 to outside:192.168.1.47/137 duration 0:00:00 bytes 0 (vpnusername)

6|Feb 14 2008|15:36:27|302016|192.168.1.33|192.168.1.47|Teardown UDP connection 1002 for outside:192.168.1.33/137 to outside:192.168.1.47/137 duration 0:00:00 bytes 0 (vpnusername)

:( MAny thanks once again.

Just to add to my last post....

Before I made the suggested changes I checked the ASA's logs and saw similar output to that previously posts except it was Tearing down udp broadcast traffic on port 53(dns) from the outside:myvpnclient TO outside:myvpnsubnet.

It seems to me the problem all along could have something to do with hair-pinning? The following seems to explain a possilbe problem:

http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/vpnsysop.html#wp1042114

Try issuing the following only,

same-security-traffic permit intra-interface

if doesnt solve, I will ask for a couple of command outputs

Thanks, I did try that, its didn't work, but I got called out to an emergency at the last minute.

According to the article I might also have to set up Nat on the outside interface.

"For the security appliance to send unencrypted traffic back out through the interface, you must enable NAT for the interface so that publicly routable addresses replace your private IP addresses (unless you already use public IP addresses in your local IP address pool)."

In regards to my last post... does it matter what the gateway address is that is assigned to my VPN client? I posted the complete details in my previous post.

Let me know hwat command output you would like.

Thanks.

Thanks, I did try that, its didn't work, but I got called out to an emergency at the last minute.

According to the article I might also have to set up Nat on the outside interface.

"For the security appliance to send unencrypted traffic back out through the interface, you must enable NAT for the interface so that publicly routable addresses replace your private IP addresses (unless you already use public IP addresses in your local IP address pool)."

In regards to my last post... does it matter what the gateway address is that is assigned to my VPN client? I posted the complete details in my previous post.

Let me know hwat command output you would like.

Thanks.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: