In article , snipped-for-privacy@yahoo.com wrote: :I'd like to bring up the tunnel in just one direction. between :68.68.68.68 and 11.11.12.0/24 network so that internal hosts hidden :behind 68.68.68.68 machine have encrypted access to 11.11.12.0/24 :network but 11.11.12.0/24 network doesn't use the tunnel and is treated :as any other external network out on the internet.
Although it wouldn't be immediately apparent to someone who didn't know PIX and IPSec well, your posting asks about 3 completely different things, some of which cannot be done but which you -probably- don't actually want to do.
Rather than pick apart your posting, I will ask you to rephrase what you want done:
- Is 68.68.68.68 the outside interface IP of your PIX, or is it an additional routable IP? (interface IPs have special properties)
- Related to the above: your posting was written in such a way that
68.68.68.68 could be a host with other hosts behind it, such as if 68.68.68.68 were a Windows box doing Internet Connection Sharing. This scenario would be inconsistant with the way you used 'global', but that might have been a misconfiguration, so better that I ask about this ?
- When the hosts fronted by 68.68.68.68 initiate connections into
11.11.12.0/24, you want the outgoing packets to be encrypted and encapsulated (tunneled), right?
- When the hosts within 11.11.12.0/24 send reply packets, should those replies be encrypted and encapsulated?
- Are there connections that the hosts within 11.11.12.0/24 should be able to initiate to the -host- 68.68.68.68 (connection sharing scenario), or should the hosts within 11.11.12.0/24 be able to ping the PIX interface IP 68.68.68.68 (PIX interface IP scenario), or should the hosts within 11.11.12.0/24 be able to initiate connections directly to the hosts hidden behind 68.68.68.68 (a tunnel scenario), or should the hosts within 11.11.12.0/24 be able to initiate connections indirectly to hosts hidden behind 68.68.68.68 by using 68.68.68.68 as the destination IP and having the PIX do port forwarding to the appropriate internal host (interface IP or public IP scenarios) ?
- When any of the above 11.11.12.0/24 initiated traffic happen, you don't want the inward traffic to be encrypted, right? How about if it were encapsulated without being encrypted?
- How about replies to 11.11.12.0/24 initiated traffic -- should the replies be encrypted? Encapsulated?
- When the hosts fronted by 68.68.68.68 initiate connections into
11.11.12.0/24, what IP address should the 11.11.12.0/24 hosts see them as -- the internal IPs or the 68.68.68.68 IP ?
It isn't apparent to me why you would want to do what you are asking. My -suspicion- is that your situation is perhaps a lot different than what you asked about, that you perhaps wrote in terms of what you had been thinking of as a solution to an unstated situation.
My suspicion is that your question is closer to "How can I give an internal network behind a PIX privileged access to a remote VPN'd network, without giving the remote VPN'd network privileged access back?" (e.g., if your technical support team is behind the PIX, you want the technical support to be able to have extensive access to the remote devices, but you don't want the remote devices to have special access to the technical support machines.) Asymmetric privileges is relatively easy with pure TCP, but becomes more difficult with UDP.