Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Desperate for answers

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.

Also,

Can you configure a stable VPN with DHCP enabled on the outside interface.

Thanks for your help...

16 REPLIES

Re: Desperate for answers

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 !!!

New Member

Re: Desperate for answers

Hello!

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?

Also,

Can you tell me if you have to have a static IP for a VPN.

Thanks

Re: Desperate for answers

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)

http://cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080455b7d.html#wp1067163

I hope it helps .. please rate it if it does !!!

Cisco Employee

Re: Desperate for answers

Hello,

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.

-Vikas

New Member

Re: Desperate for answers

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 20.20.20.1 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.

Any suggestiones???

Thanks all

Cisco Employee

Re: Desperate for answers

Do you have DSL terminating on the PIX outside?

Are you running 6.3 code?

Vikas

New Member

Re: Desperate for answers

Not on the lab I have setup I have but the proposed network will. Does that make a difference?

New Member

Re: Desperate for answers

and yes I am running 6.3

Cisco Employee

Re: Desperate for answers

Hello,

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.

Vikas

New Member

Re: Desperate for answers

Hello,

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...

Thanks!

New Member

Re: Desperate for answers

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

Re: Desperate for answers

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 match instruction.

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 !!

Cisco Employee

Re: Desperate for answers

>>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.

-Vikas

Re: Desperate for answers

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.

Cisco Employee

Re: Desperate for answers

Hello,

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.

Vikas

New Member

Re: Desperate for answers

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.

333
Views
5
Helpful
16
Replies