Re: RV042 does not permit VPN pass-thru...

jrhelgeson · ‎11-12-2009

Firmware ver: 1.3.12.19

I have the RV042 protecting my home network. I do not have any VPN configured on the device yet.

With my laptop, I cannot establish a VPN connection to a remote site, using my Cisco VPN client v5.0.06.0100 (most recent)

Connected behind the RV042, no vpn connection can be made.

- error message -

Secure VPN Connection terminated locally by the Client.

Reason 412: The remote peer is no longer responding.

Connection terminated on: Nov 12, 2009 16:00:00 Durration: 0 day(s), 00:00.00

If I connect to the internet anywhere else, I connect just fine.

Now, I know why this happens. The RV042 is listening on UDP port 500 on the external interface for IPSec ISAKMP, however, the external interface is also used for NAT translation, and when the VPN gateway I'm trying to connect to tries to respond to MY UDP/500 port... but the ROUTER answers that query rather than passing it back to me.

I've dealt with this on the PIX firewalls (I'm an old Cisco networking guy) and those commands are not available on the RV042.

I"ve checked the settings, IPSec VPN Pass-through is ENABLED, as are all of the other pass-through settings.

How can I stop this stupid router from answering/listening on port 500?

jestowe · ‎11-12-2009

jrhelgeson,

Thank you for visiting Cisco Community Forums.

Sometimes when using the Cisco VPN Client or other vpn clients, it is required to allow ICMP requests to return from the router. Try disabling this feature under the Firewall tab:

Block WAN Request :

Enable

Disable

Thanks,

Jeff.

jrhelgeson · ‎11-13-2009

No go, I already had that disabled. Cisco VPN Client trying to connect to a Cisco ASA firewall, the client sitting behind the RV042...

Blocking disabled,

All 3 of the VPN pass through settings enabled.

Even trying to forward UDP 500 to my internal laptop ethernet ip address... it does not work.

Joel Helgeson

Alejandro Gallego · ‎11-15-2009

Try the following:

remove the port forward for port 500

under protocol binding; bind IPSec protocol 50 and 51 (I am not near a RV at the moment, so i'm not sure if Protocol 51 is available) to your WAN port

the ammount of bandwidth doesnt really matter

Once you have that done try again and let us know the results. Also if you could enable loggin and make sure all options are checked and post the log.

-Alejandro

jrhelgeson · ‎11-15-2009

By binding the protocol to the port, I assume you meant under the QoS setting, and setting ESP & GRE qos under wan1? Well, i did that. No, I still cannot connect out through a VPN. Yes, i did remove the UDP 500 trial setting for port forwarding.

Can you please set this up in your lab?

This is preventing me from getting work done at home, and the whole reason I bought this was to get decent QoS with my VoIP so my voice traffic would not get killed by my data traffic. I have no intentions right now of using the VPN capabilities of this router.

You can clearly see the request go out on the top line at :11 seconds, by :51 seconds, the connection had timed out and i had my error message. The system log was set to display all logs.

System Log Table
Nov 15 17:25:11 2009       Connection Accepted       UDP 192.168.0.35:64790->206.19.211.141:500 on ixp1
Nov 15 17:25:16 2009       Connection Accepted       UDP 87.126.145.181:11087->192.168.0.25:65535 on ixp1
Nov 15 17:25:27 2009       Connection Accepted       UDP 192.168.0.25:55136->216.239.32.10:53 on ixp1
Nov 15 17:25:39 2009       Connection Accepted       UDP 73.237.44.1:67->255.255.255.255:68 on ixp1
Nov 15 17:25:42 2009       Connection Accepted       ICMP type 8 code 0 24.245.32.25->24.245.32.1 on ixp1
Nov 15 17:25:48 2009       Connection Accepted       IGMP 73.237.44.1->224.0.0.1 on ixp1
Nov 15 17:25:52 2009       Connection Accepted       TCP 192.168.0.35:51961->205.203.132.1:80 on ixp1

Alejandro Gallego · ‎11-15-2009

Can you post the Cisco VPN log? Not looking to change your mind or anything but if you are also using your VOIP phone (presumably for your office) why not create a permanent IPSec tunnel.

The part that is intersting is that we see the request leave but we never see the request come back. If the router was blocking the request, there should be a Policy Violation in the log. Taking a look at your VPN application log would be very helpful.

jrhelgeson · ‎11-15-2009

Of course you won't see the reply, because the reply is back to UDP 500, which the firewall itself answers.

It won't log that information.

There is a slight time shift between the router time and the laptop time, my laptop IP is 192.168.0.35.

Cisco Systems VPN Client Version 5.0.06.0110
Copyright (C) 1998-2009 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Windows, WinNT
Running on: 6.1.7600

73 22:13:13.038 11/15/09 Sev=Info/4 CM/0x63100002
Begin connection process

74 22:13:13.071 11/15/09 Sev=Info/4 CM/0x63100004
Establish secure connection

75 22:13:13.071 11/15/09 Sev=Info/4 CM/0x63100024
Attempt connection with server "206.19.211.141"

76 22:13:13.075 11/15/09 Sev=Info/6 IKE/0x6300003B
Attempting to establish a connection with 206.19.211.141.

77 22:13:13.081 11/15/09 Sev=Info/4 IKE/0x63000001
Starting IKE Phase 1 Negotiation

78 22:13:13.085 11/15/09 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Frag), VID(Nat-T), VID(Unity)) to 206.19.211.141

79 22:13:13.243 11/15/09 Sev=Info/4 IPSEC/0x63700008
IPSec driver successfully started

80 22:13:13.243 11/15/09 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

81 22:13:18.314 11/15/09 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!

82 22:13:18.314 11/15/09 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 206.19.211.141

83 22:13:23.382 11/15/09 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!

84 22:13:23.382 11/15/09 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 206.19.211.141

85 22:13:28.454 11/15/09 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!

86 22:13:28.454 11/15/09 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 206.19.211.141

87 22:13:33.522 11/15/09 Sev=Info/4 IKE/0x63000017
Marking IKE SA for deletion (I_Cookie=4FACA0813566C9D2 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

88 22:13:34.037 11/15/09 Sev=Info/4 IKE/0x6300004B
Discarding IKE SA negotiation (I_Cookie=4FACA0813566C9D2 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

89 22:13:34.037 11/15/09 Sev=Info/4 CM/0x63100014
Unable to establish Phase 1 SA with server "206.19.211.141" because of "DEL_REASON_PEER_NOT_RESPONDING"

90 22:13:34.037 11/15/09 Sev=Info/5 CM/0x63100025
Initializing CVPNDrv

91 22:13:34.057 11/15/09 Sev=Info/6 CM/0x63100046
Set tunnel established flag in registry to 0.

92 22:13:34.057 11/15/09 Sev=Info/4 IKE/0x63000001
IKE received signal to terminate VPN connection

93 22:13:34.539 11/15/09 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

94 22:13:34.539 11/15/09 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

95 22:13:34.539 11/15/09 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

96 22:13:34.539 11/15/09 Sev=Info/4 IPSEC/0x6370000A
IPSec driver successfully stopped

Nov 15 20:13:06 2009       Connection Accepted       TCP 192.168.0.35:54444->209.46.39.47:443 on ixp1
Nov 15 20:13:11 2009       Connection Accepted       UDP 192.168.0.35:52051->206.19.211.141:500 on ixp1
Nov 15 20:13:11 2009       Connection Accepted       UDP 192.168.0.35:52051->206.19.211.141:500 on ixp1
Nov 15 20:13:20 2009       Connection Accepted       TCP 192.168.0.35:54446->205.203.132.65:80 on ixp1
Nov 15 20:13:28 2009       Connection Accepted       UDP 192.168.0.35:36819->75.68.220.131:57878 on ixp1
Nov 15 20:13:32 2009       Connection Accepted       UDP 73.237.44.1:67->255.255.255.255:68 on ixp1
Nov 15 20:13:34 2009       Connection Accepted       UDP 73.237.44.1:67->255.255.255.255:68 on ixp1
Nov 15 20:13:34 2009       Connection Accepted       UDP 73.237.44.1:67->255.255.255.255:68 on ixp1
Nov 15 20:13:35 2009       Connection Refused - Policy violation       UDP 71.114.236.161:58927->24.245.32.25:58927 on ixp1
Nov 15 20:13:35 2009       Connection Refused - Policy violation       UDP 71.114.236.161:58927->24.245.32.25:58927 on ixp1
Nov 15 20:13:42 2009       Connection Accepted       ICMP type 8 code 0 24.245.32.25->24.245.32.1 on ixp1
Nov 15 20:13:43 2009       Connection Refused - Policy violation       UDP 71.114.236.161:58927->24.245.32.25:58927 on ixp1
Nov 15 20:13:54 2009       Connection Accepted       IGMP 73.237.44.1->224.0.0.1 on ixp1

Alejandro Gallego · ‎11-15-2009

Are all your loggin options turned on?

Even if the FW absorbs UDP500 it should still show in the log. Have you checked to see if you are being NATd by your ISP, or if they have any blocks on port 500 and/or IPSec protocol 50? I don not really think the router is actually hijacking the conversation as QVPN tunnels are initiated by a SSL connection. Since that is not happening I really do not think the router is grabbing the ISAKMP reply, especially as it is originating from inside. Could be wrong though.

jrhelgeson · ‎11-16-2009

The issue here is a known issue on the PIX firewalls, which is Port Address Translation on the interface that is used to listen for udp 500 isakmp handshakes.

They created the "fixup protocol esp-ike" in order to take care of this problem.

This is the same exact issue revisited on the RV042.

I did a packet capture in order to figure out the problem on the PIX, it is the same exact problem on the RV042. If you have access to an RV042 in your lab, you will be able to immediately recreate this issue.

Alejandro Gallego · ‎11-16-2009

unfortunately I do not have access to a PIX or ASA but I will come up with something to at least mimic the connection. Give a day or so.

jean-eric · ‎03-23-2010

hello,

I have exactly the same issue on a RV082. did you get a solution?

Regards

JEZ

David Hornstein · ‎03-23-2010

Hi all

I am using a RV042 at home. I am using my Cisco Easy VPN client to access the Cisco network and hence get to this community site. See my screen shot below.

For grins and giggles, I wonder what would happen if ;

1. you went to the setup tab of your RV042 management interface and set the DMZ address to your PC's IP address ?

Did it let you create a IPSEC tunnel from your PC behind the LAN and out through the WAN ?

2. You have had some great ideas in logging errors.

interesting that comments in the client VPN logs, almost seems to indicate that the remote VPN gateway is ignoring your request...hmmm gotta think about that.

3. But the bottom line is that VPN PASS-THRU IS WORKING

My RV042 uses the same software version as your RV042. My RV042 is connected to a Motorola Surfboard SB4100 cable modem that bridges publically accessable IP addresses.

4. What about using the same VPN client as me, Cisco Systems VPN Client Version 5.0.05.0290. When I tried using the latest and the best client that you have, my information technology folks that look after my PC software, made me use this older code, even though the newer code was available. It's worth a try :-)

5. What is the RV042 connected to, is the connected CPE device in bridging or routing mode?

What is the model and maybe if you have access to it, the software version of the cpe device the RV042 plugs into ?

If you by-pass the router and directly connect on the edge CPE device, can you VPN to work ?

regards Dave

ps... sorry you may have to download the attached jpeg to see my screen shot.

jrhelgeson · ‎03-24-2010

"3. But the bottom line is that VPN PASS-THRU IS WORKING"

I'm sure it is working - for you...

Of course I set the PC IP as the DMZ. Of course I set the IPSEC pass-through.

The answer to the problem lies in your point #2. My traffic is hitting the remote PIX firewall, and the firewall is sending traffic back to ME on UDP/500 ISAKMP - which is BEING ANSWERED BY THE RV042 rather than being forwarded inbound to my computer.

Yes, if I take the RV042 out of the loop, the VPN works great. I used to have this problem when setting up interface PAT on the Cisco Pix 515 when I worked for Cisco Security team... until Cisco introduced the fixup command to work around that problem.

When you connect into the Cisco network via the VPN - you are connecting to a VPN concentrator that will try multiple ports, methods and techniques to establish and carry out the Phase1 negotiations... but I am not connecting to a VPN Concentrator, I'm connecting to a PIX firewall...

So Until Cisco wakes up and fixes this issue, the RV041 has been removed from service...

Has anyone submitted a ticket on this issue yet?

Joel Helgeson

David Hornstein · ‎03-24-2010

Hi Joel,

Unless I'm suffering from "domestic blindness, " I cannot see within the captures, a response from the PIX firwall.

I can see your client going to the PIX, but no response from the PIX firwall.

The first thing that comes to mind is that there may be a NAT-T issue between the PC client and the PIX 501.

As you probably appreciate a IPSec access concentrator, and it doesn't matter if it's my coporate VPN access concentrator or your PIX501 will dump or ignore a ISAKMP or IPSec stream that it thinks is being spoofed.

I reckon from what you have been suggesting, and the limited RV042 logs available, that your PIX 501 is not responding to your client. It could be NAT-T related.

You might be better off checking the NetPro database that shows a lot more queries on PIX 501 issues.

Check out www.cisco.com/go/netpro

There may be a more related topic at Netpro at https://supportforums.cisco.com/message/1324925#1324925

regards Dave

jrhelgeson · ‎03-24-2010

"I can see your client going to the PIX, but no response from the PIX firwall."

That, my friend, is precisely my point!

The PIX DOES send a reply, but that REPLY is answered by the RV041 and is never forwarded inbound to my host PC. This was verified by doing a packet capture in front of the firewall, and behind the firewall... You see the PIX reply going to the firewall, but it does not get sent to the device...

The firewall just drops it, because it is a response to a key exchange that the RV041 never requested, It's like getting an ACK packet when you never sent out a SYN...

Joel