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

UTM 9 in AWS to XG85 on prem - IPSEC S2S VPN issues

Hi,

I have a UTM 9 in AWS.

Trying to setup S2S IPSEC VPN to a XG85.

Have checked the policy details match up on both ends but I believe I am having an issue because the UTM 9s external interface is a private AWS IP. 

I have tried to set the remote VPN ID on the XG85 end to the private AWS IP of the UTM.

XG85 end is set to respond only. I have re-entered the PSK on both ends.

Any help would be much appreciated.

The last snippet of the logs from the UTM I get are: 

2019:08:30-16:16:07 utm pluto[5317]: | Notify Message Type: AUTHENTICATION_FAILED
2019:08:30-16:16:07 utm pluto[5317]: | removing 16 bytes of padding
2019:08:30-16:16:07 utm pluto[5317]: "S_To-HeadOffice" #16: ignoring informational payload, type AUTHENTICATION_FAILED
2019:08:30-16:16:07 utm pluto[5317]: | info: ba d7 6d 3a 52 00 08 35 66 66 31 1f 31 bc 35 e7
2019:08:30-16:16:07 utm pluto[5317]: | next event EVENT_RETRANSMIT in 10 seconds for #16
2019:08:30-16:16:17 utm pluto[5317]: |
2019:08:30-16:16:17 utm pluto[5317]: | *time to handle event
2019:08:30-16:16:17 utm pluto[5317]: | event after this is EVENT_REINIT_SECRET in 2536 seconds
2019:08:30-16:16:17 utm pluto[5317]: | handling event EVENT_RETRANSMIT for x.x.x.x "S_To-HeadOffice" #16
2019:08:30-16:16:17 utm pluto[5317]: | inserting event EVENT_RETRANSMIT, timeout in 20 seconds for #16
2019:08:30-16:16:17 utm pluto[5317]: | next event EVENT_RETRANSMIT in 20 seconds for #16
2019:08:30-16:16:37 utm pluto[5317]: |
2019:08:30-16:16:37 utm pluto[5317]: | *time to handle event
2019:08:30-16:16:37 utm pluto[5317]: | event after this is EVENT_REINIT_SECRET in 2516 seconds
2019:08:30-16:16:37 utm pluto[5317]: | handling event EVENT_RETRANSMIT for x.x.x.x "S_To-HeadOffice" #16
2019:08:30-16:16:37 utm pluto[5317]: | inserting event EVENT_RETRANSMIT, timeout in 40 seconds for #16
2019:08:30-16:16:37 utm pluto[5317]: | next event EVENT_RETRANSMIT in 40 seconds for #16
2019:08:30-16:17:17 utm pluto[5317]: |
2019:08:30-16:17:17 utm pluto[5317]: | *time to handle event
2019:08:30-16:17:17 utm pluto[5317]: | event after this is EVENT_REINIT_SECRET in 2476 seconds
2019:08:30-16:17:17 utm pluto[5317]: | handling event EVENT_RETRANSMIT for x.x.x.x "S_To-HeadOffice" #16
2019:08:30-16:17:17 utm pluto[5317]: "S_To-HeadOffice" #16: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
2019:08:30-16:17:17 utm pluto[5317]: "S_To-HeadOffice" #16: starting keying attempt 17 of an unlimited number


This thread was automatically locked due to age.
  • Hi Matt and welcome to the UTM Community!

    "Possible authentication failure: no acceptable response to our first encrypted message"

    Rather than trying to set the VPN ID, leave the default on the XG and set it to respond only so that it doesn't attempt to initiate the connection.  Then, use an "Initiate connection" Remote Gateway in the UTM.  If that doesn't get you going, do the following:

    1. Confirm that Debug is not enabled.
    2. Disable the IPsec Connection.
    3. Start the IPsec Live Log and wait for it to begin to populate.
    4. Enable the IPsec Connection.
    5. Copy here about 60 lines from enabling through the error.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob,

     

    Thanks for the response. I made those changes and it didnt seem to make any difference.

     

    Please see the logs as requested below:

     

    2019:09:01-11:37:09 utm ipsec_starter[18176]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
    2019:09:01-11:37:09 utm pluto[18192]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
    2019:09:01-11:37:09 utm ipsec_starter[18182]: pluto (18192) started after 20 ms
    2019:09:01-11:37:10 utm pluto[18192]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve
    2019:09:01-11:37:10 utm pluto[18192]: including NAT-Traversal patch (Version 0.6c) [disabled]
    2019:09:01-11:37:10 utm pluto[18192]: Using Linux 2.6 IPsec interface code
    2019:09:01-11:37:10 utm pluto[18192]: loading ca certificates from '/etc/ipsec.d/cacerts'
    2019:09:01-11:37:10 utm pluto[18192]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA.pem'
    2019:09:01-11:37:10 utm pluto[18192]: loading aa certificates from '/etc/ipsec.d/aacerts'
    2019:09:01-11:37:10 utm pluto[18192]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2019:09:01-11:37:10 utm pluto[18192]: Changing to directory '/etc/ipsec.d/crls'
    2019:09:01-11:37:10 utm pluto[18192]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2019:09:01-11:37:10 utm pluto[18192]: adding interface reds2/reds2 192.168.xx.254:500
    2019:09:01-11:37:10 utm pluto[18192]: adding interface reds1/reds1 192.168.xx.254:500
    2019:09:01-11:37:10 utm pluto[18192]: adding interface eth1/eth1 172.16.x.200:500
    2019:09:01-11:37:10 utm pluto[18192]: adding interface eth0/eth0 172.16.x.202:500
    2019:09:01-11:37:10 utm pluto[18192]: adding interface eth0/eth0 172.16.x.201:500
    2019:09:01-11:37:10 utm pluto[18192]: adding interface eth0/eth0 172.16.x.200:500
    2019:09:01-11:37:10 utm pluto[18192]: adding interface lo/lo 127.0.0.1:500
    2019:09:01-11:37:10 utm pluto[18192]: adding interface lo/lo ::1:500
    2019:09:01-11:37:10 utm pluto[18192]: loading secrets from "/etc/ipsec.secrets"
    2019:09:01-11:37:10 utm pluto[18192]: loaded PSK secret for 172.16.xx.200 x.x.x.x
    2019:09:01-11:37:10 utm pluto[18192]: listening for IKE messages
    2019:09:01-11:37:10 utm pluto[18192]: added connection description "S_To-HeadOffice"
    2019:09:01-11:37:10 utm pluto[18192]: "S_To-HeadOffice" #1: initiating Main Mode
    2019:09:01-11:37:10 utm pluto[18192]: "S_To-HeadOffice" #1: received Vendor ID payload [XAUTH]
    2019:09:01-11:37:10 utm pluto[18192]: "S_To-HeadOffice" #1: received Vendor ID payload [Dead Peer Detection]
    2019:09:01-11:37:10 utm pluto[18192]: "S_To-HeadOffice" #1: ignoring Vendor ID payload [Cisco-Unity]
    2019:09:01-11:37:11 utm pluto[18192]: "S_To-HeadOffice" #1: ignoring informational payload, type AUTHENTICATION_FAILED
    2019:09:01-11:38:20 utm pluto[18192]: "S_To-HeadOffice" #1: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
    2019:09:01-11:38:20 utm pluto[18192]: "S_To-HeadOffice" #1: starting keying attempt 2 of an unlimited number
    2019:09:01-11:38:20 utm pluto[18192]: "S_To-HeadOffice" #2: initiating Main Mode to replace #1
    2019:09:01-11:38:20 utm pluto[18192]: "S_To-HeadOffice" #2: received Vendor ID payload [XAUTH]
    2019:09:01-11:38:20 utm pluto[18192]: "S_To-HeadOffice" #2: received Vendor ID payload [Dead Peer Detection]
    2019:09:01-11:38:20 utm pluto[18192]: "S_To-HeadOffice" #2: ignoring Vendor ID payload [Cisco-Unity]
    2019:09:01-11:38:20 utm pluto[18192]: "S_To-HeadOffice" #2: ignoring informational payload, type AUTHENTICATION_FAILED
  • Please show pictures of the Edits of the IPsec Connection and Remote Gateway in the UTM.  Also the IPsec connection in the XG.  Obfuscate IPs like 84.XX.YY.121, 10.X.Y.100, 192.168.X.200 and 172.16.Y.51.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob,

    I actually found a typo in the object 'head-office-internal' on the UTM side. I have corrected this but it still does not connect. Please see details below:

     

     

    UTM objects:

    External interface (eth0): 172.16.a.200 (assigned by AWS)

    UTM-internal local network: 172.16.b.0 /24

    'river road' gateway: 139.ccc.ccc.246

    'head-office-internal' (XG side internal network): 192.168.d.0 /24

    XG:

    Note the remote gateway address is the actual external IP, this then translates into 172.16.a.200 on the external interface of the UTM through AWS

     

    Also see fresh logs after I made the change:

     

    2019:09:05-14:16:28 utm ipsec_starter[24296]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
    2019:09:05-14:16:28 utm pluto[24311]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
    2019:09:05-14:16:28 utm ipsec_starter[24302]: pluto (24311) started after 20 ms
    2019:09:05-14:16:28 utm pluto[24311]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve
    2019:09:05-14:16:28 utm pluto[24311]: including NAT-Traversal patch (Version 0.6c) [disabled]
    2019:09:05-14:16:28 utm pluto[24311]: Using Linux 2.6 IPsec interface code
    2019:09:05-14:16:29 utm pluto[24311]: loading ca certificates from '/etc/ipsec.d/cacerts'
    2019:09:05-14:16:29 utm pluto[24311]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA.pem'
    2019:09:05-14:16:29 utm pluto[24311]: loading aa certificates from '/etc/ipsec.d/aacerts'
    2019:09:05-14:16:29 utm pluto[24311]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2019:09:05-14:16:29 utm pluto[24311]: Changing to directory '/etc/ipsec.d/crls'
    2019:09:05-14:16:29 utm pluto[24311]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2019:09:05-14:16:29 utm pluto[24311]: adding interface reds2/reds2 192.168.xx.254:500
    2019:09:05-14:16:29 utm pluto[24311]: adding interface reds1/reds1 192.168.xx.254:500
    2019:09:05-14:16:29 utm pluto[24311]: adding interface eth1/eth1 172.16.b.200:500
    2019:09:05-14:16:29 utm pluto[24311]: adding interface eth0/eth0 172.16.d.202:500
    2019:09:05-14:16:29 utm pluto[24311]: adding interface eth0/eth0 172.16.c.201:500
    2019:09:05-14:16:29 utm pluto[24311]: adding interface eth0/eth0 172.16.a.200:500
    2019:09:05-14:16:29 utm pluto[24311]: adding interface lo/lo 127.0.0.1:500
    2019:09:05-14:16:29 utm pluto[24311]: adding interface lo/lo ::1:500
    2019:09:05-14:16:29 utm pluto[24311]: loading secrets from "/etc/ipsec.secrets"
    2019:09:05-14:16:29 utm pluto[24311]: loaded PSK secret for 172.16.a.200 139.ccc.ccc.246
    2019:09:05-14:16:29 utm pluto[24311]: listening for IKE messages
    2019:09:05-14:16:29 utm pluto[24311]: added connection description "S_To-HeadOffice"
    2019:09:05-14:16:29 utm pluto[24311]: "S_To-HeadOffice" #1: initiating Main Mode
    2019:09:05-14:16:29 utm pluto[24311]: "S_To-HeadOffice" #1: received Vendor ID payload [XAUTH]
    2019:09:05-14:16:29 utm pluto[24311]: "S_To-HeadOffice" #1: received Vendor ID payload [Dead Peer Detection]
    2019:09:05-14:16:29 utm pluto[24311]: "S_To-HeadOffice" #1: ignoring Vendor ID payload [Cisco-Unity]
    2019:09:05-14:16:29 utm pluto[24311]: "S_To-HeadOffice" #1: ignoring informational payload, type AUTHENTICATION_FAILED
    2019:09:05-14:17:39 utm pluto[24311]: "S_To-HeadOffice" #1: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
    2019:09:05-14:17:39 utm pluto[24311]: "S_To-HeadOffice" #1: starting keying attempt 2 of an unlimited number
    2019:09:05-14:17:39 utm pluto[24311]: "S_To-HeadOffice" #2: initiating Main Mode to replace #1
    2019:09:05-14:17:39 utm pluto[24311]: "S_To-HeadOffice" #2: received Vendor ID payload [XAUTH]
    2019:09:05-14:17:39 utm pluto[24311]: "S_To-HeadOffice" #2: received Vendor ID payload [Dead Peer Detection]
    2019:09:05-14:17:39 utm pluto[24311]: "S_To-HeadOffice" #2: ignoring Vendor ID payload [Cisco-Unity]
    2019:09:05-14:17:39 utm pluto[24311]: "S_To-HeadOffice" #2: ignoring informational payload, type AUTHENTICATION_FAILED
    2019:09:05-14:18:49 utm pluto[24311]: "S_To-HeadOffice" #2: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
  • Hi Bob,

     

    Any further ideas on this?

     

    Cheers

  • I don't see that NAT-T is selected in the XG - it should be both there and in the UTM.

    Are we certain that 52.x.y.95 is the IP on the External interface - and that there's no NAT between it and the ISP?  Same for 139.x.y.246 and the XG?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob,

     

    Thanks for the response. 

     

    I was able to get the VPN up by setting the the VPN ID on the UTM side to the public IP:

     

     

    I couldn't get any pings across it though but was able to resolve that by allowing ping on the UTM and XG side:

     

     

    Thanks for your assistance!

  • Good job, Matt.  Specifying the IP address is necessary when you have to use "Initiate Connection" and you have a NATting router in front of your UTM.  For more details about pinging, see #2 in Rulz (last updated 2019-04-17).

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA