cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1644
Views
0
Helpful
11
Replies

RV082 - SRP527W - VPN behind NAT not working

Hello,

I've really strange behaviors with my routers. We managed to get things running but once a week, the VPN link is down.

The connection is not restart, both routers shows "connected" but are not, and we had to click on "disconnect" to get the link back.

That was before an update in our infrastructure. Now, both routers are behind routers, so both NAT.

Now, the connection works for some time, but once a week, the link disconnected but i'm unable to get it back ! NOTHING works.

Last time, i spent 2Hours to configure the link again, setting the same parameters almost 10 time, and suddenly by magic, the 11st time it worked again. I read many people have troubles with RVXXX firmware so i don't know what to think.

Anyway, my BIG concern now, is that the link is down again, and it has been 6hours since we can't got it back. I restarted the routers many times, i've made some changes in the configuration, but if it worked, why should i modify it ?????? Why is it not working anymore ?

The log for the RV082 is almost empty about the link. Here's a snippet :

Feb 10 19:01:52 2014VPN Log (g2gips0) #8: initiating Main Mode
Feb 10 19:01:52 2014VPN Log (g2gips0) #8: [Tunnel Negotiation Info] >>> Initiator Send Main Mode 1st packet
Feb 10 19:01:52 2014VPN Log (g2gips0) #8: [Tunnel Negotiation Info] >>> Initiator Send Main Mode 1st packet
Feb 10 19:01:52 2014System Log gateway_to_gateway.htm is changed.
Feb 10 19:09:08 2014VPN Log (g2gips0): deleting connection
Feb 10 19:09:08 2014VPN Log (g2gips0) #8: deleting state (STATE_MAIN_I1)
Feb 10 19:09:08 2014VPN Log added connection description (g2gips0)
Feb 10 19:09:08 2014VPN Log listening for IKE messages
Feb 10 19:09:08 2014VPN Log forgetting secrets
Feb 10 19:09:08 2014VPN Log loading secrets from '/etc/ipsec.d/ipsec.secrets'
Feb 10 19:09:09 2014System Log gateway_to_gateway.htm is changed.

The log for the SRP527W is full of this :

Dump pluto log message in syslog  :

cat /var/log/messages |grep pluto

Jan  1 02:29:39 TLSR0254 authpriv.warn pluto[1156]: "G2" #187: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1

Jan  1 02:29:39 TLSR0254 authpriv.warn pluto[1156]: "G2" #187: STATE_MAIN_R1: sent MR1, expecting MI2

Jan  1 02:30:09 TLSR0254 authpriv.warn pluto[1156]: "G2" #186: max number of retransmissions (2) reached STATE_MAIN_R1

Jan  1 02:30:19 TLSR0254 authpriv.warn pluto[1156]: packet from 37.1.XXX.XXX:500: received Vendor ID payload [RFC 3947] method set to=109

Jan  1 02:30:19 TLSR0254 authpriv.warn pluto[1156]: packet from 37.1.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 109

Jan  1 02:30:19 TLSR0254 authpriv.warn pluto[1156]: packet from 37.1.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 109

Jan  1 02:30:19 TLSR0254 authpriv.warn pluto[1156]: packet from 37.1.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]

Jan  1 02:30:19 TLSR0254 authpriv.warn pluto[1156]: "G2" #188: responding to Main Mode

Jan  1 02:30:19 TLSR0254 authpriv.warn pluto[1156]: "G2" #188: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1

Jan  1 02:30:19 TLSR0254 authpriv.warn pluto[1156]: "G2" #188: STATE_MAIN_R1: sent MR1, expecting MI2

Jan  1 02:30:25 TLSR0254 authpriv.warn pluto[1156]: pending Quick Mode with 37.1.XXX.XXX "G2" took too long -- replacing phase 1

Jan  1 02:30:25 TLSR0254 authpriv.warn pluto[1156]: "G2" #189: initiating Main Mode to replace #185

Jan  1 02:30:49 TLSR0254 authpriv.warn pluto[1156]: "G2" #187: max number of retransmissions (2) reached STATE_MAIN_R1

Jan  1 02:30:59 TLSR0254 authpriv.warn pluto[1156]: packet from 37.1.XXX.XXX:500: received Vendor ID payload [RFC 3947] method set to=109

Jan  1 02:30:59 TLSR0254 authpriv.warn pluto[1156]: packet from 37.1.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 109

Jan  1 02:30:59 TLSR0254 authpriv.warn pluto[1156]: packet from 37.1.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 109

Jan  1 02:30:59 TLSR0254 authpriv.warn pluto[1156]: packet from 37.1.XXX.XXX:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]

Jan  1 02:30:59 TLSR0254 authpriv.warn pluto[1156]: "G2" #190: responding to Main Mode


Please help me to get things sorted. I just don't understand why nothing is written in the log about the SRP trying to make a connection. I also don't understand why suddenly the link is broken, and without changing anything, it can't get it back normally !!

Best Regards

11 Replies 11

mpyhala
Rising star
Rising star

g2metric_g2metric,

I recommend that you contact support for assistance with this issue. We would need to gather too much information to post here and it could take a very long time to troubleshoot.

www.cisco.com/go/sbsc

- Marty

Samir Darji
Contributor
Contributor

Next time this happens, reboot the rv082 and reconnect.  If it works fine, it's just the rv082 needing regular reboots.  A fact of life for smb routers by any manufacturer.

Huntsville's Premiere Car and Bike e-magazine: www.huntsvillecarscene.com

Huntsville's Premiere Car and Bike e-magazine: www.huntsvillecarscene.com