03-31-2008 06:39 AM - edited 03-11-2019 05:24 AM
hi ive got a problem with asa 5510 7.2 site2site to pix501 6.3:
config asa:
sysopt connection permit-ipsec
crypto ipsec transform-set FW1set esp-3des esp-md5-hmac
crypto map FW1 10 match address CRYPTO
crypto map FW1 10 set peer 11.11.11.11
crypto map FW1 10 set transform-set FW1set
crypto map FW1 interface outside
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
tunnel-group 11.11.11.11 type ipsec-l2l
config PIX:
sysopt connection permit-ipsec
crypto ipsec transform-set FW2set esp-3des esp-md5-hmac
crypto ipsec security-association lifetime seconds 600
crypto map FW2 10 ipsec-isakmp
crypto map FW2 10 match address IPSEC
crypto map FW2 10 set peer 22.22.22.22
crypto map FW2 10 set transform-set FW2set
crypto map FW2 interface outside
isakmp enable outside
isakmp key ******** address 22.22.22.22 netmask 255.255.255.255
isakmp identity address
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption 3des
isakmp policy 1 hash md5
isakmp policy 1 group 2
isakmp policy 1 lifetime 86400
error on asa:
PATAPON(config-isakmp-policy)# Mar 31 03:11:19 [IKEv1]: Group = 11.11.11.11, IP = 11.11.11.11, Can't find a valid tunnel group, aborting...!
Mar 31 03:11:19 [IKEv1]: Group = 11.11.11.11, IP = 11.11.11.11, Removing peer from peer table failed, no match!
Mar 31 03:11:19 [IKEv1]: Group = 11.11.11.11, IP = 11.11.11.11, Error: Unable to remove PeerTblEntry
Mar 31 03:11:24 [IKEv1]: IP = 11.11.11.11, Header invalid, missing SA payload! (next payload = 4)
Solved! Go to Solution.
03-31-2008 06:49 AM
Hi Peter
In 7.2 code, do you have the following?
tunnel-group 11.11.11.11 ipsec-attrib
pre-shared-key ********
Also check your NAT statements, or attach entire config with sanitizing password entries and public IPs in condifgs and let me check.
Regards
03-31-2008 06:49 AM
Hi Peter
In 7.2 code, do you have the following?
tunnel-group 11.11.11.11 ipsec-attrib
pre-shared-key ********
Also check your NAT statements, or attach entire config with sanitizing password entries and public IPs in condifgs and let me check.
Regards
03-31-2008 07:05 AM
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.
03-31-2008 07:27 AM
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.
Please do not forget to rate the posts that are helpful and resolved your issue!
Regards
03-31-2008 08:23 AM
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?
03-31-2008 08:52 AM
"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.
03-31-2008 09:27 AM
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?
04-01-2008 07:24 AM
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.
04-01-2008 08:27 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide