Site to Site VPN using RV160-RV130W-RV132W routers

[aalexioy]

Hi 

I have three sites connected with RV routers.

Site A 192.168.2.0/24 with router RV132W is connected with site to site VPN to site B

Site B 192.168.0.0/24 with router RV160 is connected with site to site VPN to site A and C

Site C 192.168.1.0/24 with router RV130W is connected with site to site VPN to site B

The issue is that site B can talk with site A and C but sites A and C cannot communicate with each other through B.

There is no routing though VPN to the RV routers . Does anyone knows if this function is supported by the routers and if yes how i can enable it? If no if there any walkaround for this issue?

VPN passthrough is enabled and static routes do not work as the VPN tunnel is not listed as a connection , only WAN and LAN are listed.

Thank you!

[nagrajk1969]

Hi

Your vpn deployment requirement is a classic/standard Hub-and-Spoke VPN Topology in which spoke-to-spoke traffic will be routed in the ipsec tunnels via the HubGw (which is RV160 in this case). Please refer to the attached schematic of the required vpn topology that you will need to configure

Please find attached the sample (but required) S2S VPN Tunnel configurationsce t you will need to apply on each of the Site-A/B/C routers

- It should solve your issue of traffic between the siteA<>SiteC via SiteB  thru the ipsec-vpn tunnels established

Please Note: 

1. Since these are "Spoke-Gws", i have assumed that the wan-ipaddresses on both RV13X-routers (siteA and siteC) are "Dynamic-IPaddresses : configured using DHCP or PPPoE"

2. Also, i have assumed that both these Spoke-Gws - siteA-router and SiteC-router "maybe" connected behind some NAT-router of ISP...meaning that their wan-ipaddresses will be NATed to some public-ipaddresses. So this would mean that the ipsec tunnels would be using NAT-T...and hence the need to use/enable "Aggressive Mode" for these IKEv1-based tunnels

3. Therefore considering point-1 and point-2 above,

a) i have configured on RV160 for both S2S tunnels, the "Remote-Endpoint: Dynamic-IP", which makes this a Passive Gw. So in this case for the ipsec tunnels to be established, always send/initiate traffic from hosts behind Site-A and/or Site-C routers

4. In case AND ONLY in case point-1 and/or point-2 above are not the applicable in your deployment, you may then configure on RV160/HubGw as below:  

a) for tunnel-1 to Site-A

- Remote-Endpoint: Static-IP: <the public ipaddress of the siteA-router wan-interface>

- And in advanced-settings, you can now enable "Keepalive" too

a) for tunnel-2 to Site-C

- Remote-Endpoint: Static-IP: <the public ipaddress of the siteC-router wan-interface>

- And in advanced-settings, you can now enable "Keepalive" too

- all other settings/options selected/applied remain the same as in attached docs for both tunnels

Note: These configs for this hub-spoke topology are applicable to/on any IPsec-Peer-Gw/router not just RV-routers

Additional Note: DO NOT ADD ANY MANUAL ACL/PORT-FORWARD OR ANY RULES IN THE FIREWALL SECTION OF RV160. All the required firewall rules to allow/forward/nat-bypass for VPN tunnels/IPsec tunnels get automatically applied by the system implicitly in the background....you dont need to add any permit/bypass/port-forward rules for ipsec/vpn....AGAIN, DO NOT ADD ANY EXPLICIT/MANUAL FIREWALL RULES/ACLs..ON RV160

[aalexioy]

Hi nagrajk 

Thanks for the detailed how to great work. Most of the configuration you suggested is the same as mine .

But the router does not let me change to any /0.0.0.0 as you can see in the below print screen.

Do you have any other idea ?

Thanks again for you kindness for answering my question.

[nagrajk1969]

please mention which "router"?...iam thinking its RV130/132...???

1. You have selected "single"...which is incorrect

Expand the dropdown list and i think you will see "Subnet" and maybe "Any" too

2. If you dont see "Any", then select "Subnet" and give below values:

Ip Address: 0.0.0.0

Subnet Mask: 0.0.0.0

- the above represents ALL networks/destinations

Note: enter value as above...dont give value of 255.255.255.255 for subnet-mask

Note: IF it does not allow you to enter value of 0.0.0.0 for ipaddr-subnet & 0.0.0.0 for mask, then its a bug in RV130/132...and then we have to think some other method...

Try selecting "Any" if present in dropdown list, else try the point2 with selecting subnet

[Kasun Bandara]

Hi,

i had a same kind of issue when using default routes via VPNs in RV series. we cannot use 0.0.0.0/0 in routing and had to use specific routes for each subnet. we used subnet 128 by dividing to two networks.

Good luck

KB

[nagrajk1969]

Hi

Alex:

Sorry i missed seeing both the screenshots you had posted in your message earlier.(mobile phones are not good for viewing messages)..and i went ahead and suggested the same config which you have already tried..sorry again

So ok its a bug in these older RV routers

Kasun:

Thanks yes it seems the older RV routers dont support configuration of ipsec traffic-selector of 0.0.0.0/0.0.0.0....

But FYI, all the new RV160/260/340/345 routers series support ANY(0.0.0.0/0)...

Alex: In this case we need to try a different method to deploy the hub-spoke vpn tunnels in your setup

a) Can you confirm whether we can create network/ip-subnet group objects on RV130/132???

And more importantly,

b) Can we (after creating the network-groups) select these groups in the s2s tunnel configs for Remote-Traffic-Selectors on RV130/132???

Is there another option for ip-groups in the dropdown list?(other than single/subnet)

Note:FYI on the newer RV160/260/34X routers we can

[nagrajk1969]

Hi

I dont whether this would be supported on the RV130/132 routers (it is supported on the newer RV-series routers):

Alternatively, meanwhile, you could try with below changes in the sample configs i had sent earlier and which you have already applied as such

1. On-SiteA/RV130 router

a) Keep all configs as earlier for the tunnel to siteB/Hubgw, and

b) In the remote traffic selector give the below values

subnet:192.168.0.0

mask: 255.255.0.0

2. And on SiteC-RV132 router too

in the remote traffic selector, give the below:

subnet:192.168.0.0

mask: 255.255.0.0

3. On RV160

For each s2s tunnel, keep the existing configs as it is, and additionally change for Local-traffic selector from ANY to below:

Local subnet: 192.168.0.0

Mask: 255.255.0.0

Basically we are using "summarized" network/subnet in the respective traffic selector on each of the routers... hopefully this should work

[aalexioy]

Hi again 

your help is priceless thanks again for your time. i have made the changes and it works with 255.255.0.0 sub for the B site connection.

But after that i am experiencing a very strange issue the site A and B are working fine the site C with the RV130W router when the tunnel is up even if it's not connected i am loosing connectivity with the router when i am connected to the local lan 192.168.1.0/24 but the strange think is when the tunnel is up from  the local lan 192.168.1.0/24 i am still not able to ping or connect to the router 192.168.1.1but if i am at the site B 192.168.0.0/24 i can connect fine to the router 192.168.1.1 . The issue is that the router is working fine but locally i am not able to reach it. if the tunnel is disabled everything works fine. i think when the tunnel is enable the 192.168.1.1 traffic it gets rejected for some reason . I think is a bug inside the router firmware. If you have any idea why only this is happening to one router please share. also i have factory reset the router and reconfigure it manually just in case but the behavior remain the same. 

Thank once more for you time and great help!

[nagrajk1969]

Hi

>>>i think when the tunnel is enable the 192.168.1.1 traffic it gets rejected for some reason

>>>I think is a bug inside the router firmware.

1. I was expecting that this "may" happen (or rather would happen if there is no fix) when i suggested that you should use the summarized-subnet "192.168.0.0/255.255.0.0" in the vpn tunnel configs on each of the routers

- BUT i was hoping with fingers-crossed that this behavior "maybe" would have been fixed or not present in RV130/132 routers

- BUT i did not mention about this repurcussion before-hand becos i had to confirm that this may happen on the RV130/132 routers. Which you have now confirmed that this issue is definitely occuring

2. Yes it is a "bug" in the RV130/132 routers for sure.

Note: Its not an issue with RV160 though becos it has the required fixes/additional-configs that solves this problem of using summarized-subnets as traffic-selectors in vpn tunnels

3. Its not really a "bug" as in "bug", its actually a scenario in which there is a need to additionally add a "bypass-ipsec rule for local-subnet-to-local-subnet traffic"  

a) You see say consider siteA-router:

lan-host/192.168.1.2----192.168.1.1[RV130]=====ipsec-tunnel===[RV160]

- now on this RV130 you have the ipsec tunnel policy configured as below:

192.168.1.0/24<>192.168.0.0/16 : Protect IPsec

- So when you ping from 192.168.1.2 to 192.168.1.1, whats happening is that this is ping-packet with destination 192.168.1.1 is matching the above ipsec policy to the destination-traffic-selector which is a summarized-subnet 192.168.0.0/16 (and 192.168.1.1 falls into this..eventhough its supposed to be directly-connected) 

- and therefore this ping packet is being forwarded across the active ipsec tunnel upto the RV160...where it is dropped after decryption which is to be expected becos there is NO 192.168.1.1 destination on RV160...

b) This is a not a bug in the true-sense becos this is "routing" behavior and happens when you have vpn tunnel with a remote-destination traffic-selector that is a summarized-subnet of local-network-traffic-selector....

c) So generally the "fix" or the solution to these kind of scenarios where you may need to use summarized-subnets in the vpn-tunnels is to ensure that a "bypass-ipsec-for-local-subnet-to-local-subnet traffic" rule is added in the ipsec-policy alongwith the above policy

- this bypass policy would be something like below (it means - dont apply ipsec to traffic that is within the local-subnet:

192.168.1.0/24<>192.168.1.0/24: Bypass-IPsec

d) So in case of RV130/132, the automatic applying of the required bypass-ipsec rule/configuration is not being added on these routers in this specific vpn tunneling scenario (using summarized-subnets). Hence its a bug on these routers

e) And another point is that even in case, on RV130/132, if the subnet "ANY(0.0.0.0/0.0.0.0)" was allowed to be used, the same issue would have happened becos on these routers the bypass-ipsec/passthrough ipsec-policies/rules are NOT being added...so its a overall problem on RV130/132

4. So now to solve this issue in your network deployment, another config method needs to be applied - provided ofcourse it is supported on RV130/132

(Note: it is working on RV160/260/34X routers though as seen in attached screenshot of the config that i tried and it works on RV160/260/34X) 

So can you kindly please try applying the below configs on each of the specified routers?

1. On-SiteA/RV130 router

a) Keep all configs as earlier for the tunnel to siteB/Hubgw, and

b) In the remote traffic selector give the below values

subnet:128.0.0.0

mask: 128.0.0.0

2. And on SiteC-RV132 router too

in the remote traffic selector, give the below:

subnet:128.0.0.0

mask: 128.0.0.0

3. On RV160

For each s2s tunnel, keep the existing configs as it is, and additionally change for Local-traffic selector from 192.168.0.0/16 to below:

Local subnet: 128.0.0.0

Mask: 128.0.0.0

Hopefully this above updated config should solve and fix the issues observed by you

best wishes

[nagrajk1969]

Hi

just a heads up, on further tests done using similar configs - use of subnet "128.0.0.0/128.0.0.0", on some other non-RV linux-based routers, iam observing that without the "bypass-ipsec-for-local-subnets" policy-rule applied, there is a similar problem of accessing the router itself from its lan-subnet interface......so i dont know, i guess it "may not" work using 128.0.0.0/128.0.0.0 subnet values too...on RV130/132...

But try it anyways and check the behavior after all tunnels are up. we dont know, maybe it will work on the RV130/132 with the new configs applied

thanks