VSEC AWS traffic to/from local subnet

[Matthias_Hoppe]

My question is certainly easy to answer, but I cannot find the answer myself. I am not a starter with VSEC, and also not in AWS, but nevertheless it seems to be a newbee question.

Here is what we have: We have a VSEC installed in an AWS VPC. The VPC has several subnets. VSEC has interfaces in two of them:

- one public subnet - route table has the default route to the IGW - this is VSECs eth0

- on private subnet - route table has the default route to the ENI of the VSEC in this subnet -  this is VSECs eth1

All Security Groups and all NACLs allow any traffic.

VSECs setting for Source/Destination Check is "disabled".

VSEC is connected to our corporate network using VPN, which is running well. We can reach the VSECs IP-address in the private subnet from on-premise.

We additionally have an EC2 instance in the private subnet running an AWS Linux.

We try to reach this EC2 from on-premise without success. We see the packets run from on-premise via VSEC, which allows the traffic, and also see the traffic leaving VSEC on the correct interface eth1. But we do never see reply packets from EC2.

We also try to reach on-premis from EC2. Here we never see any packet arriving at the VSEC.

Connecting from VSEC to EC2 directly and vice versa is working well.

Does anybody have any ideas what I can check additionally?

Thanks in advance. Matthias Hoppe

[Naveen_Kumar]

Hi!, Please verify the route table associated with private subnet running an AWS Linux, from where you are trying to reach on on-premise network. On-premise network should be pointed towards vSec eth1 interface.

[Matthias_Hoppe]

Hi Naveen, thank you for your valuable answer. I think I already mentioned, that the route table is correct ("on private subnet - route table has the default route to the ENI of the VSEC in this subnet -  this is VSECs eth1")

[Matthias_Hoppe]

Hi guys, just yesterday late afternoon, I found the solution. I was not aware that "Source/Destination Check" cat be set not only for the EC2 but also for every single ENI on that EC2. And for the second interface (eth1) it was set to "True". Having disabled this, everything worked perfectly well.

Sorry for having bothered you with this question. I assumed that there was only one tiny setting missing but could not find it for some time...