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

Cisco ASA & VPN routing problem

Having a problem when accessing the network over the VPN. Our VPN address pool is on 10.1.3.x. I have no problem accessing andything on the 10.x.x.x networks. Problem is devices that are on a 192.168.1.x network are unreachable from the VPN. From inside I can get to this network without any problem.  From the ASA I am able to ping devices on the 192.168.1.x network. I have a static route on the ASA to this network. I guess I am just confused on what I need to do here to get this to work, do I need to define the VLAN on the ASA for the 192.168.1.x network? When I look at the routing table on a PC I see no mention of the 192.168.x.x. network and therefore when I tracert to it tries to go out to the internet from the local machines internet connection. If you need more info just let me know.
0
FHSCompGuy
Asked:
FHSCompGuy
  • 3
  • 2
1 Solution
 
rsivanandanCommented:
NO You don't have to create VLAN stuff. Basically couple of things to check;

Do you have the 'nonat' access-list defined for both 10.x and 192.x network on ASA ?

Is the PC connected to a network which is on 192.x network scheme ? If so bad :-(

Simple and fast solution would be to disable split-tunneling so that all traffic would go through the VPN connection, but you may have some unhappy end-users because of the slowness in browsing.

How about posting the config here [ Sanitized config, remove off the passwords and mask off one of the octect from the public ip ]

Cheers,
Rajesh
0
 
lrmooreCommented:
You have to make sure that the 192.168.1.0 subnet is included in the nat_0 access-list as well as any split-tunnel acl that you may have.
0
 
FHSCompGuyAuthor Commented:
I believe these are the statements that pertain to this.

access-list ST-LIST extended permit ip 192.168.1.0 255.255.255.0 10.1.0.0 255.255.0.0
access-list ST-LIST extended permit ip 10.1.0.0 255.255.0.0 192.168.1.0 255.255.255.0
access-list ST-LIST extended permit ip 10.0.0.0 255.0.0.0 192.168.1.0 255.255.255.0

nat (inside) 0 access-list ST-LIST

route inside 192.168.1.0 255.255.255.0 10.1.254.254 1

split-tunnel-policy tunnelspecified
split-tunnel-network-list value ST-LIST

I just added LINE 1 in the ACL to see if that was what I was doing wrong but don't think so as it didn't do me any good. The inside route statement directs to the internal default route. Since ST-LIST is being use in both the NAT statement and the group-policy the 192.168.1.x network I think should be defined. Let me know if you see something wrong or if you need more info let me know.
0
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

 
lrmooreCommented:
OK, we need to separate the no-nat acl from the split-tunnel acl:

access-list NONAT extended permit ip 192.168.1.0 255.255.255.0 10.1.3.0 255.255.255.0
access-list NONAT extended permit ip 10.1.0.0 255.255.0.0 10.1.3.0 255.255.255.0
no nat (inside) 0 access-list ST-LIST
nat (inside) 0 access-list NONAT
access-list SPLIT standard permit 192.168.1.0 255.255.255.0
access-list SPLIT standard permit 10.1.0.0 255.255.0.0
no split-tunnel-network-list value ST-LIST
split-tunnel-network-list value SPLIT
0
 
FHSCompGuyAuthor Commented:
lrmoore,

Your solution worked great - Thank you. One last question if you wouldn't mind - did my method not work because the access-lists have to be separate or because I was trying to use extended access lists instead of standard?
0
 
lrmooreCommented:
combination of both. ASA requires standard acls for split-tunneling whereas the older PIX 6.x only had extended. It is also best practice to always use one acl per process. Two different processes using the same acl is not efficient.
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

Increase Security & Decrease Risk with NSPM Tools

Analyst firm, Enterprise Management Associates (EMA) reveals significant benefits to enterprises when using Network Security Policy Management (NSPM) solutions, while organizations without, experienced issues including non standard security policies and failed cloud migrations

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