I have an ipsec tunnel set up that connects to an AWS VPC subnet. The subnet has an instance running in it with the ip address 192.168.150.12. I eventually want to configure this instance to route traffic from our office to another AWS subnet, 172.22.0.0/24, but have not done that yet.
If I configure the tunnel from our office to only route traffic for 192.168.150.0/24, it works and I can connect to 192.168.150.12. If I add as a secondary remote network 172.22.0.0/24 to the ipsec tunnel config and restart it, I’m now unable to connect to 192.168.150.12 at all, using the same method (SSH). I’ve triple checked everything on the 192.168.150.12 instance to make sure the routes and firewall aren’t interfering, but really the only difference is the reconfiguration of the ipsec tunnel on the balance router with the secondary remote network.
For the record, this is a Peplink Balance 210, although I don’t know that that matters. Is there any reason I’m seeing this behaviour?
I did a bit more testing with tcpdump and discovered that with the secondary route configured in the ipsec tunnel, I can see packets arriving in the remote host (192.168.150.12), and responses being sent back but they aren’t arriving at the computer from which I’m initiating the connection. If I disable the secondary network route and re-run the test, I now see responses arriving back at the initiating computer.
That’s a guide that also contains the configuration settings specific to our AWS VPN. It’s made available as a download once you configure the VPN connection within AWS. This documentation describes it in more detail: What is AWS Site-to-Site VPN? - AWS Site-to-Site VPN
Can you please provide the screenshots for the defined IPSEC settings (AWS) for us to further check ? This will help us to understand what are the settings defined in AWS.
The given configuration file doesn’t seem to include the IPSEC configuration info that we need to compare.
I’m honestly not sure what else I can give you. I can’t screenshot the settings on the AWS side as they aren’t displayed in the console, they’re in the config file that I already attached above. But for the sake of clarity, here they are extracted from the file:
Additional:
TCP MSS Adjustment: 1387 bytes
Clear Don’t Fragment Bit: enabled
Fragmentation: Before encryption
The settings I’m using on my side are shown in the balance screenshot I supplied in my initial post. I should mention that despite what the config file settings above show, AWS VPNs do actually support AES-256 and SHA256 during phase 1, but only AES-256 and SHA1 during phase 2.
The above AWS IPSEC configuration doesn’t include the route propagation for the IPSEC tunnel.
I strongly believe that the route propagation is not properly define for the AWS. For more information, please refer to the attached URL.
Static routing require for the IPSEC tunnel to route the corresponding network traffics. Can you please check on that ? Possible please provide screenshot for the route propagation and we can further discuss what are the configuration is missing here.
As I mentioned originally though, everything works perfectly well when I only have 192.168.150.0/24 configured as a remote network on my Balance 210. I can connect to my instance inside the 192.168.150.0/24 network, no problems. It’s when I add 172.22.0.0/24 as a secondary remote network to the VPN config on the Balance that I can suddenly no longer connect to instances on the 192.168.150.0/24 network. If I then remove the additional remote networks on the Balance and just leave 192.168.150.0/24, it works fine again.
Guessing the VPN network/route (192.168.150.0/24 & 172.22.0.0/24) for AWS miss match with B210 configuration thus after you added in the 172.22.0.0/24 as a secondary remote network, traffics fail to pass-through the VPN tunnel.
May i know why 192.168.150.0/24 target as “Local” while 172.22.0.0/24 as other (eni-0c6da172) ? Do you contact with AWS support before to verify the require settings for routing multiple subnets for AWS ?
The reason 192.168.150.0/24 is marked as local is because that is the network range of the AWS VPC, the system automatically adds that to the route table when you create the VPC. I didn’t add it myself. I’ve actually since removed 172.22.0.0/24 from the route table entirely for now, just to confirm it’s not part of the problem. So now my route table for my AWS VPC looks like this:
However I still have this problem when I configure additional remote networks in my IPsec config in the B210. I just did a quick test with just the VPC subnet (192.168.150.0/24) configured in the tunnel and when I connect to 192.168.150.14 I can see using tcpdump the packets both arriving from and returning to 192.168.100.66, and I can also see via tcpdump, the packets arriving back at my laptop on IP 192.168.100.66.
If I then add 172.22.0.0/24 as an additional remote network to the B210 tunnel config, I can still see exactly the same behaviour from tcpdump on 192.168.150.14 (packets both arriving from and returning to 192.168.100.66), but I cannot see any response traffic on my laptop 192.168.100.66 (and of course SSH doesn’t work any more).
So it seems like the traffic is still being seen by the remote instance and it’s trying to communicate back with me, but somewhere in between it’s being lost. Given that the routing config at the AWS end remains exactly the same between tests, I’m unsure how this could be caused by anything other than the B210 failing to handle the returning packets from 192.168.150.0/24 when the vpn tunnel is configured with additional remote networks, but I remain open to suggestions.
I haven’t yet contacted AWS for help but I will see what they have to say about it. In the meantime though, is there any way I can dig deeper into the B210 and try to see at a lower level what’s happening with the vpn tunnel traffic?
The routes (local and remote networks, including the subnet) between Balance 210 and AWS VPN connection must be identical.
Your IPsec settings on Balance 210 looks great. We have many succesful cases that establishing IPSec VPN with AWS. I suggest contact AWS and get advice on your current settings.
Ok, well I guess that answers it then. Unfortunately, I spoke to AWS and they confirmed that we cannot set up multiple routes at their end without using BGP, we can only have the one security association pair. So I’ll have to go back to the drawing board and try and find a different solution for this, maybe by connecting from the the B210 directly to the Strongswan instance in AWS.
Thanks for your help with this, it’s much appreciated!
