RV042 stops working during long transmissions

Unanswered Question
Apr 2nd, 2012

When my RV042 is accessed for long transmissions (svn check out, usually after 20 minutes ) the client receives a message "Gateway not responding, do you want to wait".

When this happens I see the following in the RV042 system log (the first 3 lines of the log below are normal):

Apr 2 17:36:53 2012Connection AcceptedTCP 192.168.2.2:8888->192.168.1.5:50046 on ppp1
Apr 2 17:36:54 2012Connection AcceptedTCP 192.168.2.2:8888->192.168.1.5:50046 on ppp1
Apr 2 17:36:54 2012Connection AcceptedTCP 192.168.2.2:8888->192.168.1.5:50046 on ppp1
Apr 2 17:37:00 2012Connection AcceptedUDP 110.33.141.168:500->180.243.235.82:500 on MAC=
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: received Vendor ID payload [RFC 3947]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: received Vendor ID payload [RFC 3947]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [FRAGMENTATION]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [FRAGMENTATION]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [e3a5966a76379fe707228231e5ce8652]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: ignoring Vendor ID payload [e3a5966a76379fe707228231e5ce8652]
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet
Apr 2 17:37:00 2012VPN Log packet from 110.33.141.168:500: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet
Apr 2 17:37:00 2012VPN Log (qknips3) #100: responding to Main Mode
Apr 2 17:37:00 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] >>> Responder Send Main Mode 2nd packet
Apr 2 17:37:00 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] >>> Responder Send Main Mode 2nd packet
Apr 2 17:37:00 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Main Mode 3rd packet
Apr 2 17:37:00 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Main Mode 3rd packet
Apr 2 17:37:00 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] >>> Responder send Main Mode 4th packet
Apr 2 17:37:00 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] >>> Responder send Main Mode 4th packet
Apr 2 17:37:01 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Main Mode 5th packet
Apr 2 17:37:01 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Main Mode 5th packet
Apr 2 17:37:01 2012VPN Log (qknips3) #100: Peer ID is ID_IPV4_ADDR: '192.168.1.5'
Apr 2 17:37:01 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] >>> Responder Send Main Mode 6th packet
Apr 2 17:37:01 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] >>> Responder Send Main Mode 6th packet
Apr 2 17:37:01 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] Main Mode Phase 1 SA Established
Apr 2 17:37:01 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] Main Mode Phase 1 SA Established
Apr 2 17:37:01 2012VPN Log (qknips3) #100: sent MR3, ISAKMP SA established
Apr 2 17:37:01 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 1st packet
Apr 2 17:37:01 2012VPN Log (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 1st packet
Apr 2 17:37:01 2012VPN Log (qknips3) #101: esp_ealg_id=3-3,esp_ealg_keylen=0, key_len=192,esp_aalg_id=1-1.
Apr 2 17:37:01 2012VPN Log (qknips3) #101: esp_ealg_id=3-3,esp_ealg_keylen=0, key_len=192,esp_aalg_id=1-1.
Apr 2 17:37:01 2012VPN Log (qknips3) #101: responding to Quick Mode
Apr 2 17:37:01 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] Inbound  SPI value = 28a4a9ab
Apr 2 17:37:01 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] Inbound  SPI value = 28a4a9ab
Apr 2 17:37:01 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] Outbound SPI value = 1cd20e4d
Apr 2 17:37:01 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] Outbound SPI value = 1cd20e4d
Apr 2 17:37:01 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] >>> Responder send Quick Mode 2nd packet
Apr 2 17:37:01 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] >>> Responder send Quick Mode 2nd packet
Apr 2 17:37:02 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 3rd packet
Apr 2 17:37:02 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 3rd packet
Apr 2 17:37:02 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected
Apr 2 17:37:02 2012VPN Log (qknips3) #101: [Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected
Apr 2 17:37:02 2012VPN Log (qknips3) #101: IPsec SA established {ESP=>0x1cd20e4d <0x28a4a9ab
Apr 2 17:37:02 2012VPN Log (qknips3) #98: received Delete SA(0x6ae048ca) payload: deleting IPSEC State #99
Apr 2 17:37:02 2012VPN Log (qknips3) #98: received Delete SA(0x6ae048ca) payload: deleting IPSEC State #99
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
miswilli Mon, 04/02/2012 - 06:36

Hi Johan,

I have a few questions for you:

1. Is this a RV042 v3? If so are you on the latest version of firmware (4.1.1.01)?

I ask this because the latest version of firmware fixes some ICMP issues from earlier versions of firmware (see the release notes at:

http://www.cisco.com/en/US/docs/routers/csbr/rv0xx/release/rv0xx_rn_v4-1-1-01.pdf ) which can cause issues with a gateway-to gateway VPN when trying to reconnect after a session has expired. If you are on an older version of firmware, please upgrade the firmware. You can find the link to the latest version at:

http://www.cisco.com/cisco/software/release.html?mdfid=282414011&flowid=785&softwareid=282465789

But, please be aware that if your RV042 is an older hardware version, this firmware is NOT compatible.

2. What type of VPN is this: client to gateway or gateway-to-gateway? If you are using client software for the connection, are you using QuickVPN, latest version 1.4.2.1 and, if so, what OS is on the client PC? I ask this because QVPN will give the same error when there are issues pinging the gateway. I performed a traceroute and ping on the IP address 110.33.141.168 and once you get past the twtelecom hop, there is alot of latency. See the results below:

Tracing route to d110-33-141-168.mas800.nsw.optusnet.com.au [110.33.141.168]

over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  97.65.143.129

  2     2 ms     1 ms     1 ms  64-128-71-33.static.twtelecom.net [64.128.71.33]

  3    61 ms    75 ms    60 ms  lax2-pr2-xe-1-3-0-0.us.twtelecom.net [66.192.241

.218]

  4   208 ms   209 ms   208 ms  203.208.174.190

  5   209 ms   209 ms   210 ms  mas1-ge3-0.gw.optusnet.com.au [211.29.125.238]

  6   209 ms   208 ms   209 ms  mas800.ba.optusnet.com.au [198.142.128.102]

  7   223 ms   223 ms   224 ms  d110-33-141-168.mas800.nsw.optusnet.com.au [110.

33.141.168]

Trace complete.

****************************

ping 110.33.141.168

Pinging 110.33.141.168 with 32 bytes of data:

Reply from 110.33.141.168: bytes=32 time=224ms TTL=57

Reply from 110.33.141.168: bytes=32 time=224ms TTL=57

Reply from 110.33.141.168: bytes=32 time=223ms TTL=57

Reply from 110.33.141.168: bytes=32 time=226ms TTL=57

Ping statistics for 110.33.141.168:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 223ms, Maximum = 226ms, Average = 224ms

Please let me know the answers and I will be happy to help anyway I can. Have a good day!

johanvermeij Mon, 04/02/2012 - 15:36

Thank you Misty, I will send the info tonight (I am located in Indonesia).

johanvermeij Tue, 04/03/2012 - 03:15

I have upgraded the firmware for the RV042 to the latest.

I have hardware version 3 so the upgrade was effective.

The ping and trace route show the same results when I try from here

TraceRoute to 110.33.141.168 [d110-33-141-168.mas800.nsw.optusnet.com.au]

Hop(ms)(ms)(ms)
     IP AddressHost name
1   1   0   0      206.123.64.42   -  

2   0   0   0      64.124.196.225  xe-4-2-0.er2.dfw2.us.above.net 

3   1   0   0      64.125.26.213  xe-1-1-0.cr2.dfw2.us.above.net 

4   5   5   5      64.125.31.122  xe-4-2-0.cr2.iah1.us.above.net 

5   39   37   37      64.125.30.50  xe-0-3-0.cr2.lax112.us.above.net 

6   45   45   46      64.125.26.30  xe-2-1-0.cr2.sjc2.us.above.net 

7   45   69   46      64.125.31.69  xe-0-1-0.mpr2.pao1.us.above.net 

8   46   46   46      64.125.13.6  above-gige.pao.singtel.net 

9   53   54   53      203.208.149.250   -  

10   202   202   203      203.208.174.190   -  

11   205   208   207      211.29.125.242  mas2-ge3-0.gw.optusnet.com.au 

12   219   215   214      110.33.141.168

  d110-33-141-168.mas800.nsw.optusnet.com.au 

The avg ping to 110.33.141.168 is 427 ms

But that has nothing to do with the router of course

Thanks a lot Misty, we will try again

johanvermeij Tue, 04/03/2012 - 04:28

We just tried with the new firmware and after 20 minutes the same thing happened.

It looks like it is always happening after 20 minutes of intensive download

Apr 3 18:22:25 2012Connection AcceptedTCP 192.168.1.5:51283->192.168.2.2:8888 on eth0
Apr 3 18:22:26 2012Connection AcceptedUDP 110.33.138.144:500->180.243.235.82:500 on MAC=
Apr 3 18:22:26 2012Connection AcceptedTCP 192.168.1.5:51283->192.168.2.2:8888 on eth0
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: received Vendor ID payload [RFC 3947]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: received Vendor ID payload [RFC 3947]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [FRAGMENTATION]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [FRAGMENTATION]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [e3a5966a76379fe707228231e5ce8652]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: ignoring Vendor ID payload [e3a5966a76379fe707228231e5ce8652]
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet
Apr 3 18:22:26 2012VPN Log packet from 110.33.138.144:500: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet
Apr 3 18:22:26 2012VPN Log (qknips3) #5: responding to Main Mode
Apr 3 18:22:26 2012VPN Log (qknips3) #5: [Tunnel Negotiation Info] >>> Responder Send Main Mode 2nd packet
Apr 3 18:22:26 2012VPN Log (qknips3) #5: [Tunnel Negotiation Info] >>> Responder Send Main Mode 2nd packet
Apr 3 18:22:26 2012Connection AcceptedTCP 192.168.1.5:51283->192.168.2.2:8888 on eth0
Apr 3 18:22:26 2012Connection AcceptedTCP 192.168.1.5:51283->192.168.2.2:8888 on eth0
Apr 3 18:22:27 2012Connection AcceptedTCP 192.168.1.5:51283->192.168.2.2:8888 on eth0
Apr 3 18:22:27 2012Connection AcceptedTCP 192.168.1.5:51283->192.168.2.2:8888 on eth0
Apr 3 18:22:27 2012VPN Log (qknips3) #5: [Tunnel Negotiation Info] <<< Responder Received Main Mode 3rd packet
Apr 3 18:22:27 2012VPN Log (qknips3) #5: [Tunnel Negotiation Info] <<< Responder Received Main Mode 3rd packet
Apr 3 18:22:27 2012Connection AcceptedTCP 192.168.1.5:51283->192.168.2.2:8888 on eth0
Apr 3 18:22:27 2012VPN Log (qknips3) #5: [Tunnel Negotiation Info] >>> Responder send Main Mode 4th packet
Apr 3 18:22:27 2012VPN Log (qknips3) #5: [Tunnel Negotiation Info] >>> Responder send Main Mode 4th packet
johanvermeij Tue, 04/03/2012 - 03:16

Sorry, I forgot to mention.

We are using Client to Gateway with the latest QuickVPN client

jasbryan Tue, 04/03/2012 - 07:26

Johan,

The logs show me that your RV042 Wan interface is using a private ip address. The RV042 needs to hold the public ip address on it's WAN interface for client to gateway function properly. Currently having a private ip address isn't a support configuration because the RV042 doesn't have full control over data flow.

Jasbryan

johanvermeij Tue, 04/03/2012 - 17:12

Hi Jasbryan

I have a domain (xxx.com) registered with Sitelutions and this translates to my static IP address in Indonesia (xxx.xxx.xxx.xxx).

Just to make sure:

My public IP address should be xxx.xxx.xxx.xxx

The internal IP address of the router is 192,168.2.10.

The ADSL modem I have (IP 192.168.2.1) is bridged.

I connect to my ISP using the ADSL method in the main RV042 setup screen (using the user ID and the password my ISP has assigned to me, PPP0E).

The RV042 has been working fine for quite a while but long transmissions fail (for example a full checkout of a svn repository fails).

I attach my WAN setup page.

Thanks

Johan Vermeij

Attachment: 
johanvermeij Thu, 04/05/2012 - 20:33

Hi

We did a svn checkout this morning using port forwarding (bypassing the router).

The checkout has been running for 4 hours without interruptiuon.

When we do the same thing through the vpn the transmission stops after 20 minutes.

Bypassing the vpn router defeats the purpose of having one of course.

Please let me know if there is any solution.

Thanks

Johan Vermeij

miswilli Mon, 04/09/2012 - 07:42

Hi Johan,

I recommend you lower your WAN MTU settings down from the 1500 default to avoid

packet fragmentation which can be an issue with QuickVPN (especially in other countries outside the

USA.)

The best way to find this value is to call your ISP and ask or you can optionally do an MTU test

yourself: http://help.expedient.com/broadband/mtu_ping_test.shtml

If this information does not help, please feel free to contact us at 1-866-606-1866. While this is the number for US support, we can find an interpreter if needed so we can assist you.

I hope you have a wonderful day!

Actions

Login or Register to take actions

This Discussion

Posted April 2, 2012 at 4:36 AM
Stats:
Replies:10 Avg. Rating:
Views:979 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 1,091
2 369
3 181
4 83
5 80
Rank Username Points
5
5