By the way that firewall config POSTROUTING line I've tried with '-i eth0', '-o eth0' and without any -i/-o eth0 with same results.
Apologies for the delayed response; our forum notifications were not working.
Your firewall configuration is correct, although it will only allow connectivity to 188.8.131.52/8 from the 10.100.1.21 host; not the entire 10.100.1.0/24 subnet. It sounds like that's the host you're testing with, so that's fine for now.
My first thought would be to double check that source/destination checking is disabled (that's AWS terminology; Azure has a toggle to enable "IP Forwarding", and other clouds have their own wording.)
If that's not the issue, I would want to take a firsthand look at your configuration and the behavior. In that case I would ask that you open a support ticket or email us at email@example.com in order to continue the conversation.
Hello. I have the same problem. My VNS is working fine, but when we not expect, we dont receive bytes and the value "bytes in:0", and "bytes out: xxxxx" ...we don understand what's happen, the logs don't said some specific. The only way to restore the "bytes in" is restarting the tunnel. This situation begin since 2 weeks, the other side peer said us that your peer is ok and the only peer that is present failure is our peer.
I'm trying to create a working tunnel to a (large) customers infrastructure (I believe they're using Cisco ASA). They have been sent me all standard Ipsec tunnel Phase1 & 2 configs and our tunnel establishes an SA with them. This client requires us to use a public ip encryption domain and we've used the AWS "unattached Elastic IP trick" and the forwarding rules adapted to our situation (we are not using an overlay network). Our public encryption domain/eip is 3.xxx.xxx.167and our internal network is VPC 10.100.0.0/16, VNS3 subnet 10.100.3.166/24, destination host for tunnel traffic subnet 10.100.1.21/24.
Setting a ping up from the 10.100.1.21 host to a host in the remote encryption domain (184.108.40.206/8) we can see on the VNS3 (again tunnel shows up) bytes out increasing. Our client says they see the ping round-tripping on their ASA. A VNS3 sniffer trace on the ipsec endpoint shows the ping traffic going to AND RECEIVING FROM the clients public ipsec address (it stops both ways when we stop the ping)
But again, the ping does not return to the host and, since I don't know how to monitor the PREROUTING_CUST and POSTROUTING_CUST rules, or do a simple check of pinging our box from the VNS3 appliance to check connectivity, I'm stuck. By the way all other boxes in the 10.100.1.x and 10.100.3.x subnets can ping the box (10.100.1.21) trying to ping across the tunnel.
The rules sending the packets out must be correct (at least one way) or they wouldn't be getting to the other side of the tunnel unless they were right. Here they are by the way:
I haven't included all of the ipsec Phase 1 and Phase2 params because connectivity and logs all indicate these are correct.