Anyone using Site-to-Site VPN tunnel between XG 16 and Amazon AWS VPC?

Hi PG Tech,

That's some odd behaviour, would you be able to run a tcpdump and paste the results here? You will need to do this in the advanced shell so SSH to the box and use the admin login to get into the shell then you want Option 5 and Option 3 for the advanced shell. The command you want to run is "tcpdump -veni any host 10.30.1.97 and icmp" (without quotes) which will output all icmp traffic to the 10.30.1.97 host.

We're looking to see if the reply traffic even makes it back to the XG, because if it does then there could a be a problem elsewhere between the XG and your local client, but if it doesn't back to the XG then there may be a problem with the IPSEC tunnel.

Looking forward to your response!

Emile

Thank you Emile, here's the tcpdump.

Hi PG Tech,

So here's what I've matched below, I'm able to link up the majority of the ICMP echo requests with their replies and they are shown incoming on the ipsec tunnel and then are egressed to PortE5 to get to the source of 10.100.1.11.

However the two lines I've drawn extending out to the left show absolutely no reply on the same sequence coming in to the XG on the ipsec tunnel which leads me to believe you may have an issue with packets flowing in/out on the AWS VPC side of the connection. Can you run a wireshark/tcpdump on the host in the cloud to see if the echo requests are being received/being sent out of the host 10.30.1.97?

Emile

Thanks I saw the same thing but it just doesn't make any sense why it would ping several times and then drop a few. Very odd. I'm not sure how I can run tcpdump on the server at AWS. I will have to look into that.

Hi PG Tech,

There could be a possibility that the tunnel is unstable, in the advanced shell of the XG could you take a look/paste the output here of the following command "tail -f /log/ipsec.log" (without quotes).

This will show the raw output from the ipsec daemon and we can look out for any inconsistencies or potential issues that might represent an unstable tunnel.

Emile

That could be the issue.

That could be the issue.

Hi PG Tech,

That doesn't look fully healthy.

Could you share screenshots of the ipsec configuration on the XG as well as the VPC IPSEC connector config in AWS?

Emile

Amazon Web Services
Virtual Private Cloud

VPN Connection Configuration
================================================================================
AWS utilizes unique identifiers to manipulate the configuration of
a VPN Connection. Each VPN Connection is assigned a VPN Connection Identifier
and is associated with two other identifiers, namely the
Customer Gateway Identifier and the Virtual Private Gateway Identifier.

Your VPN Connection ID : vpn-xxxxxxx
Your Virtual Private Gateway ID : vgw-xxxxxxxx
Your Customer Gateway ID : cgw-xxxxxxx

A VPN Connection consists of a pair of IPSec tunnel security associations (SAs).
It is important that both tunnel security associations be configured.

IPSec Tunnel #1
================================================================================
#1: Internet Key Exchange Configuration

Configure the IKE SA as follows:
Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24.
The address of the external interface for your customer gateway must be a static address.
Your customer gateway may reside behind a device performing network address translation (NAT).
To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500. If not behind NAT, we recommend disabling NAT-T.
- Authentication Method : Pre-Shared Key
- Pre-Shared Key : xxxxxxxxxxxxxxxxxxxxx
- Authentication Algorithm : sha1
- Encryption Algorithm : aes-128-cbc
- Lifetime : 28800 seconds
- Phase 1 Negotiation Mode : main
- Perfect Forward Secrecy : Diffie-Hellman Group 2

#2: IPSec Configuration

Configure the IPSec SA as follows:
Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 1,2, 5, 14-18, 22, 23, and 24.
- Protocol : esp
- Authentication Algorithm : hmac-sha1-96
- Encryption Algorithm : aes-128-cbc
- Lifetime : 3600 seconds
- Mode : tunnel
- Perfect Forward Secrecy : Diffie-Hellman Group 2

IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
- DPD Interval : 10
- DPD Retries : 3

IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space,
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following
configuration on your Customer Gateway:
- TCP MSS Adjustment : 1387 bytes
- Clear Don't Fragment Bit : enabled
- Fragmentation : Before encryption

#3: Tunnel Interface Configuration

Your Customer Gateway must be configured with a tunnel interface that is
associated with the IPSec tunnel. All traffic transmitted to the tunnel
interface is encrypted and transmitted to the Virtual Private Gateway.

The Customer Gateway and Virtual Private Gateway each have two addresses that relate
to this IPSec tunnel. Each contains an outside address, upon which encrypted
traffic is exchanged. Each also contain an inside address associated with
the tunnel interface.

The Customer Gateway outside IP address was provided when the Customer Gateway
was created. Changing the IP address requires the creation of a new
Customer Gateway.

The Customer Gateway inside IP address should be configured on your tunnel
interface.

Outside IP Addresses:
- Customer Gateway : x.x.x.x
- Virtual Private Gateway : x.x.x.x

Inside IP Addresses
- Customer Gateway : x.x.x.x
- Virtual Private Gateway : x.x.x.x

Configure your tunnel to fragment at the optimal size:
- Tunnel interface MTU : 1436 bytes

#4: Static Routing Configuration:

To route traffic between your internal network and your VPC,
you will need a static route added to your router.

Static Route Configuration Options:

- Next hop : 169.254.255.5

You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over
the tunnels.

I'm unable to find some of the settings that AWS recommends in the configuration such as DPD. I feel like I'm missing something simple and it may not be a setting in the GUI. Could it be a console command or commands? I see DPD is enabled on the IPsec policy but don't see the settings for it in the GUI.

IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We recommend configuring DPD on your endpoint as follows:

- DPD Interval : 10
- DPD Retries : 3

Hi PG Tech,

With the given external IP that your tunnel is meant to initiate a connection with, could perform a no fragment ping test?

To do this you will want to SSH to the UTM and run the following command: ping -M do -s 1387 <IP of remote gateway>

This will run a ping test to the destination with no fragmentation allowed, recently I've been encountering a few problems with IPSEC tunnels and fragmentation causing random drops in the tunnel consistency. This is just a wee test, i doubt it will show up much, but if when you do the above the ping borks out saying it couldn't ping due to fragmentation, keep lowering it until the pings are successful. Then configure the interface under Network for the WAN which the tunnel will be built from to that MTU under advanced settings.

The only settings I can't remember if you can do and I can't see them are the "Clear don't fragment bit" and "Fragmentation: Before Encryption", if I remember correctly these are enabled by default but I will need to try and confirm that.

The DPD settings are under the profile but you can only set the interval it checks for (in seconds which would be 10 in this case) and how long it will wait for a response but not for how many tries. I doubt this would affect tunnel stability because all it's doing is checking if the tunnel is active and if it doesn't receive a response to close the tunnel and will keep retrying until the tunnel comes back up.

Hope this helps progress!

Emile

Hi Emile,

I tried command from console and shell. Both error

SG230_WP01_SFOS 16.01.1# ping -M do -s 1387 72.21.209.224
ping: invalid option -- 'M'

console> ping -M do -s 1387 72.21.209.224

% Error: Unknown Parameter 'do'

Hi PG Tech,

Sorry, I meant ping -M do -s 1387 <ip address>

Forgot the -s!

Emile

Still no luck with ping command. No matter what I try it says invalid command.

PG did you ever get this working?  I have another thread and spent hours trying toget traffic flowing both ways but still can't on an XG 85 fully updated using a static VPN with amazon.

Thanks!

Joey Costa said:

PG did you ever get this working?  I have another thread and spent hours trying toget traffic flowing both ways but still can't on an XG 85 fully updated using a static VPN with amazon.

Thanks!

 

No sorry never got it working. I've had bigger fish to fry and it was put on the back burner. I will at some point this year dig back into the issue and get it working. I will update this thread then.

Finally got this to work. Silly fix I discovered here... https://aws.amazon.com/premiumsupport/knowledge-center/vpn-connection-instability/

I consolidated down to one remote LAN network(subnet) in the IPsec connection I had setup for AWS and no more random packet drops. Here's my IPsec profile policy for AWS. Hope this helps anyone else having the same issue we had.