IPsec tunnel broken after nightly build upgrade
Closed, ResolvedPublic

Description

I have upgraded 2 out of 3 test machines to the latest nightly build. I've got problem with ipsec connection after the upgrade. I've got the following log from the not-upgraded machine:

Jun  7 14:36:40 RSYYYY-1 pluto[2828]: "peer-10.201.2.1-tunnel-vti" #43: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: "peer-10.201.2.1-tunnel-vti" #43: starting keying attempt 12 of an unlimited number
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: "peer-10.201.2.1-tunnel-vti" #44: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #43 {using isakmp#14}
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: received Vendor ID payload [XAUTH]
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: received Vendor ID payload [Dead Peer Detection]
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: ignoring Vendor ID payload [RFC 3947]
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #45: responding to Main Mode
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #45: Oakley Transform [AES_CBC (256), HMAC_SHA2_256, (null)] refused due to strict flag
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #45: no acceptable Oakley Transform
Jun  7 14:36:40 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #45: sending notification NO_PROPOSAL_CHOSEN to 10.201.0.1:500
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: received Vendor ID payload [XAUTH]
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: received Vendor ID payload [Dead Peer Detection]
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: ignoring Vendor ID payload [RFC 3947]
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #46: responding to Main Mode
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #46: Oakley Transform [AES_CBC (256), HMAC_SHA2_256, (null)] refused due to strict flag
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #46: no acceptable Oakley Transform
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #46: sending notification NO_PROPOSAL_CHOSEN to 10.201.0.1:500
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: received Vendor ID payload [XAUTH]
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: received Vendor ID payload [Dead Peer Detection]
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: ignoring Vendor ID payload [RFC 3947]
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #47: responding to Main Mode
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #47: Oakley Transform [AES_CBC (256), HMAC_SHA2_256, (null)] refused due to strict flag
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #47: no acceptable Oakley Transform
Jun  7 14:36:41 RSYYYY-1 pluto[2828]: "peer-10.201.0.1-tunnel-vti" #47: sending notification NO_PROPOSAL_CHOSEN to 10.201.0.1:500
Jun  7 14:37:02 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Jun  7 14:37:19 RSYYYY-1 pluto[2828]: "peer-10.201.2.1-tunnel-vti" #48: initiating Main Mode to replace #14
Jun  7 14:37:19 RSYYYY-1 pluto[2828]: packet from 10.201.2.1:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Jun  7 14:37:29 RSYYYY-1 pluto[2828]: packet from 10.201.2.1:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Jun  7 14:37:42 RSYYYY-1 pluto[2828]: packet from 10.201.0.1:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Jun  7 14:37:49 RSYYYY-1 pluto[2828]: packet from 10.201.2.1:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Jun  7 14:37:50 RSYYYY-1 pluto[2828]: "peer-10.201.2.1-tunnel-vti" #44: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Jun  7 14:37:50 RSYYYY-1 pluto[2828]: "peer-10.201.2.1-tunnel-vti" #44: starting keying attempt 13 of an unlimited number

It would be great if this can be fixed.

Details

Difficulty level
Easy (less than an hour)
Version
current

Current configuration from a router:

interfaces {
......
    vti vti3 {
        address 10.223.0.2/30
    }
    vti vti4 {
        address 10.223.0.5/30
    }
}
........
vpn {
    ipsec {
        esp-group ESP-YYYY {
            compression disable
            lifetime 1800
            mode tunnel
            pfs enable
            proposal 1 {
                encryption aes256
                hash sha256
            }
        }
        ike-group IKE-YYYY {
            ikev2-reauth no
            key-exchange ikev1
            lifetime 3600
            proposal 1 {
                encryption aes256
                hash sha256
            }
        }
        ipsec-interfaces {
            interface eth1
        }
        site-to-site {
            peer 10.201.0.1 {
                authentication {
                    mode pre-shared-secret
                    pre-shared-secret ****************
                }
                connection-type initiate
                default-esp-group ESP-YYYY
                ike-group IKE-YYYY
                ikev2-reauth inherit
                local-address 10.201.1.1
                vti {
                    bind vti3
                    esp-group ESP-YYYY
                }
            }
            peer 10.201.2.1 {
                authentication {
                    mode pre-shared-secret
                    pre-shared-secret ****************
                }
                connection-type initiate
                default-esp-group ESP-YYYY
                ike-group IKE-YYYY
                ikev2-reauth inherit
                local-address 10.201.1.1
                vti {
                    bind vti4
                    esp-group ESP-YYYY
                }
            }
        }
    }
}
syncer triaged this task as High priority.Jun 8 2016, 4:47 PM
syncer added subscribers: EwaldvanGeffen, syncer.

@EwaldvanGeffen
can you take a look this
Thanks

@EwaldvanGeffen
It would be great if you could help us with this issue. So I can continue testing this version.

UnicronNL added a subscriber: UnicronNL.EditedAug 9 2016, 12:34 PM

to what version did you upgrade? (vyos) squeeze 1.7 or debian jessie?

Oakley Transform [AES_CBC (256), HMAC_SHA2_256, (null)] refused due to strict flag

looks like the "!" is missing from one of the config files.

can you check post /etc/ipsec.conf of both? (cat /etc/ipsec.conf)

Also it could be a DH Group issue, you have set pfs to "yes" in esp-group, but no dh group in ike-group.

but please check if the ike and esp rules are the same in both the ipsec.conf files

ruffy91 added a subscriber: ruffy91.EditedNov 4 2016, 9:02 AM

I have a similar problem, since 1.1.7 PFS in phase 2 is not working.
"Oakley Transform [AES_CBC (256), HMAC_SHA2_256, (null)] refused due to strict flag."
As you can see there is no pfs proposal sent by 1.1.7.
The same with a tunnel between 1.1.7 and pfsense 2.3.2.
When activating PFS on both there is no matching proposal, when disabling PFS on pfSense a proposal is found.

This problem has security implications and should be handled with high priority.

esp-group esp1 {
    compression disable
    lifetime 3600
    mode tunnel
    pfs dh-group18
    proposal 1 {
        encryption aes256
        hash sha512
    }
}
ike-group ike1 {
    ikev2-reauth no
    key-exchange ikev2
    lifetime 3600
    proposal 1 {
        dh-group 18
        encryption aes256
        hash sha512
    }
}
ipsec-interfaces {
    interface eth0
}
nat-networks {
    allowed-network 10.0.0.0/8 {
        exclude 10.42.1.0/24
        exclude 10.38.0.0/24
        exclude 10.43.0.0/24
        exclude 10.52.1.0/24
    }
    allowed-network 172.16.0.0/12 {
    }
    allowed-network 192.168.0.0/16 {
    }
}
nat-traversal enable
site-to-site {
    peer X.X.X.X {
        authentication {
            mode pre-shared-secret
            pre-shared-secret 12345678
        }
        connection-type respond
        default-esp-group esp1
        ike-group ike1
        ikev2-reauth inherit
        local-address X.X.X.X
        tunnel 1 {
            allow-nat-networks disable
            allow-public-networks disable
            local {
                prefix X.X.Y.X/24
            }
            remote {
                prefix X.X.X.X/24
            }
        }
    }
}

output from cat /etc/ipsec.conf

conn peer-X.X.X.X-tunnel-1
        left=X.X.X.X
        right=X.X.X.X
        leftsubnet=X.X.Y.X/24
        rightsubnet=X.X.X.X/24
        leftsourceip=X.X.Y.1
        ike=aes256-sha512-modp8192!
        keyexchange=ikev2
        reauth=no
        ikelifetime=3600s
        esp=aes256-sha512!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        pfs=yes
        pfsgroup=modp8192
        compress=no
        authby=secret
        auto=route
        keyingtries=1
syncer edited subscribers, added: VyOS 1.2.x; removed: VyOS 1.1.x (1.1.8).

@ruffy91

I tested your config, and it works for me (between vyos 1.1.7 and 1.2)
Also can you Please open an new task for this, this is different than the above issue.

UnicronNL closed this task as Resolved.Dec 28 2016, 10:26 AM
UnicronNL claimed this task.

@ahaitoute.

The issue is that strongswan in 1.1.7 when configures as ikev1 wil use default dh groups (modp1024 and modp1536).
Vyos 1.2 does not use default dh groups, so if you want this config to work you have to set dh group in your "ike-group IKE-YYYY proposal"
(modp1024 or modp1536 if you leave your proposal in 1.1.7 empty).

I will try to make VyOS 1.2 act like 1.1.7 on this.