VPN Client issue here. User authenticates agains the firewall(gets IP from a pool) and can access everything fine and dandy on the directly connected lan. He goes to access a lan in another building that but cant.
the lan in the other building is connected by a 100mb lan extension so it has a router on the other side.
The router on that side has a route back to the ip pool that is used for the remote users. Weird thing is from router in the network he can not reach I can ping the ip he has been assigned from the pool.
when I look at the live logs via asdm i filter for his IP but can not see any traffic coming in from him to the network he is trying to reach.
when he does a traceroute to the network directly connected it gets there in one hop however when he does a traceroute the network that isnt working it tries to go out over various gateways on the internet.
i should point out Im relativly new to PIX but the fact that from the network the user cant access I can succesfully ping the remote user but not vice versa suggest that routing is OK??
Solved! Go to Solution.
thanks for the reply.
how can I check the spit tunneling acl
normal users on both networks have problems connecting to each other its just the remote client vpn users
Try putting a route on your PIX firewall for the network that is not directly connected to the router.
PIX connected LAN is 10.0.0.0/24 - Router network is 10.0.1.0/24. The router has a connected interface into the 10.0.0.0/24 and sends out of Eth1 for example and connected to eth1 is the 10.0.0.0/24 hence it works. The Client pool is 192.168.1.0/24. You also have a route on the router for 192.168.1.0/24 to go out of eth1. You need a route on the PIX anything for 10.0.1.0/24 go to Eth1 Ip address on the Router.
If this does not make sence let me know.
Thanks for the reply.
I have a route on the pix already, the weird thing is I can ping the remote vpn client's pool IP address from the lan not directly connected. Could it be something to do with IPSEC rules?
Thanks for the reply.
I have that option configured however I dont see a rule for on the inside interface which would basically say
allow 192.168.10.0 get to 10.50.20.0 IP permit
Although I can ping the vpn client from 10.50.20.0 network it doesnt make sense to me that if i was to add this rule all would be well.
what do you think
It sounds like your split tunnel is in need of some help.
If you posted your config it would help but I can probably guess what you have/need.
look for a section in your group-policy that specifies the split-tunnel-policy and split-tunnel-network-list value.
set your policy to tunnelspecified and your network-list value to the ACL that defines the split tunnel traffic.
your split tunnel ACL should look something like this:
access-list 101 standard permit 192.168.1.0 255.255.255.0
access-list 101 standard permit 172.16.1.0 255.255.255.0
Where 192.168.1.0/24 is your local LAN that you can access now, and 172.16.1.0/24 is the LAN in the other building.
I think you might have it there my friend.
here is the config from the CLI. there is not access list for the 10.50.20.0/24 network which the remove vpn client can not get to.
split-tunnel-network-list value 100
access-list 100 extended permit ip 22.214.171.124 255.255.255.0 192.168.10.0 255.255.255.0
access-list 100 extended permit ip 126.96.36.199 255.255.0.0 192.168.10.0 255.255.255.0
so tomorrow I will add
access-list 100 extended permit ip 10.50.20.0 255.255.255.0 192.168.10.0
which should do the trick yeah?