Re: RV345P - multiple subnets in site-to-site VPN

train_wreck · ‎09-13-2017

We are in the process of testing out a new RV345P device to see if we can use it in a new location. We have an existing VPN configuration between 2 existing sites using 1921s and using certificate auth. I have successfully made the first S2S connection between the 1921 and the RV345P, shown below:

(1921) 192.168.222.0/28 --------- (RV345P) 192.168.128.0/29

The 1921 has 2 LANs configured on it, and I am trying to create the second phase 2 association for the 2nd subnet:

(1921) 192.168.168.0/27 --------- (RV345P) 192.168.128.0/29

However, when I try to add the 2nd S2S on the RV345P, I receive the following error:

So how do I add a 2nd subnet in the phase 2 association? Surely this is a feature of this device? Your Cisco RV042 device that was released nearly ten years ago can do this.....

I can provide sanitized configs if necessary.

train_wreck · ‎09-23-2017

Hello, anyone there?

Perhaps I was unclear: The RV345P has a VLAN subnet of 192.168.128.0/29, and the 1921 has 2 VLAN subnets 192.168.222.0/28 and 192.168.168.0/27. Both routers have host IP address of .1 in all their respective VLANs.

I create the first IPsec security association between the VLAN of the RV345P and the first VLAN of the 1921:

This tunnel comes up fine. I then go to add the second tunnel:

And the RV345P refuses to let me proceed. Apparently, according to the strange restrictions in the error message, I must install a separate certificate with a separate distinguished name just to add a second subnet to the phase 2 association. I cannot keep the same phase 1 with the same cert.

Am I missing something here? I am unaware of any other router which shares such a restriction. I realize that I could renumber the subnets on both sides to make them contiguous, after which I imagine the RV345P would accept the summarized subnets, but I'm sure you understand the relative insanity of going through all of that, just to work around this device's limitation.

What gives?

train_wreck · ‎10-17-2017

Been over a month, no replies.....

Hello??

crs101 · ‎11-03-2017

I have this same problem. We were able to do this fine on our old Netgear Prosafe boxes, I was thinking this is where we had to create a GRE tunnel but there is a bug in the firmware that will not allow you to create a GRE with two FQDN's, they have a support ticket for the GRE problem and tell me they are addressing it.

train_wreck · ‎11-04-2017

ah, good to see I'm not not the only one running into this. We also used the Netgear Prosafe series in some of our locations (specifically the FVS336G), but since Netgear killed off all of the FVS lines we're looking into other alternatives. While the original RV series from Cisco has a pretty bad rap, I was hoping the updated versions would be better... ironically this new series can't do what the old one could (multiple IPsec and GRE tunnels)..... goes to show why updates aren't always a good thing.

Would love an official response from someone, anyone at Cisco....

crs101 · ‎11-06-2017

Yeah Crickets from Cisco... I got this working temporarily with a GRE tunnel using my current IP's with RIP enabled. A few of my sites have DHCP addresses - so I hope they get the FQDN bug fixed soon, it would appear that they are in no hurry since the case finally got escalated a week later. As much as I loved to hate the Netgears they weren't that bad compared to these units - which seem cranky to say the least. I also think its pretty crappy you have to buy licenses to use their VPN client or even download the software where Netgear gave it freely. After spending 10K to upgrade all our sites to these they made me look really bad!

train_wreck · ‎11-06-2017

Wouldn't have to use a proprietary client, if the IPsec implementation was good....

crs101 · ‎11-10-2017

I was a fan of Netgear's rebranded Greeenbow client. I have 5 RV345s deployed and they are just so buggy, some connect to third party clients and others will just give cookie errors and refuse to work.

train_wreck · ‎11-10-2017

Yeah, Greenbow has been the most reliable 3rd-party VPN client I've used on the Windows platform. I've always had this conspiracy theory that the wretched state of most IPsec implementations is to push people into buying manufacturer proprietary VPN clients, since while IPsec is technically a standard (more a chain of standards patched together in numerous RFCs), it is very possible to find a combination of IPsec server/clients that simply do not interoperate.

(And like I said, I realize subnet summarization could be employed here to work around the issue of the topic, but in the real world networks are not always set up that way, particularly the smaller/SMB ones, and taking downtime for reconfiguration/testing can be costly. I realize the CCENT/CCNA both say it is "recommended", but there is certainly no technical reason why routers can have non-contiguous subnets, and the benefits of doing so are very slight in the small networks that the RV series is marketed to.)

crs101 · ‎11-10-2017

My latest issue is with greenbow, and even shrew not connecting to some of the RV34x's (client to site) and see another forum thread reporting the same problem (we have 12 RV320's deployed and no issues like I have the 34X's). These things are just so buggy! On a good note the GRE tunnel was easy enough and solved most of our issues... Occasionally the tunnel will drop and one side thinks it is still connected and has to be rebooted to get it re-established.

train_wreck · ‎11-10-2017

The unfortunate aspect of GRE is that not all routers support it, particularly in the RV series price range; I know the Netgears didn't, and numerous others from D-Link, TP-Link, et al. don't. And RE: the bugginess of these devices, one of the guys I work with said that the company trialed using the RV042/320 devices 5 or 6 years ago, and didn't move ahead with them due to many of the same kinds of issues mentioned; interoperability & configuration deficiencies and a troubling level of unreliability. Though to be fair, the Netgear FVS318G ranks as the most unreliable SMB router I have ever worked with..... in all honesty it was a good thing that Netgear EOL'd that line.

Curious, have you benchmarked performance of GRE tunnels in the RV series? Particularly between 2 RV34x?

ferdinando.alde · ‎08-06-2018

The curious thing is that on the RV325 the use of more than one subnet is perfectly permissible and configurable. I wonder why Cisco does not answer these questions and. above all, it does not prepare the correction of what appears to be a defect.
I find it a real lack of seriousness.

Isynth · ‎12-02-2018

Hallo,

I see that the initial post was one year ago.

Where you able to solve this issue.

I'm stuck in an RV340 in productive. Does that mean I can only use one subnet per l2l tunnel?

Thanks for the update.

ferdinando.alde · ‎12-02-2018

Yes. Nothing has changed. Cisco still does not deal with these routers, they just need to sell them. It's not a good behavior from a company that I thought was serious. It is necessary to change brand: I'm using an EdgeRouter and it's great.

train_wreck · ‎12-03-2018

@Isynth wrote:
Hallo,

I see that the initial post was one year ago.
Where you able to solve this issue.
I'm stuck in an RV340 in productive. Does that mean I can only use one subnet per l2l tunnel?

Thanks for the update.

No, I was never able to get this resolved, and my open ticket with Cisco support was immediately closed with a status of "unsupported".

We gave up and returned our device. There were other things it was sorely lacking (no IKEv2 or OpenVPN support??? in 2018?), as well as a bug that caused cert-based VPNs to send an ID type of "FQDN" even when "ASN1DN" was selected, causing interoperability problems with non-Cisco firewalls.

These things are junk. The throughput is high, but there are just too many unresolved problems, and Cisco seems not to care. We've moved on to using Fortigate UTMs (the 30E and the FortiWifi 50E devices blow these things out of the water, and offer much more capability).