• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 620
  • Last Modified:

Cisco ASA 5505 Remote VPN IPsec - Same IP as the internal network

First, let me refer to my earlier topic:
-      http://www.experts-exchange.com/Software/System_Utilities/Remote_Access/VPN/Q_25754785.html

My new question is this:
Would it be possible to make the Remote VPN user have an IP address within the same network as the inside network?
If not, is it possible to make all remote VPN users to look like an host within the inside network?

Say that the Remote VPN IP is within 10.0.3.0/25
And the internal network is within 10.0.2.0/25
Would it then be possible in any way to make this remove VPN user to look like an IP within the internal network?

My situation is this: I have a remote user, that wish to access an internal host, this host ONLY accepts traffic from other hosts within the same network.

Thanks in advace!
0
trondbotnen
Asked:
trondbotnen
6 Solutions
 
Jan SpringerCommented:
Have you tried changing the netmask on this [specific] host to 255.255.254.0?  That would include the 10.0.2.0 and 10.0.3.0 networks.
0
 
trondbotnenAuthor Commented:
Hit me if I’m wrong, but I believe that this would not work?
My reason is this:
1.      I send a package from my remote computer, lets say 10.0.2.101, this package is meant for the IP address 10.0.2.202. This would be solved by the VPN client, and the routing that follows.
2.      The package would then travel to the Cisco ASA, where it would be routed to the specific client. Everything fine so far.
3.      Now, this computer (or PLS I’m my case) will try to deliver this package back. And it sees that the IP is within his own network area. This is because of the network mask.
My conclusion is then, the package would never leave the local area, sins the host would never try to send this package to the router.

Or am I totally wrong?
0
 
Jan SpringerCommented:
I'm not sure but if the gateway for that host is the ASA, the ASA should know what to do with it.   You might have to configure the ASA to proxy ARP that IP so that when the host issues an ARP who has, the ASA can answer up with its IP.

So, no.  You're not totally wrong.  But this may be the only way you can get the remote to talk with the local host.
0
The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

 
gavvingCommented:
The answer to the question is yes you can allocate the IP Pool for the VPN user out of the subnet that's on the inside interface.  The ASA will automatically proxy arp, and the traffic will work correctly.  You just need to ensure that your IP Pool doesn't overlap any other IP assignments on the inside network.

0
 
trondbotnenAuthor Commented:
A reply to both of you:

Isn’t it so, that a host will never send a package to the gateway(Cisco ASA) as long as the host is within the network specified on that host?

10.0.2.0/24 - would not send packages to gateway, as long as they are between 10.0.2.0 – 10.0.2.255.

Or is this wrong?
0
 
Jan SpringerCommented:
Whichever device answers the ARP 'who has' is the device to which the packet is sent.  So, if the ASA is proxy-arping for an IP, it will response to the 'who has' request with its own IP.

The gateway (default route) is used for layer 3 packet transfers when no other route is known for another subnet.

So, I expect that packets from host to host within a subnet will utilize ARP 'who has' and will not forward the packet to the gateway unless the gateway performs a proxy arp (which I why I disable proxy arp by default where possible).
0
 
trondbotnenAuthor Commented:
I dont seems to fully understand this Proxy-arp that you speak of, but I will read up on it, and come back WHEN i have anohter question :P

Still, feel free to post other known solutions that you think might solv my problem!

Thanks so far !
0
 
ptchubaCommented:
Just to clarify.

In a LAN, when a device wants to send to another device, the sending device needs to know the MAC address of the destination device, so it sends an ARP request which is like saying " I need the MAC address of the device with this IP address x.x.x.x." The device that has that IP address then responds and says "I have IP address x.x.x.x and this is my MAC address abcd.efgh.ijkl" The sending device can now use that MAC address to send data to the destination.

What happens with proxy ARP is that another device such as the ASA acts as a proxy between the source and destination. So when the source sends the ARP request asking for the MAC address of a destination, the ASA will respond with its own MAC address as if it were the destination. The source then sends data to the ASA and the ASA sends that data onto the destination. For this to work, proxy ARP must be enabled , and the ASA must have a way to get to the destination.

Hope that helps.

Peter C.
0
 
trondbotnenAuthor Commented:
Hum, i think that i now understand a litte more.

But now, it still seems to me like the PLS (network host) will still not respond to hostes outside its network?

Or am I still on a wild track here?
0
 
trondbotnenAuthor Commented:
I might add that Proxy ARP is already enabled for this Cisco ASA : /

Took a quick look as I was waiting for the night, and sleepiness to come along.

But now I think that I would have to add, that I can in fact access an Windows machine within the internal network, but the PLS is unreachable to me.
0
 
Jan SpringerCommented:
There might be an access list configured on that host that prevents outside networks from connecting.

The only other consideration is that it is missing a default route (0.0.0.0 gateway).
0
 
trondbotnenAuthor Commented:
Then I’m back to my other solution, that I would like if all remote hosts got an “fake” internal address. So that the insidehost(pls) would think that the package would be delivered to the an inside host.

But this isn’t possible?  Or would it by any chance be?
0
 
trondbotnenAuthor Commented:
Then it was time to hand out some points.
I found the solution to the problem, and it was probably almost exactly like Jepsen said in the beginning.

I configured as follows:

Inside networks: 10.0.2.0/24
IPsec VPN Pool: 10.0.2.80/28
With its NAT rules.

This worked perfectly!

The problem was that the PLC had no opportunity to configure a gateway.

Sorry I did not understand what you all thought, as it had saved us all a lot of bother.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Tackle projects and never again get stuck behind a technical roadblock.
Join Now