Help setting up a VPN so satellite offices can access an internal host 1

[skhoury]

Hello all,

Ok, I am a newbie to the world of Cisco products, and in particular the PIX 515E. I have successfully configured the firewall so that it functions just fine. I've built my access-lists etc..

Now the next step that I would like to take is to expose our local Intranet server to our satellite offices, however I don't want to just expose it to the world like a regular web server. I'd for the satellite offices to have access to it via a VPN.

Does anyone have any pointers on setting up the VPN functionality on the PIX515E? In particular I imagine that the users will use the Cisco VPN software to get connected, not some sort of a tunnel. I used the wizard that comes with the http gui by default and seems to have built the tunnel (i.e. I can connect), however I cannot access any internal hosts (like our intranet server).

Does anyone know what I may have done wrong?

Many thanks!

Sam

 

[themut]

You need to make sure NAT-T is enabled on the headend device, a simple test is to establish a VPN connection and then go to VPN Client Status and then click on statistics, under Transport make sure Transparent Tunneling is active on UDP port 4500. If not then you need to configure the following command on the PIX:

isakmp nat-traversal

Unfortuantely, this command is only available on version 6.3.X so you will need to upgrade if you have an earlier version. The following link will help you configure PIX to Client tunnels in case you want a guideline:

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008009442e.shtml

 

[skhoury]

Thanks for the tips! Im going to give it a go and see what comes out of it!

I'll post my results

Sam

 

[skhoury]

themut - Ok, I've setup the vpn connection per the instructions you provided in the link. I also included the command you specified (isakmp nat-traversal) however I still can not gain access to inside hosts. Further more, even with that command active, the status still indicates that transparent tunnelling is inactive.

Any thoughts as to why?

Thanks,sam

 

[themut]

On the VPN client, highlight the connection entry and click on modify. Then on the Transport Tab make sure the box Enable Transparent Tunneling is checked and IPSec over UDP (NAT/PAT) is selected. Save the changes and try to establish the VPN session, is transparent tunneling still inactive?

 

[skhoury]

Yup - the transparent tunneling is still inactive. Im not sure what I did wrong. Maybe something with the base configuration?

 

[themut]

Are you able to connect to the VPN? Are you assigned an IP address from the pool configured? If so, I'd look at simultaneous logs on the VPN client and debugs at the PIX. To try to determine the reason why it is not negotiating NAT-T. On the PIX you need console access and the following debugs:

debug crypto ipsec
debug crypto isakmp

Be careful because debugs are CPU intensive so you might experience some issues.

On the VPN client you need to enable the log at the highest level (level 3) on the client in order to see more details. Click on Log | Log Settings and set all options to High. Then click on Log again and click on enable, if disable is displayed it means it is already enabled

 

[skhoury]

Yup, im able to connect no problem, and im getting an ip out of the pool. The debug messages dont seem to be generating anything with respect to nat, nat-t, or the particular internal ip im trying to access. On the other hand the logs from the client are generating the following messages that contain references to nat:

This client and the remote client are not behind a NAT device.

Could this have anything to do with the acl?

For example in the cisco doc it has an example acl:
access-list 101 permit ip 10.1.1.0 255.255.255.0 10.1.2.0 255.255.255.0

and it binds this acl to: nat (inside) 0 access-list 101.

Would I simply adjust this acl to match my internal environment: access-list vpnacl permit ip 192.168.100.0 255.255.255.0 192.168.100.0 255.255.255.0

or maybe I shouldnt have created a new acl and just assigned my current acl to the split-tunnel entry in the vpngroup?

?? Sorry...im am new to this, but im trying.

 

[themut]

If the client is not behind a NAT device then it will never negotiate NAT-T, so that makes sense. I'm suspecting you have a static translation to itself for the VPN client on the PIX.

The ACL 101 on the link is used for two different reasons:

1) To tell the PIX which traffic shouldn't be natted; nat (inside) 0 access-list 101
2) To tell the PIX which traffic should be encrypted; vpngroup <name> split-tunnel 101

Have you configured a pool which belongs to any used subnets on your network? If so then you need to remove the pool and configure a new pool using an unused subnet.

Make sure a route on your network doesn't conflict with the pool configured. For example, if a route statement says, that network 10.0.0.0 can be reached through an router off the inside interface and you have configured the local pool (unused subnet) as 10.10.10.0. Then you will not be able to receive the return traffic, since the PIX will try to direct the replies back off the inside interface. And since it cannot route packets back on the same interface they arrived, it drops the replies.