Now I've a new scenario: it's similar to the old one:
but now on the inside network 10.0.0.x there's a router 10.0.0.139 and it can access to the 172 net. Now I always need to reach that net from the outside with cisco vpn client. As jackko said:
since the pix is protecting 10.0.0.x not 172.17.x.x, it's not feasible for the pix to provide vpn access to a network that is outside the pix. one workaround is to setup a terminal server at 10.0.0.x. when roadwarrior connects to 10.0.0.x via vpn, he/she can establish a terminal session to the server (ip: 10.0.0.x), then from the server he/she will be able to access 172.17.x.x.
Now my question is:
when I connect to the protected network 10.0.0.x from a cisco vpn client 10.0.9.x he doesn't have any gateway. I thought: if I give to the 10.0.9.x the gateway 10.0.0.139 (that is the router) maybe I can reach the 172 net. I've tried with cisco client under windows but when I put a gateway address in the new lan interface (the cisco vpn client one) my pc doesn't go to internet anymore and however it can't reach 172 net.
i was thinking it may work providing you added the 172 net as part of the no-nat and crypto acls, and a static route on pix pointing to the 10.0.0.139 router for 172 net.
however, a second thought suggests that it may not be feasible as the pix will not forward the packets (from vpn client to 172 net) to the 10.0.0.139 router. the reason being the pix outside interface is directly connected to 172 net, thus the static route will not be considered.
vpn client sends a packet with destionation 172 net. the pix receives the packet since 172 net has been included as part of the no-nat and crypto acls for remote vpn access. pix will then decrypts the packet and try to determine the next hop. since pix outside interface is part of 172 net, pix will not send the packet to the 10.0.0.139 router. so again, base of the rule that pix will not re-route the traffic back to the same interface, this solution will probably fail.
one workaround i can think of is to configure remote vpn access on the router. since the router doesn't have the restriction like pix (i.e. packet from an interface will not be routed back to the same interface), it should work. one catch is that the pix will then need to perform 1-to-1 nat for the router, so that remote vpn client can reach the router from outside world in order to establish vpn tunnel.
"Is it possibile to tell the router: well, everything from 10.0.9.x put into the 172? Ummm...maybe not because the router is connected to pix as well... I don't know." i guess it's not possible, please read the example from my previous post.
i would say configuring remote vpn access on the router is probably the way as long as the router supports ipsec, the config is very straight forward too. as mentioned, with this scenario, a 1-to-1 nat needs to be configured on the pix for the router, so that the remote vpn client can establish the vpn.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :