04-29-2011 08:01 AM
Hi. I am tring to configure an IPPSEC VPN from a Cisco RV 120W (with latest firmware) with a Checkpoint NG
The two phases of IPSEC are completed with sucess and the tunnel is estabilihesed, but the traffic is being rejected in the other end (in checkpoint NG) with the error "encryption failure: Wrong peer gateway for decrypted packet (VPN Error code 01)"
Any ideas of whats happening here?
best regards,
--
Bruno Antunes
05-02-2011 06:48 AM
Not familiar with Check Point devices but from what you are explaining I would think the problem is with the tunnel type. Do you know if Check Point prefers AH over ESP? I would try to configure the RV120 to use AH IPSec if it supports it. I have not used the RV router so not sure how helpful this may be.
05-02-2011 07:43 AM
We will probably need more logging information. You stated that the SA for both phase 1 and phase 2 are successful correct? Is this on both sides? Have you ever gotten this to work? do you have other site-to-site VPN's on ether device? Are they working? have you tried different encryption levels?
let me know,
Cisco Small Business Support Center
Randy Manthey
CCNA, CCNA - Security
05-02-2011 08:03 AM
Hi
> You stated that the SA for both phase 1 and phase 2 are successful correct?
Yes
> Is this on both sides?
Yes
> Have you ever gotten this to work?
No
> do you have other site-to-site VPN's on ether device?
In the Cisco Router no. On the other end there are other IPSEC's VPNs.
> have you tried different encryption levels ?
Yes
--
Bruno Antunes
05-02-2011 08:58 AM
I can't speak to the errors on the Checkpoint device, but it sounds like it dosn't like the Remote Peer ID. I would think this would cause Phase 1 to fail. Are you using Perfect Forwarding? What are your key lifetimes for both phases? Does your company have other Checkpoint devices you could setup a VPN between one of those and the RV120W?
Cisco Small Business Support Center
Randy Manthey
CCNA, CCNA - Security
05-02-2011 09:18 AM
If the Remote Peer was invalid guess that phase 1 was not estabilished. As mentioned Phase 1 and Phase 2 are ok, tunel is up, only traffic does not flow with the mentioned error. Only tested flow from Cisco to Checkpoint.
I have Perfect Forwarding disabled (but same problem happens with it enabled).
I guess lifetimes do not cause errors here, as the tunel is estabilished. Both lifetimes are equal in the two ends
Phase 1 Lifetime = 86400 seconds
Phase 2 Lifetime = 3600 seconds
> Does your company have other Checkpoint devices you could setup a VPN between one of those and the RV120W?
For the moment this is the only one.
regards,
--
Bruno Antunes
05-02-2011 09:55 AM
I noticed in a previous post that you tested the flow from the Cisco to the Checkpoint. How about the Checkpoint to the Cisco? On the Cisco under VPN Status does it show you the Tx and Rx bytes? Are they both incrementing up?
Cisco Small Business Support Center
Randy Manthey
CCNA, CCNA - Security
05-02-2011 10:08 AM
I have already schedule a the test with the client so that they initiate the connection from their side (from "Checkpoint" to "Cisco"). I will post the results as soon i have then.
In the "IKE Policy" i have "Direction Type" set to "Both"; but i have also tried every possible combination.
When monitoring the Status from "IPsec Connection Status" i do see "Tx KB" and "Tx Packets" increase every time i try some traffic.
--
Bruno Antunes
05-18-2011 06:54 AM
After verifications from Checkpoint side, they have already configured other encryption domain that included the the accored local network source from Cisco side (They already add a VPN in the accorded source network range)
Changing local network so that there was no colision from "source" network on the other end the VPN worked. Tunnel is established and traffic flows.
regards,
--
Bruno Antunes
05-18-2011 08:01 AM
Here is something that you can check when doing IPSEC tunnels on different model devices. The encryption types don't always work together when using different brand devices. So a great thing to try is taking the encryption down to maybe 3des and MD5 on both sides of the tunnel for phase 1 and 2. I have done this many times in the past to get traffic to pass. The tunnel connects and is up and running but no traffic. The could be to a encryption mismatch in the different brands. Not sure why this seems to happen but its how the encryption of the data when it is going across the tunnel. I have seen it more when devices are using sha1,aes128,etc on both sides of the tunnel. Please let me know if this helped.
Another thing that will help is you dont need to have dead peer detection and keep alive on both sides of the tunnel. It only need to be enabled on one end or the other.
Thanks
Quendale
05-18-2011 08:51 AM
As i tried do explain in my last post, this issue is now solved.
The error with message "Wrong peer gateway for decrypted packet" on Checkpoint (for this issue) was caused by the fact that they already add another encryption domain (and an estabilished VPN) that already included the accorded source network (Local Traffic, from Cisco side). After the tunel was estabislhed with sucess, and passing some traffic, CheckPoint expected that trafic was for other VPN as gateway is different the traffic was being reject with that error message (this is my guest, so that the error message makes some sense).
Changing local network so that there was no colision from "source" network (local traffic on Cisco) on the other end (on checkpoint) the VPN worked. Tunnel is established and traffic flows.
So in conclusion; for this type of errors in the future: Check that and recheck that local (and also remote) networks do not cause colisions on other side
Thanks for all the help and sugesttions, regards,
--
Bruno Antunes
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