04-02-2012 04:36 AM
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 2012 | Connection Accepted | TCP 192.168.2.2:8888->192.168.1.5:50046 on ppp1 |
Apr 2 17:36:54 2012 | Connection Accepted | TCP 192.168.2.2:8888->192.168.1.5:50046 on ppp1 |
Apr 2 17:36:54 2012 | Connection Accepted | TCP 192.168.2.2:8888->192.168.1.5:50046 on ppp1 |
Apr 2 17:37:00 2012 | Connection Accepted | UDP 110.33.141.168:500->180.243.235.82:500 on MAC= |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008] |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008] |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: received Vendor ID payload [RFC 3947] |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: received Vendor ID payload [RFC 3947] |
Apr 2 17:37:00 2012 | VPN 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 2012 | VPN 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 2012 | VPN Log | packet from 110.33.141.168:500: ignoring Vendor ID payload [FRAGMENTATION] |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: ignoring Vendor ID payload [FRAGMENTATION] |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: ignoring Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120] |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: ignoring Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120] |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: ignoring Vendor ID payload [e3a5966a76379fe707228231e5ce8652] |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: ignoring Vendor ID payload [e3a5966a76379fe707228231e5ce8652] |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet |
Apr 2 17:37:00 2012 | VPN Log | packet from 110.33.141.168:500: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet |
Apr 2 17:37:00 2012 | VPN Log | (qknips3) #100: responding to Main Mode |
Apr 2 17:37:00 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] >>> Responder Send Main Mode 2nd packet |
Apr 2 17:37:00 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] >>> Responder Send Main Mode 2nd packet |
Apr 2 17:37:00 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Main Mode 3rd packet |
Apr 2 17:37:00 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Main Mode 3rd packet |
Apr 2 17:37:00 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] >>> Responder send Main Mode 4th packet |
Apr 2 17:37:00 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] >>> Responder send Main Mode 4th packet |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Main Mode 5th packet |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Main Mode 5th packet |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: Peer ID is ID_IPV4_ADDR: '192.168.1.5' |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] >>> Responder Send Main Mode 6th packet |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] >>> Responder Send Main Mode 6th packet |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] Main Mode Phase 1 SA Established |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] Main Mode Phase 1 SA Established |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: sent MR3, ISAKMP SA established |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 1st packet |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #100: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 1st packet |
Apr 2 17:37:01 2012 | VPN 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 2012 | VPN 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 2012 | VPN Log | (qknips3) #101: responding to Quick Mode |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] Inbound SPI value = 28a4a9ab |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] Inbound SPI value = 28a4a9ab |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] Outbound SPI value = 1cd20e4d |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] Outbound SPI value = 1cd20e4d |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] >>> Responder send Quick Mode 2nd packet |
Apr 2 17:37:01 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] >>> Responder send Quick Mode 2nd packet |
Apr 2 17:37:02 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 3rd packet |
Apr 2 17:37:02 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] <<< Responder Received Quick Mode 3rd packet |
Apr 2 17:37:02 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected |
Apr 2 17:37:02 2012 | VPN Log | (qknips3) #101: [Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected |
Apr 2 17:37:02 2012 | VPN Log | (qknips3) #101: IPsec SA established {ESP=>0x1cd20e4d <0x28a4a9ab |
Apr 2 17:37:02 2012 | VPN Log | (qknips3) #98: received Delete SA(0x6ae048ca) payload: deleting IPSEC State #99 |
Apr 2 17:37:02 2012 | VPN Log | (qknips3) #98: received Delete SA(0x6ae048ca) payload: deleting IPSEC State #99 |
04-02-2012 06:36 AM
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!
04-02-2012 03:36 PM
Thank you Misty, I will send the info tonight (I am located in Indonesia).
04-03-2012 03:15 AM
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 Address | Host 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
04-03-2012 04:28 AM
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 2012 | Connection Accepted | TCP 192.168.1.5:51283->192.168.2.2:8888 on eth0 |
Apr 3 18:22:26 2012 | Connection Accepted | UDP 110.33.138.144:500->180.243.235.82:500 on MAC= |
Apr 3 18:22:26 2012 | Connection Accepted | TCP 192.168.1.5:51283->192.168.2.2:8888 on eth0 |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008] |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008] |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: received Vendor ID payload [RFC 3947] |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: received Vendor ID payload [RFC 3947] |
Apr 3 18:22:26 2012 | VPN 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 2012 | VPN 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 2012 | VPN Log | packet from 110.33.138.144:500: ignoring Vendor ID payload [FRAGMENTATION] |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: ignoring Vendor ID payload [FRAGMENTATION] |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: ignoring Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120] |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: ignoring Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120] |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: ignoring Vendor ID payload [e3a5966a76379fe707228231e5ce8652] |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: ignoring Vendor ID payload [e3a5966a76379fe707228231e5ce8652] |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet |
Apr 3 18:22:26 2012 | VPN Log | packet from 110.33.138.144:500: [Tunnel Negotiation Info] <<< Responder Received Main Mode 1st packet |
Apr 3 18:22:26 2012 | VPN Log | (qknips3) #5: responding to Main Mode |
Apr 3 18:22:26 2012 | VPN Log | (qknips3) #5: [Tunnel Negotiation Info] >>> Responder Send Main Mode 2nd packet |
Apr 3 18:22:26 2012 | VPN Log | (qknips3) #5: [Tunnel Negotiation Info] >>> Responder Send Main Mode 2nd packet |
Apr 3 18:22:26 2012 | Connection Accepted | TCP 192.168.1.5:51283->192.168.2.2:8888 on eth0 |
Apr 3 18:22:26 2012 | Connection Accepted | TCP 192.168.1.5:51283->192.168.2.2:8888 on eth0 |
Apr 3 18:22:27 2012 | Connection Accepted | TCP 192.168.1.5:51283->192.168.2.2:8888 on eth0 |
Apr 3 18:22:27 2012 | Connection Accepted | TCP 192.168.1.5:51283->192.168.2.2:8888 on eth0 |
Apr 3 18:22:27 2012 | VPN Log | (qknips3) #5: [Tunnel Negotiation Info] <<< Responder Received Main Mode 3rd packet |
Apr 3 18:22:27 2012 | VPN Log | (qknips3) #5: [Tunnel Negotiation Info] <<< Responder Received Main Mode 3rd packet |
Apr 3 18:22:27 2012 | Connection Accepted | TCP 192.168.1.5:51283->192.168.2.2:8888 on eth0 |
Apr 3 18:22:27 2012 | VPN Log | (qknips3) #5: [Tunnel Negotiation Info] >>> Responder send Main Mode 4th packet |
Apr 3 18:22:27 2012 | VPN Log | (qknips3) #5: [Tunnel Negotiation Info] >>> Responder send Main Mode 4th packet |
04-05-2012 04:09 AM
The show still stops after 20 odd minutes
04-03-2012 03:16 AM
Sorry, I forgot to mention.
We are using Client to Gateway with the latest QuickVPN client
04-03-2012 07:26 AM
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
04-03-2012 05:12 PM
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
04-05-2012 08:33 PM
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
04-09-2012 07:42 AM
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!
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