FHSCompGuy
asked on
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.
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.
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
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?
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.
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