RV340 Site-to-Site VPN with Edge Gateway

[VyacheslavTuchkov94367]

Hello

There is a Cisco RV340 router with the following networks behind it:

- 192.168.1.1

- 192.168.88.1

- 10.36.1.1

Several more networks are planned to be added in the future.

And there is VMware NSX Edge Gateway, with networks behind it:

- 10.222.1.1

- 10.222.2.1

Network groups created on RV340:

- VPN_VRN_Net, which includes all networks connected to the router

- VPN_QAZ_Net, which includes the networks behind the Edge Gateway

IPSec profile created:

IKE Version: IKEv2

Phase 1:

DH Group: 14

Encryption: AES - 256

Autentication: SHA - 1

SA Lifetime: 28800

Phase 2:

Protocol: ESP

Encryption: AES - 256

Autentication: SHA - 1

SA Lifetime: 3600

PFS: Enable

DH Group: 14

Tunnel settings on RV340 are shown in screenshots StS VPN_1 and StS VPN_2

Tunnel settings for NSX Edge:

# Configuration for IPsec VPN connection

#

# Peer NSX Edge and IPSec Site configuration details.

#

# IPsec site Id: ipsecsite-172

# IPsec site name: QAZ-VRN23

# IPsec site description:

# IPsec site enabled: true

# IPsec site vpn type: Policy based VPN

# NSX Edge Id: edge-40

# Feature version: 11

# Time stamp: 051521_194518ALMT

#

# Internet Key Exchange Configuration

# Phase 1

# Configure the IKE SA as outlined below

IKE version: ikev2

Connection initiation mode: initiator

Authentication method: psk

Pre shared key: xxxxxxxxxxxx

Authentication algorithm: sha1

Encryption algorithm: aes256

SA life time: 28800 seconds

Phase 1 negotiation mode: Not applicable for ikev2

DH group: DH14

# IPsec_configuration

# Phase 2

# Configure the IPsec SA as outlined below

Protocol: ESP

Authentication algorithm: sha1

Sa life time: 3600 seconds

Encryption algorithm: aes256

Encapsulation mode: Tunnel mode

Enable perfect forward secrecy: false

Perfect forward secrecy DH group: Not Applicable

# Peer configuration

Peer address: 185.102.72.161 # Peer gateway public IP.

Peer id: 185.102.72.161

Peer subnets: [10.222.0.0/16]

# IPsec Dead Peer Detection (DPD) settings

DPD enabled: true

DPD interval: 30 seconds

DPD timeout: 150 seconds

# Local configuration

Local address: 188.235.1.195 # Local gateway public IP.

Local id: 188.235.1.195

Local subnets: [192.168.0.0/16,10.36.0.0/16]

Tried using both network groups and / 16 subnet masks. The result is the same: only one subnet is connected from the side of the router, others have the error "IPSec-SA Proposals or Traffic Selectors did not match". Edge screenshot - vpn_eror.

Is it possible to get VPN to work with different types of networks? Could it be that the RV340 does not support such a configuration?

[nagrajk1969]

Hi

I see 2 things that needed to be checked 

1. On VMWare Edge-Gw, the the below is the settings 

------------------------------------------------------

# Peer configuration

Peer address: 185.102.72.161 # Peer gateway public IP.

Peer id: 185.102.72.161

Peer subnets: [10.222.0.0/16]

# Local configuration

Local address: 188.235.1.195 # Local gateway public IP.

Local id: 188.235.1.195

Local subnets: [192.168.0.0/16,10.36.0.0/16]

--------------------------------------------

For VMWare-edge, peer is the RV340 with wan-ipaddress 188.235.1.195, but it seems the subnets of RV340 are configured as Local-subnets

- The same with the subnets for VMware which are Local but configured as Peer...

- shouldnt this config be turned around...its quite confusing...

2. If no the above is some error done while copy/pasting the config here...then the next point to note is

a) In the IPsec-Profile on RV340, the Phase-2 PFS is enable, whereas its disabled on VMWare-Edge

b) So please disable PFS on RV340 or enable PFS on VMWare either of the 2 should be done

3. And in case you still see a problem, an additional step that you should try on RV340 only is to disable/uncheck the "Non-RFC" settings....maybe VMware-Edge does support RFC-standards for IKEv2 negotiation...so...try it out...only after checking with points-1 and 2 above

Nothing so critical...its just some teething problems and initial config hiccups...nothing wrong with either RV340 and/or Vmware-Edge...

[nagrajk1969]

also enable DPD on RV340 with 30/150/clear values...it helps (as its also configured on VMware)

[VyacheslavTuchkov94367]

Hello

PFS and Non-RFC disabled, at the moment the tunnel is still preserved. But the problem with the fact that only one subnet is connected behind the router remains. Moreover, if you restart the VPN, another subnet can connect, and the first one will be with the same error: "IPSec-SA Proposals or Traffic Selectors did not match".

I also noticed that if you specify only one network for the RV340, then the tunnel is established in 100% of cases.

The reason why the rest of the networks are not connected, even with the / 16 or / 24 mask, could not be identified

[nagrajk1969]

Hi

1. After you have disabled the PFS in the ipsec-profile on RV340, and apply-save, please go to S2S tunnel page and edit the S2S tunnel entry .

- And then in the Basic settings page, simply once uncheck the "Enable" checkbox, click on Apply for sure...and then re-edit the S2S tunnel entry again AND now this time, check/enable the "Enable" check box of this S2S tunnel...on then the changes in the ipsec-profile will get "Re-Applied" to the S2S tunnel config...

2. Secondly i would suggest that you continue to enable the "Non-RFC" setting in the RV340.

- keep this enabled for now.

-I had mentioned in my earlier post that this should be disabled ONLY if its still NOT working AFTER doing the things pointed out in Point-1 and Point-2.

3. By the way whats the status/info on the checks mentioned in Point-1 above??...is the config on VMware-edge interchanged?

4. Can you clarify with details as to how the below networks are connected to RV340?

192.168.88.1

10.36.1.1

- are these 2 subnets above directly configured on RV340 as 2 separate vlans? Or is it routed via another router connected to RV340?

- I can assume that 192.168.1.0/24 is the network vlan1 on RV340

5. Also are both wan1 and wan2 interfaces active on RV340 AND is the S2S tunnel on wan1 or wan2?

==================================================

I apologze sincerely, if iam asking too many questions to you without providing any or some concrete analysis of the issue at hand...believe me i have some things in mind that i suspect the issue is happening becos of...so if you can, please kindly bear with my questions and hopefully you will post the answers whenever you have the time  to do so...

thanks & best wishes

[VyacheslavTuchkov94367]

Hello

1. In the advanced settings, the following options were enabled (screenshot of tunnel_as):
- Non-RFC Compliant
- NetBIOS Broadcast
- Keep-Alive
- DPD Enable (Delay Time: 30, Detection Timeout: 150, Delay Action: Restart)

At the moment, both networks (192.168.0.0/16 and 10.36.0.0/16) behind the RV340 are connected to the / 16 Edge Gateway network.

2. In the VPN tunnel settings on the Edge GW in the "Local Subnets" parameters, the networks behind the Edge are specified, in the "Peer Subnets" networks behind the remote VPN gateway (in this case, the RV340). You cannot change them.

3. Networks 192.168.1.0/24, 192.168.88.0/24, 10.36.1.0/24 are connected as separate VLANs. You are right, the 192.168.1.0/24 Network is VLAN1 (vlan screenshot)

4. Connection goes only through WAN1.

WAN2 is not connected to any network (screenshot wan)

[nagrajk1969]

Hi Vyacheslav

You must think i must have run-away after asking so many questions and making you go thru the effort of answering my queries

Sorry for the delayed response, iam actually been running some tests by configuring a similar scenario in my setup (with RV340). I dont have a Edge-Gateway, so iam testing with other interoperable peers (such as a Cisco-ISR/IOS router, and/or a Ubuntu-Linux-with-Strongswan peer gateway)

So a quick info/update to you is that i have been able to identify what exactly is the problem and where and why it is happening (the issue with only 1-subnet traffic working and the traffic for other subnet does not get forwarded..)

I will update you with my observations and suggestions in the next post....give me just another 30 minutes or so to collect the info and formulate a reply to you

thanks

[nagrajk1969]

Hi

Meanwhile, additionally, for you to clearly understand whats happening and why...i would like to request you to do the below if its possible in your deployment...atleast the point-2 will rellay help for your understanding of the cause of the issue observed..

 1. On the RV340, enable/configure the sending of the logs to a "Syslog server" (preferably one whicy runs on a Ubuntu-Linux/Linux) on the lan-network of RV340

- and on the syslog server, run the command in the command-prompt - "tail -f /var/log/syslog" to see the logs being sent by RV340 when the ipsec tunnel is being established

- pay attention and note down the logs for "Child-SA...established..." messages so that you will note down what are ipsec-SAs formed and what are the SPI numbers in each direction (outbound marked by "xxx_o" and inbound "yyyy_i)...

2. Setup a wireshark pc on the wan-side of RV340 to capture the ESP traffic flowing from and to the wan1 interface of RV340

- here you will need to check the SPI numbers of the ESP packets flowing "from" the WAN1 to remote peer, and "to" the wan1 from the remote peer 

===========================

From what i observe from my checks

1. Say a ping sent from 192.168.1.x to 10.222.1.x will be reaching 10.222.1.x..but the reply packet from 10.222.1.x will be reaching RV340 and IT WILL BE DROPPED AND NOT FORWARDED TO THE 192.168.1.X host that sent the ping-request

2. But at the same time, a ping sent from 10.36.1.x to 10.222.1.x (or 10.222.2.x) will be working correctly and you will be recieving the ping reply packets...from 10.222.1.x to 10.36.1.x...this will not be dropped...

[nagrajk1969]

Hello Vyacheslav

Ok my observations from the tests i did in my setup are as below:

Here iam assuming that there will be NO change in the configuration that is applied on the Edge-Gateway (remote-peer) and that it will continue to remain as it is shown in your earlier posts...so keep the existing config on Edge-Gateway as it is.

Scenario-1:

1. On RV340, you have configured the Local-IP Group as below (either of the config below can be used)

VPN_VRN_Net:

192.168.1.0/24

10.36.1.0/24

OR you could have configured as below too

VPN_VRN_Net:

192.168.0.0/16

10.36.0.0/16

2. In the advanced S2S tunnel config page, you have enabled/checked the setting/option "Non-RFC" 

3. So in this scenario-1, what i have observed in my tests/checks is 

a) the IPsec tunnel is established and on RV340, there are 2 "Child-SA-pairs" established for this tunnel to Edge-Gateway. You can see this from the syslogs

for example:

- child-SA pair-1 will be with the below parameters:

 192.168.1.0/24 <> 10.222.0.0/16

spi-outbound: "0xAAAA_o"

spi-inbound: "0xBBBB_i"

- child-SA pair-2 will be with below parameters:

10.36.1.0/24 <> 10.222.0.0/16

spi-outbound: "0xCCCC_o"

spi-inbound: "0xDDDD_i"

b) So whats happening is Ping traffic sent from a lan-host 192.168.1.10 to 10.222.1.10 is going thru the ipsec tunnel, but if you capture the ESP packets on the wan-side of RV340, it is observed that

- ESP-packet sent from RV340 to Edge-gateway is using SPI-out "0xAAAA_o"

- And the ESP-packet sent from Edge-Gateway (and this will contain the ping-reply) to RV340 is using SPI-inbound "0xDDDD_i" instead of "0xBBBB_i"

- so after decrypting the packet there is always a check done by ipsec engine to check the matching policy binded to the SPI-inbound...and here it sees that the destination ipaddress is 192.168.1.x, which does not match with the configured subnet for this spi-inbound 10.36.1.x...therefore the ping reply is getting dropped

b) Now at the same time, concurrently, for Ping sent from 10.36.1.x to 10.222.1.x, the below is happening correctly

- ESP packet sent from RV340 is using the SPI-outbound "0xCCCC_o"

- And the ESP packet sent by Edge-Gateway (containing the ping reply) is correctly using the SPI-inbound "0xDDDD_i"

- and therefore the ping traffic from the second subnet of RV340 is working correctly via the ipsec tunnel between RV340/Edge-Gw

...and so on for other traffic types too, which i checked (udp-bidirectional, tcp). Its the same behavior

continued in next post....

[nagrajk1969]

...continued...

Scenario-2:

1. On RV340, you have configured the Local-IP Group as below (either of the config below can be used)

VPN_VRN_Net:

192.168.1.0/24

10.36.1.0/24

OR you could have configured as below too

VPN_VRN_Net:

192.168.0.0/16

10.36.0.0/16

2. In the advanced S2S tunnel config page, you have DISABLED the setting/option "Non-RFC" 

3. So in this scenario-2, what i have observed in my tests/checks is 

a) the IPsec tunnel is established and on RV340, there is only 1 "Child-SA-pairs" established for this tunnel to Edge-Gateway. You can see this from the syslogs

for example:

- child-SA pair will be with the below parameters:

 192.168.1.0/24, 10.36.1.0/24 <> 10.222.0.0/16

spi-outbound: "0xAAAA_o"

spi-inbound: "0xBBBB_i"

b) In this scenario-2, there are no issues at all...all traffic from all subnets are working correctly

====================================

So in summary, from my observations, you should try the scenario-2 and disable "non-rfc" on RV340 and apply-save and check

thanks