On a site to site VPN with a 515 on the hub (HQ) and a 501 on the spoke (remote site), I need to know if you can configure it were the users on the spoke can only reach a couple of addresses in the hub network and the hub can reach all the addresses spoke network.
Can you configure a stable VPN with DHCP enabled on the outside interface.
Thanks for your help...
Hi ... a couple of questions
1.- is the VPN between hub-spoke already up ?
2.- On the spoke do you have the sysopt connection permit-ipsec on its configuration ..?
3.- Do you have any access-list applied to the Inside interface on the spoke PIX.
4.- Can you post the config of the spoke ..? remove IP addresses ... usernames .. etc .. I am more than happy to give you a hand .. you could use an access-list on the spoke's inside interface to restrict outbound access to only a fe systems on the Hub side.. if you post the config .. then I can edit it for you.
I hope it helps ... please rate if it it does !!!
Thanks for responding.
This has not been deployed yet. We are just at the theory stage. They even want to limit it down to the protocol. e.g. Only allow rpc or smtp to a specific ip on the hub side but allow everything to the spoke. Is this possible?
Can you tell me if you have to have a static IP for a VPN.
oops ... in regards to your second question .. yes it is possible but at least one end of the VPN needs to have static IP address. The one with the static Ip address can be configured as VPN server and the one having the dynamic IP can be configured as VPN client. A VPN client can be a cisco router (only supported series) a PIX ( running supported versions)
I hope it helps .. please rate it if it does !!!
You can restrict the users of the spoke to access only come ip on the HQ side.
sysopt connection permit-ipsec this command renders all the access list on the outside interface useless if the traffic is coming through a ipsec tunnel.
If this command is not there then the acl on the outside interface will be checked againts the ipsec traffic.
The traffic will arrive at the outside interface, will get decrypted, if sysopt connection permit-ipsec is present then the traffic will not be subjected to acl inspection otherwise it will be.
From the PIX command ref
sysopt connection permit-ipsec:
Implicitly permit any packet that came from an IPSec tunnel and bypass the checking of an associated access-list, conduit, or access-group command statement for IPSec connections.
Your next question has already been answered.
Thanks to both of you.
In a test I performed on another set up I have, I modified the "crypto map match address ACL" (e.g. access-list blah permit tcp 10.10.10.10 255.255.255.255 host 220.127.116.11 eq 53)
and it worked great.
The only problem I had was pinging. It wouldn't work, even with a access-list blah permit icmp any any.
check with debug icmp and see if the echo responses are going with the outside interface's ip address as the source. They should go through the inside of the PIX rather the outside interface.
There is a log entry something along the lines of "no proxy ip". Does that make sense? Sorry for being so vague, I don't have it in front of me right now...
Here is the log entry at the hub:
May 27 2006 10:37:37: %ASA-3-713061: Group = REMOTE SITE IP, IP = REMOTE SITE IP, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/1/0 local proxy 0.0.0.0/0.0.0.0/1/0 on interface OUTSIDE
My suggestion is;
for you to filter the traffic from systems behind the spoke PIX. remove the sysopt connection permit-ipsec for this PIX and apply ACL to the inside interface allowing only the outbound access you want towards the Hub. Don'try to modify the crypto map as in your case it has different access requirements on the hub (full access to spoke systems ) and on the spoke (restricted to some hosts only on the Hub network). and the interesting traffic ( traffic that will be encrypted) needs to match exactly on both ends by using the same access-list on your crypto map
You also need to allow traffic from the Hub PIX to the outside interface of the Spoke PIX to get the tunnel established.
A bit confused ..? I hope not !!
>>remove the sysopt connection permit-ipsec for this >>PIX and apply ACL to the inside interface allowing >>only the outbound access you want towards the Hub.
PIX acls do not function like a router acl. The acl on the inside int will stop the inside hosts to create a connection however, if the connection is already established, like from outside, the inside acl will not do anything.
What are you talking about .. are you saying that a connection initiated from inside is the same as a connection initiated from outside ..? The issue requested was to limit OUTBOUND access from the spoke which can be controlled by an access-list applied to the Inside interface. Full INBOUND access from the hub will be allowed as per the access-list applied to the crypto map.
Please paste the crypto acl in the forums from both the sides.
The above error is simply saying that no entry for 'any any' found in the crypto acl.
"remote proxy 0.0.0.0/0.0.0.0/1/0 local proxy 0.0.0.0/0.0.0.0/1/0 " where
remote proxy 0.0.0.0/0.0.0.0/1/0 are the remote subnet/mask/proto/port since here the protocol is 1 which is ICMP the port is 0.
Please check the crypto entries again.
Well. I've begun the project. I guess when using EZVPN, you dont configure much on the remote side. It all gets pushed down to it from the hub. Now my need has changed from "What do I put in the remote acl?", to "What do I put in the split tunnel ACL on the hub?"
Just a note:
I don't think I like EZVPN, it seems a bit dirty. I don't like the lack of control over which policy it uses.