RV042 G to G connectivity problem

I'm having a problem establishing a VPN tunnel in between two Cisco RV042 routers. They are both running the latest firmware (4.1 something). Both sites have Comcast Business Gateways and static IPs, so I figured that setting up the tunnel would be a snap (IP to IP). Well, it did work initially right off the bat using 100% default settings and then stopped working and I never got it back up since. It was in between the first successful test and now that I performed the firmware upgrade on both routers.

Here's what's going on:
- Client VPN access (group VPN) works fine.
- QuickVPN works fine.
- I have a backup DSL connection (set as a smart link backup) at office A. If I switch to this DSL which is on Wan 2 by unplugging the Comcast cable going to Wan 1, and then modify tunnel 1 to use Wan2 at site A, and point tunnel 1 to the DSL IP address at site B, the VPN goes up and stays up.

That's where the good news ends. If I switch back to WAN1 (tunnel 1) and the Comcast static, it stops working. I've tried with different security settings, but last that worked in "DSL" mode resulted in this error log (see below).

IPSec Settings:
Group 1 / AES-256 / SHA1 / 86400

PFS yes.

Group 1 / AES-256 / SHA1 / 3600

Keep alive yes.

What could the problem be?

Thanks,

Andrew

Apr 3 15:34:02 2012
VPN Log
packet from 75.149.47.253:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Apr 3 15:34:02 2012
VPN Log
packet from 75.149.47.253:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Apr 3 15:34:06 2012
VPN Log
packet from 75.149.47.254:1: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet
Apr 3 15:34:06 2012
VPN Log
packet from 75.149.47.254:1: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet
Apr 3 15:34:06 2012
VPN Log
(grpips0)[12] 192.168.169.0/24=== ...75.149.47.254===192.168.1.2/32 #83: responding to Main Mode from unknown peer 75.149.47.254
Apr 3 15:34:06 2012
VPN Log
(grpips0)[12] 192.168.169.0/24=== ...75.149.47.254===192.168.1.2/32 #83: OAKLEY_AES_CBC is not enabled for this connection. Attribute OAKLEY_ENCRYPTION_ALGORITHM
Apr 3 15:34:06 2012
VPN Log
(grpips0)[12] 192.168.169.0/24=== ...75.149.47.254===192.168.1.2/32 #83: OAKLEY_AES_CBC is not enabled for this connection. Attribute OAKLEY_ENCRYPTION_ALGORITHM
Apr 3 15:34:06 2012
VPN Log
(grpips0)[12] 192.168.169.0/24=== ...75.149.47.254===192.168.1.2/32 #83: no acceptable Oakley Transform
Apr 3 15:34:06 2012
VPN Log
(grpips0)[12] 192.168.169.0/24=== ...75.149.47.254===192.168.1.2/32 #83: no acceptable Oakley Transform
Apr 3 15:34:06 2012
VPN Log
(grpips0)[12] 192.168.169.0/24=== ...75.149.47.254===192.168.1.2/32 #83: sending notification NO_PROPOSAL_CHOSEN to 75.149.47.254:500
Apr 3 15:34:18 2012
VPN Log
(grpips0)[1] 192.168.169.0/24=== ...75.149.47.254===? #79: max number of retransmissions (2) reached STATE_AGGR_I1
Apr 3 15:34:18 2012
VPN Log
(grpips0)[1] 192.168.169.0/24=== ...75.149.47.254===? #79: max number of retransmissions (2) reached STATE_AGGR_I1
Apr 3 15:34:18 2012
VPN Log
(grpips0)[1] 192.168.169.0/24=== ...75.149.47.254===? #79: starting keying attempt 31 of an unlimited number
Apr 3 15:34:18 2012
VPN Log
(grpips0)[1] 192.168.169.0/24=== ...75.149.47.254===? #84: initiating Aggressive Mode #84 to replace #79, connection 'grpips0'
Apr 3 15:34:18 2012
VPN Log
(grpips0)[1] 192.168.169.0/24=== ...75.149.47.254===? #84: [Tunnel Negotiation Info] >>> Initiator Send Aggressive Mode 1st packet
Apr 3 15:34:18 2012
VPN Log
(grpips0)[1] 192.168.169.0/24=== ...75.149.47.254===? #84: [Tunnel Negotiation Info] >>> Initiator Send Aggressive Mode 1st packet
Apr 3 15:34:18 2012
VPN Log
packet from 75.149.47.254:1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
LVL 1
btm02sfAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Joshua1909Commented:
Hi,

It sounds like it's having issues in phase 2.
Would you be able to post scrubbed configs from your routers?

Cheers,
Josh
0
btm02sfAuthor Commented:
Here you go.... Thanks!

Site A
Tunnel No. 1
Tunnel Name : ABPD_G1 W1
Interface : WAN1

Local Group Setup
Local Security Gateway Type : IP Only
IP Address : 76.150.48.254
Local Security Group Type : IPSubnet
IP Address : 192.168.168.0
Subnet Mask : 255.255.255.0


Remote Group Setup

Remote Security Gateway Type : IP Only
IP Address: 24.25.204.18
Remote Security Group Type : IPSubnet
IP Address : 192.168.169.0
Subnet Mask : 255.255.255.0

IPSec Setup

Keying Mode : IKE with Preshared key
Phase 1 DH Group : Group 1 - 768 bit
Phase 1 Encryption : AES-256
Phase 1 Authentication : SHA1
Phase 1 SA Life Time : 86400seconds
Perfect Forward Secrecy : YES

Phase 2 DH Group : Group 1 - 768 bit
Phase 2 Encryption : AES-256
Phase 2 Authentication : SHA1
Phase 2 SA Life Time : 3600seconds
Preshared Key : xxxxxxxxxx
Minimum Preshared Key Complexity : Enable

Site B

Tunnel No. 1
Tunnel Name : ABPD_G2 W1
Interface : WAN1

Local Group Setup
Local Security Gateway Type : 
IP Only
IP Address : 24.25.204.18
Local Security Group Type : IPSubnet
IP Address : 192.168.169.0
Subnet Mask : 255.255.255.0

Remote Group Setup
Remote Security Gateway Type : 
IP Only
IP Address: 76.150.48.254
Remote Security Group Type : 
Subnet
IP Address : 192.168.168.0
Subnet Mask : 255.255.255.0

IPSec Setup
Keying Mode : IKE with Preshared key
Phase 1 DH Group : Group 1 - 768 bit
Phase 1 Encryption : AES-256
Phase 1 Authentication : SHA1
Phase 1 SA Life Time : 86400seconds
Perfect Forward Secrecy : YES

Phase 2 DH Group : Group 1 - 768 bit
Phase 2 Encryption : AES-256
Phase 2 Authentication : SHA1
Phase 2 SA Life Time : 3600seconds
Preshared Key : xxxxxxxxxx
Minimum Preshared Key Complexity : Enable

Keep Alive : yes
0
btm02sfAuthor Commented:
Go figure... The opposite is also true. We have a backup DSL at office B as well. Today I got a chance to reverse the scenario:
- Comcast cable at office A (on Wan 1)
- AT&T DSL at office B (on Wan 2)

Changed the local gateway type at B to dynamic IP + email address - and that did the trick. Did not make any changes to the IPSec setup I listed above.

I then switched the office B router to load balance which enabled Wan 2 and the VPN. That brought up a bunch of load balancing issues, but that's a different topic.

So, after all what is the problem with my standard G to G over static IP? What else could be happening?
0
Joshua1909Commented:
Hi,
I'm not familiar with the Comcast devices, but I can't see any issues in your configuration.
Do you have any configuration on the Comcast, and what's the model of it?

To break it down, you're using the same VPN configuration between the Internet connections. It would seem the main variables are the Internet plan, the physical ports connecting to, and the devices terminating the Internet services.


There are a couple things I would get you to check:

-Have you tried changing the encryption to 3DES instead of AES on both ends?

-On your main Internet service, are there any firewall configurations (at the ISP level) that might be blocking IPsec traffic? (generally only a problem with consumer plans, but it's possible.)

-Have you tried changing the DSL connection to WAN 1, and the other to WAN 2 (in case there is a physical issue)? This is unlikely but in the process of troubleshooting, every variation we can test...

I've had a bit of a search for a manual, and it looks like most of the Comcast devices have firewall capability. It may be possible that there is something on there interfering.
1

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
bskaggs32Commented:
I was testing a new old stock RV042 VPN  to TZ215 SonicWALL for a client's satellite office spin up.
I used our commercial internet at the office to test, but used DHCP to grab a public address rather the pull one out of our perimeter firewall. I fought it for a couple of hours thinking I was a missing a config somewhere. I don't have to setup VPNs everyday, so I was a bit rusty.  It sounds obvious, but apparently our ISP handles its DHCP traffic differently. We have a commercial account with quite a few statics. I was just being lazy and thought I would grab one up real quick. Lesson learned. VPN traffic blocked on commercial DHCP network!! I didn't hit me until I read this article. Doh!!!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Internet Protocol Security

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.