cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
510
Views
5
Helpful
2
Replies

IPSEC VPN client - 2 ASAs accessing Windows file share

gizbri
Level 1
Level 1

Using the Cisco VPN IPSEC to ASA users can access Windows file shares when going through one firewall:

VPN Client  --> 5555 --> inside interface 

 

Problem - When going through to second ASA  users can not access file shares:

VPN Client  --> 5555 --> 5585 --> inside interface

When using the net use command they can connect , so I know the correct rules are in place

Not sure if we are still hitting some Netbios issue.... any thoughts ?

 

2 Replies 2

Hi,

 

It the VPN server is the 5555, and you can access the Inside interface with no issues, we have to take a look to several factors in placed:

 

 

- Are you using Split tunnel or tunnel all? 

 * Split tunnel= make sure the Subnets and networks are within the standard ACL to permit the access

 

- Make sure the IP local pool or the DHCP IP pool assigned to the clients is not overlapping with anything in the inside of your network

 

- Do you have NAT exemption configured on the 5555 ASA?

 

- When the packet is going further of the inside interface of the VPN server and gets to the 5585 ASA, is it permitting the packet on the access groups? Does the 5585 ASA has a route for the IP range of the VPN clients to come back to the inside interface of the Inside interface of the 5555 ASA?

 

- By doing traceroute you can see where the packet is being dropped

 

- Also set up a capture on the ASA 5555 to see if the packet is getting into the inside interface and see if the response is coming back:

 

  Capture CAP interface inside match ip host <AnyConnect user IP> host <Server on the 5585>

 

Then show capture CAP

 

To see the results.

 

Let em know how it works out!

 

Please don't forget to rate and mark as correct the helpful Post!

 

Regards,

 

David Castro,

 

David  - Thanks for the reply. We have an application running on the same server as the file share so we previously too care of NAT. Like I said in the post, it works when we use the IP instead of FQDN (even though it resolves), and we see the communication between the client and sever on 445 when doing packet captures. It seems to be something with NetBIOS, FQDN, or AD credentials being passed, or possibly something with server versions (2003 to 2012)