Hi,

thx for your help, it was the missing associated psk.

Why do i need tunnel-groups for site2site?

Where can i define specific policies for traffic in the tunnel, for example:

LAN A is allowed to do everything to LAN B, LAN B is allowed to reply (stateful), LAN B is only allowed to talk to webserver of peer A.

Peter,

Nice to hear that your problem is resolved.

"Why do i need tunnel-groups for site2site"

A connection established for a traffic flow from, which is negotiated by both sides of connection in a secure fashion is called "tunnel". In either Remote Access VPN or Site To Site VPN, you are establishing a tunnel. Thats why you should create a tunnel-group to specify tunnel specific parameters like type, group policy, filter ACLs, pre-shared-key or etc.

For controlling the traffic in tunnel, the best practise is applying filter ACL.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml

Please do not forget to rate the posts that are helpful and resolved your issue!

Regards

Hi,

thank u very much, one thing i still dont understand is, 1.why do i have to associate a psk again? i did this already in ike settings crypto table. Why iam able to define IKE settings in tunnel-group, i did this also in IKE crypto settings?

2. Ok this makes sense, setting up ACLs in group-policy and bind group-policy to tunnel-group? So i dont need ACLs for inside interface? They are bind to policy-group and then to tunnel-group ist this correct?

"why do i have to associate a psk again?"

You are not associating the psk again. You didnt have a psk in ASA 5510. In 7.2 IOS, you can not assign psk in crypto table like in 6.3 IOS, you assign the psk with the commands I suggested to you (tunnel-group).

In 6.3 IOS in your PIX 501, there is no command called tunnel-group and you assign the psk with "isakmp key ********"

"Ok this makes sense, setting up ACLs in group-policy and bind group-policy to tunnel-group?"

Exactly!

"So i dont need ACLs for inside interface?"

If you want to control the traffic originated from your inside hosts, you need inside ACL, but you dont have to enter ACEs for VPN traffic in inside ACL, if you implement the filter.

Thank u for response again, first thing makes sense to me now, i didnt noticed i entered a psk, so this was my fault, its everything so new here switching from iptables ;)

2nd hmmm iam not sure i understood this.

i created a access-list like this:

access-list INSIDE_IN permit icmp 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list INSIDE_IN permit 10.0.1.0 255.255.255.0 permit tcp 10.0.2.1 255.255.255.255 eq 3349

access-list INSIDE_IN deny any any

access-group INSIDE_IN in interface inside

access-list TESTLAB_AtoTESTLAB_B permit icmp 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0

access-list TESTLAB_AtoTESTLAB_B permit icmp 10.0.2.0 255.255.255.0 10.0.1.0 255.255.255.0

access-list TESTLAB_AtoTESTLAB_B permit tcp 10.0.2.0 255.255.255.0 10.0.1.1 255.255.255.255 eq 3349

access-list TESTLAB_AtoTESTLAB_B deny any any

group_policy TESTLAB_CRYPTO_GRP_POL internal

group_policy TESTLAB_CRYPTO GRP_POL vpn-filter TESTLAB_AtoTESTLAB_B

tunnel-group XXXXXXXXXX default-group-policy TESTLAB_CRYPTO_GRP_POL

no data flows, Syslog says: DEny ICMP src outside 10.0.2.4 by access-group OUTSIDE_IN

does this mean i have to:

ACL everything from inside to inside Interface

ACL everything from outside to outside Interface

and then when this is done, permit or deny everything in the group-policy?

btw. what is a ACE?

Keep in mind that traffic flow from a higher secuirty level interface to a lower security level interface is permitted by default. You dont need a specific permit ACL for insid einterface just like in yours. So completely remove the ACL that it has no effect.

For allowing PING, issue the following commands

policy-map global_policy

class inspection_default

inspect icmp

Now the following question may appear in your mind. "When do I apply an ACL to inside interface?" Since the default action is permit, you should apply ACL to inside interface when you want to deny the specific traffic that is inside originated. For example

access-list INSIDE_IN deny tcp host 10.0.1.10 host 10.0.2.5 eq 3389

access-list INSIDE_IN deny tcp 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0 eq smtp

access-list INSIDE_IN permit ip any any

Above ACL denies two conditions and permits the rest. Since the implict rule is always "deny any any" we should apply that permit any any. Above ACL is just an example, dont apply it.

INSIDE_IN is an ACL (Access-List). And it has ACEs in it (Access-list entries). Every single line in an ACL is called ACE.

hi,

thx for reply, i didnt defined my answer correctly, i added the inside rul only to show, there will be rules, for example forbidding some internet traffic. the main reason was understanding dataflow in situation where:

i permit traffic without sysopt and deny some tunnel traffic at outside acl and using sysopt and deny tunneltraffic via group-policy.

Because i think i will never have a environment without a rule on the inside interface and with some tunnel on which not all traffic is allowed.

The strange thing on using sysopt the ACL in the tunnel-group mapped via policy group seems to work first after a timeout of abot 15 minutes or so.

thx anyway