IPsec tunnel broken after nightly build upgrade
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• ahaitoute
	Jun 7 2016, 12:49 PM

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

Version: current

Event Timeline

• ahaitoute created this task.Jun 7 2016, 12:49 PM

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
                }
            }
        }
    }
}

@EwaldvanGeffen
can you take a look this
Thanks

syncer added a subscriber: VyOS 1.1.x (1.1.8).Jun 8 2016, 4:47 PM

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

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

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 projects, added VyOS 1.2 Crux; removed VyOS 1.1.x (1.1.8).Dec 14 2016, 1:30 PM

syncer edited subscribers, added: VyOS 1.2 Crux; 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.

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

syncer edited projects, added VyOS 1.2 Crux (VyOS 1.2.0-rc1), VyOS-1.2.0-GA; removed VyOS 1.2 Crux.Oct 15 2018, 11:06 PM

syncer moved this task from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.0-rc1) board.Oct 15 2018, 11:58 PM

IPsec tunnel broken after nightly build upgradeClosed, ResolvedPublicActions

Description

Details

Event Timeline

IPsec tunnel broken after nightly build upgrade
Closed, ResolvedPublic
Actions