Solved

RV042 G to G connectivity problem

Posted on 2012-04-03
5
1,589 Views
Last Modified: 2015-12-07
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
0
Comment
Question by:btm02sf
  • 2
  • 2
5 Comments
 
LVL 6

Expert Comment

by:Joshua1909
Comment Utility
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
 
LVL 1

Author Comment

by:btm02sf
Comment Utility
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
 
LVL 1

Author Comment

by:btm02sf
Comment Utility
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
 
LVL 6

Accepted Solution

by:
Joshua1909 earned 500 total points
Comment Utility
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
 
LVL 1

Expert Comment

by:bskaggs32
Comment Utility
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

Featured Post

Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

Join & Write a Comment

Understanding FTPS File transfer is a common requirement in most Enterprises. While there are numerous ways to get a file from Point A to Point B over a network, perhaps the most common method still in use is FTP – File Transfer Protocol. FTP is …
The article explains the protocols and technology which is involved when two computers on different TCP/IP networks communicate with each other. In the diagram, a router is used to segregate two networks. The networks are 192.168.1.0/24 and 192…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now