site to site VPN CISCO PIX

Yes. It is possible to do this with Cisco PIX. Normally when you configure site to site vpns, you also have to configure access-list. For the one you dont want traffic to go through you can put a deny rule blocking the traffic that you dont want to traverse. Alternatively you can also not include the unwanted traffic in the allow access-list.

There is a easy cheatsheet for configuring cisco site to site vpns. The link is below:

Hope this helps

Thank you James

doggedpuppy's response is incorrect (or at least incomplete).

[I didn't reply there because doggedpuppy failed to quote any context and it's too much of a pain to go back and synthesize context where it hasn't been included.]

You can NOT do what you have requested -- at least not meaningfully. [Well, you could force it if it so happened that your only traffic was UDP from the 515 to the 501 and there were never any response packets.]

The crypto map "match address" ACLs on the two devices must be mirror images of each other in order for response packets (e.g., a TCP SYN ACK packet) to get through. If you managed to find a way to deny the traffic from the 501 to the 515 then you would not be able to complete any TCP connections or get through anything else that required a response.

What you *can* do is configure the devices so that the 501 is not allowed to initiate new connections towards the 515. You would do that by

*not* having "sysopt connection permit-ipsec" turned on in the 515 configuration, and then do NOT permit anything from the 501 LAN to the 515 LAN in the 515's access-list that is applied as an access-group "in" the outside interface of the 515.

Note that if you did configure this way, then some UDP would fail between the

501 and the 515, including some NETBIOS, and especially some communications between an Outlook client and an Exchange server. UDP has no inherent "end of conversation" packet, so if the 515 starts sending UDP to the 501, there is no way for the 515 to know when to stop expecting replies from the 501. The PIX resolves that through timers: by default, if no traffic has gone through the UDP connection for 2 minutes, it closes the UDP connection. However, if for some reason a response does not get sent for more than 2 minutes, then unless you have permitted inbound UDP on that port towards the 515, the packets will not get through. An example of a response not being generated for more than 2 minutes is a notification from an Exchange server to the Exchange client that a new message has just arrived. [There are a number of other situations in Exchange... some of which happen for no reason I've ever been able to discern.]

The initial question is as follows: "I want to permit the access only PIX 515 to PIX 501 and deny for PIX

501 to 515. It is possible ? " My understanding is that he/she wants traffic(user initiated traffic, and not return traffic like syn acks) to go from Pix515 to PIX 501 and not the other way around. This is possible.And Rob just explained what I had said by this:

"...and then do NOT permit anything from the 501 LAN to the 515 LAN in the 515's access-list that is applied as an access-group "in" the outside interface of the 515. "

My understanding is that it is also possible to restrict user initiated traffic from PIX 501 through access-lists. Not allowing a network behind PIX 501 to access resources from PIX 515 through the tunnel doesnt mean that it should drop all the reponse packets of tcp handshake process.

And as for problems with timeouts that can happen with any traffic not just vpn connection. And we have the timeout command to help in such cases.

Set the maximum idle time duration.

timeout [xlate hh[:mm[:ss]]] [conn hh[:mm[:ss]]] [half-closed hh[:mm[:ss]]] [udp hh[:mm[:ss]]] [rpc hh[:mm[:ss]]] [h225 hh[:mm[:ss]]] [h323 hh[:mm[:ss]]] [mgcp hh[:mm[:ss]]] [sip hh[:mm[:ss]]] [sip_media hh[:mm[:ss]]][uauth hh[:mm[:ss]] [absolute | inactivity]]

clear timeout

show timeout

These are my views and I believe it is correct from my past experience with pix firewalls. Wish we can have more participants to give their views also.

Thank you James

Not if you include non-TCP traffic. By definition, every ICMP and UDP packet is a new flow, not necessarily a reply to anything discernable. That's because ICMP and UDP are defined as "connectionless"; TCP is defined as "connection oriented", so replies -are- meaningful for it.

I believe it was I that said that, not some "Rob". [This mistake in attributions would not have happened if you had used normal Usenet quoting practices...]

Sure. You can block it on the 501 or you can block it on the 515, but it's more secure to block it on the 515 (or both!) just in case the 501 config fails somehow. It is not a good security practice to count on something remote to always act properly.

ICMP. UDP. GRE. ESP. All connectionless, so as far as the PIX is concerned, each one requires an ACL entry to allow it through. For UDP, and {weakly} for ICMP, the PIX Adaptive Security Algorithm automatically adds in temporary ACL entries, but those entries time out in 2 minutes by default. After that timeout, the next UDP packet from the outside is treated as a new flow.

As far as the PIX is concerned, there is no difference between a delayed response to a NETBIOS query, and a new request from the remote device to (say) enumerate the shares. Source and destination ports both UDP 137 for some of that NETBIOS traffic...

Yes, timeouts happen anyhow, but if you drop the restriction on the 501 not being allowed to initiate connections towards the 515, then you can open the appropriate port in the 515's outside access-group and so allow those packets through.

There is no reasonable timeout that will fix this problem for some of the Outlook Exchange 2000 interactions. When Exchange 2000 has new mail for a user, it looks to see what the last IP and port was that it talked to that user's mailbox on, and it will attempt to contact that IP + port. I traced some of those back 17 days: the Exchange 2000 server did not flush its cache in that time and *assumed* that the Outlook client was still there on the same IP and port more than 2 weeks later. [Yeah, right, what's the probability that an office Windows machine will not have been rebooted within 2 weeks?] In order to allow for this, one would have to set the UDP timeout to at least 17 days instead of the normal 2 minutes. If your site is at all active, your PIX memory is going to fill up on UDP connections -- since one of the other nice things about the Outlook client is that every few minutes it starts a -new- UDP connection to the server, using a -different- source port. [What was it I calculated for work? I think it was that by 34 hours our PIX 525 would be signficantly slowed due to lack of memory, and by 56 hours it would almost certainly have hung or crashed due to total resource exhaustion....]