This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

We recently setup site to site tunnels from our new XG230 running 16.01.1 to another XG, Cisco ASA and AWS. All are working fine except the AWS tunnel will drop pings intermittently from the 2 LAN's behind the XG to the servers in the AWS VPC. I used the generic VPN configuration AWS provides. pcap shows no gateway on incoming response.

2016-10-19 15:00:07
PortE5
ipsec0
IPv4
10.100.1.11
10.30.1.97
ICMP
--
3
Forwarded
 
512
2016-10-19 15:00:07
PortE5
 
IPv4
10.100.1.11
10.30.1.97
ICMP
--
0
Incoming
 
No Gateway


This thread was automatically locked due to age.
Parents
  • 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.

     

  • 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.

     

  • Hi, how you make that static route, off the amazon config file #4 ?

  • No static route needed on the Sophos, but you do need static routes in your VPC Route Tables for the private subnets behind your Sophos. Go to AWS and make sure you have a Route Table for the VPC and associated subnet. My AWS Route Table looks like this below. Basically pointing your remote LAN subnets to the Virtual Gateway at AWS.

     

    Destination
    Target
    Status
    Propagated
    10.50.0.0/16
    local
    Active
    No
    0.0.0.0/0
    igw-cXXXXXX
    Active
    No
    10.100.1.0/24
    vgw-eXXXXXX
    Active
    No
    192.168.0.0/22
    vgw-eXXXXXX
    Active
    No
    pl-68XXXXXXX(com.amazonaws.us-west-2.s3)
    vpce-3XXXXX
    Active
    No
Reply
  • No static route needed on the Sophos, but you do need static routes in your VPC Route Tables for the private subnets behind your Sophos. Go to AWS and make sure you have a Route Table for the VPC and associated subnet. My AWS Route Table looks like this below. Basically pointing your remote LAN subnets to the Virtual Gateway at AWS.

     

    Destination
    Target
    Status
    Propagated
    10.50.0.0/16
    local
    Active
    No
    0.0.0.0/0
    igw-cXXXXXX
    Active
    No
    10.100.1.0/24
    vgw-eXXXXXX
    Active
    No
    192.168.0.0/22
    vgw-eXXXXXX
    Active
    No
    pl-68XXXXXXX(com.amazonaws.us-west-2.s3)
    vpce-3XXXXX
    Active
    No
Children
No Data