Routing Problem

[dianewalker]

I just setup a new group policy on the ASA  for the users to Remote Control to the server 208.57.131.152 by logging in to Cisco VPN client.  The users are unable to Remote Control to the server 208.57.131.152 when they logging in to Cisco VPN client.  I can Remote Control to this server when I am in the office.  So, it is not the server issue.  I can Remote Control to the servers that are on different subnets when I login to Cisco VPN client.  Is there a way to check to see what stopping me from Remote Control to this server when I login to Cisco VPN client?  I suspect that it is a routing issue.  By the way, the IP addresses are not real.  They are used as an example.

Please let me know if you need additional information.

route Inside 208.57.131.0 255.255.255.0 208.57.131.1 1

access-list purchasing standard permit host 208.57.131.152

group-policy purchasing internal
group-policy purchasing attributes
wins-server value 208.57.131.250 208.57.131.251
dns-server value 208.57.131.5 208.57.131.10
vpn-tunnel-protocol IPSec
split-tunnel-policy tunnelspecified
split-tunnel-network-list value purchasing
default-domain value consoto.com

Thanks.

Diane

[Jennifer Halim]

What about NAT exemption?

Have you got nonat for the following:

access-list permit ip 208.57.131.0 255.255.255.0

Are you able to ping or access the host by IP address?

I can see that your WINS and DNS servers are also in the same subnet, however, if your split tunnel ACL: "purchasing" is only allowing access to 208.57.131.152 then neither WINS nor DNS servers will work as you haven't allowed them access.

[dianewalker]

Thanks for your prompt response and suggestions, Jennifer.  I added the NONAT statement and it did not make any difference.  I am not able to ping the server by IP address.  I got Request Time Out error.  Do you have any other suggestions?  Perhaps, I need to post my config.  I will post my config tomorrow.

Thanks.

Diane

[Jennifer Halim]

Assuming that you have just added a new nonat ACL, and you have "clear xlate", yes, please post the config to view the complete picture. Thanks.

[dianewalker]

Thanks for your prompt response and suggestions, Jennifer.  I tried the "clear xlate" command and it did not make any difference. By the way, the server is in DMZ.  I do not know if it makes any difference.  I will post the config tomorrow.

Thanks.

Diane

[Jennifer Halim]

Assuming that you have applied the NONAT access list to your DMZ interface?

nat (dmz) 0 access-list

[Jennifer Halim]

Oh, btw, how is the server in the DMZ if you have routing pointing towards the inside?

route Inside 208.57.131.0 255.255.255.0 208.57.131.1 1

[dianewalker]

Thanks for your prompt response and information.  I am sorry that I gave you the wrong info.  It should be

route Inside 208.57.131.0 255.255.255.0 208.57.132.1 1

The IP address 208.57.132.1 is the outside interface of the firewall.

Thanks.

Diane

[Jennifer Halim]

Then this command is completely incorrect and should be removed:

route Inside 208.57.131.0 255.255.255.0 208.57.132.1 1

If 208.57.132.1 is your outside interface IP address, I am not sure how the server is in DMZ now? and why did you route it to the inside?

What is the actual ip address of the server? public ip or private ip? and what is your ASA dmz interface ip address?

[dianewalker]

Thanks for your prompt response.  The server has a public IP address. My ASA outside interface has the IP address of  208.57.132.10 which is the same subnet as my other firewall.  I am sorry that I confused you.  I will post the config tomorrow.

Thanks.

Diane