Project

General

Profile

Issue #3316

Problem with Strongswan 5.3.5

Added by Imran Ullah 3 months ago. Updated 2 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.3.5
Resolution:

Description

OS : Ubuntu 16.04

Dear Team,

We are in the process of upgrading strongswan from 4.5.2 to 5.3.5. We are testing the new version on a separate server, with the Same OS and other specifications. We have modified the ipsec.conf file for new version:

conn %default
                type            =tunnel
                left            =123.123.123.123
                leftsubnet      =123.123.123.123/32
                ikelifetime     =86400s
                keylife         =28800s
                auto            =start
                authby          =secret
                keyexchange     =ikev1
                aggressive      =no
                compress        =no

Tunnel Conf:

conn testtunnel
        right                   = 3.2.3.2
        rightsubnet             = 1.2.1.2/32
        esp                     = aes256-sha512-modp1536
        ike                     = aes256-sha512-modp1536

The problem is some tunnels are successfully established, the others are not. When we check 'ipsec status' for the tunnels that are not UP, it says no matching Tunnel found. I could not see any particular error in logs also. We are using keepalive for Virtual IPs. All the IPs are added to the configuration of keepalive also, to establish the connections, but still we are unable to do it.

Please guide if our configuration files are OK. Please also guide what can we do to eradicate the problem. Unfortunately we are clueless at the moment.

icm.txt (48.8 KB) icm.txt Imran Ullah, 22.01.2020 13:51

History

#1 Updated by Imran Ullah 3 months ago

Logs for the Tunnel that is UP on old version, but Down on new version(new server).

11[NET] received packet: from 1.8.6.2[500] to 3.2.1.0[500] (140 bytes)
Jan 19 20:34:10 server charon: 11[ENC] invalid ID_V1 payload length, decryption failed?
Jan 19 20:34:10 server charon: 11[ENC] could not decrypt payloads
Jan 19 20:34:10 server charon: 11[IKE] message parsing failed
Jan 19 20:34:10 server charon: 11[ENC] generating INFORMATIONAL_V1 request 1123901249 [ HASH N(PLD_MAL) ]
Jan 19 20:34:10 server charon: 11[NET] sending packet: from 3.2.1.0[500] to 1.8.6.2[500] (124 bytes)
Jan 19 20:34:10 server charon: 11[IKE] ID_PROT request with message ID 0 processing failedĀ“

Logs using GREP

Jan 19 20:33:54 server charon: 00[CFG]   loaded IKE secret for 3.2.1.0 1.8.6.2
Jan 19 20:33:58 server charon: 07[NET] received packet: from 1.8.6.2[500] to 3.2.1.0[500] (292 bytes)
Jan 19 20:33:58 server charon: 07[IKE] no IKE config found for 3.2.1.0...1.8.6.2, sending NO_PROPOSAL_CHOSEN
Jan 19 20:33:58 server charon: 07[NET] sending packet: from 3.2.1.0[500] to 1.8.6.2[500] (40 bytes)
Jan 19 20:34:07 server charon: 07[NET] received packet: from 1.8.6.2[500] to 3.2.1.0[500] (292 bytes)
Jan 19 20:34:07 server charon: 07[IKE] 1.8.6.2 is initiating a Main Mode IKE_SA
Jan 19 20:34:07 server charon: 07[NET] sending packet: from 3.2.1.0[500] to 1.8.6.2[500] (140 bytes)
Jan 19 20:34:07 server charon: 08[NET] received packet: from 1.8.6.2[500] to 3.2.1.0[500] (460 bytes)
Jan 19 20:34:07 server charon: 08[NET] sending packet: from 3.2.1.0[500] to 1.8.6.2[500] (460 bytes)
Jan 19 20:34:07 server charon: 10[NET] received packet: from 1.8.6.2[500] to 3.2.1.0[500] (140 bytes)
Jan 19 20:34:07 server charon: 10[NET] sending packet: from 3.2.1.0[500] to 1.8.6.2[500] (124 bytes)
Jan 19 20:34:10 server charon: 11[NET] received packet: from 1.8.6.2[500] to 3.2.1.0[500] (140 bytes)
Jan 19 20:34:10 server charon: 11[NET] sending packet: from 3.2.1.0[500] to 1.8.6.2[500] (124 bytes)
Jan 19 20:34:16 server charon: 14[NET] received packet: from 1.8.6.2[500] to 3.2.1.0[500] (140 bytes)
Jan 19 20:34:16 server charon: 14[NET] sending packet: from 3.2.1.0[500] to 1.8.6.2[500] (124 bytes)
Jan 19 20:34:28 server charon: 12[NET] received packet: from 1.8.6.2[500] to 3.2.1.0[500] (140 bytes)
Jan 19 20:34:28 server charon: 12[NET] sending packet: from 3.2.1.0[500] to 1.8.6.2[500] (124 bytes)
Jan 19 20:34:37 server charon: 07[NET] received packet: from 1.8.6.2[500] to 3.2.1.0[500] (292 bytes)

Old Conf file:

config setup
    #plutodebug=none
    #plutodebug=control
    plutodebug=none
    charonstart=no
    nat_traversal=yes
    plutostderrlog=/var/log/pluto.log
    interfaces=%defaultroute

conn %default
    #ikelifetime=60m
    #keylife=20m
    rekeymargin=3m
    keyexchange=ikev1
    #authby=secret
    auto=add
    compress=no
    keyingtries=5
    pfs=yes
    type=tunnel
    leftnexthop=1.1.1.1
    dpdaction = clear
    dpdtimeout = 10s
    dpddelay = 90s

Tunnel conf:

conn testtunnel
        type                    = tunnel
        left                    = our public IP
        leftsubnet              = our local subnet
        leftsourceip            = our local IP
        right                   = Clients Public IP
        rightsubnet             = Clients local IP
        esp                     = aes256-sha512-modp1536
        ike                     = aes256-sha512-modp1536
        ikelifetime             = 86400s
        keylife                 = 28800s
        authby                  = secret
        dpdaction               = restart
        auto                    = start

#2 Updated by Tobias Brunner 3 months ago

  • Description updated (diff)
  • Category changed from charon to configuration
  • Status changed from New to Feedback
  • Priority changed from Urgent to Normal

I could not see any particular error in logs also.

Then why not post the complete logs so we can have a look at them? Maybe just try a single connection first to make it work successfully.

Logs for the Tunnel that is UP on old version, but Down on new version(new server).

Those snippets are not really helpful. And what does "Logs using GREP" mean?

We are using keepalive for Virtual IPs. All the IPs are added to the configuration of keepalive also, to establish the connections, but still we are unable to do it.

Not sure what that means exactly (in particular what you mean with virtual IP). But maybe you want to use auto=route so traffic triggers the connection.

#3 Updated by Imran Ullah 2 months ago

Good Morning,

Thanks a lot for the quick and detailed reply.

As you suggested, I tested the new version with less Tunnels today. As noted earlier, some tunnels were UP, some were down. I observed something for 2 which were down. Both had 'not a local address or the interface is down' in logs.
one of them is using a pem certificate for authentication, the other PSK for authentication

(for the tunnel using a .pem for authentication)
Jan 22 07:48:54 04[KNL] 1.1.1.1 is not a local address or the interface is down
Jan 22 07:48:54 04[ASN] file content is not binary ASN.1

'*_Those snippets are not really helpful. And hat does "Logs using GREP" mean?_*'
I just wanted to show details of negotiations. For Logs, can you tell us what we should be seeing particularly, and sharing with you? What I think is it has something to do with the Leftsubnet settings in configuration file. Even if I put leftsubnet in configuration file, the tunnel does not establish.

'*_Not sure what that means exactly (in particular what you mean with virtual IP). But maybe you want to use auto=route so traffic triggers the connection_*'
we are using a pool of IP addresses as 'left subnet', not just native IP address.

Tobias Brunner wrote:

I could not see any particular error in logs also.

Then why not post the complete logs so we can have a look at them? Maybe just try a single connection first to make it work successfully.

Logs for the Tunnel that is UP on old version, but Down on new version(new server).

Those snippets are not really helpful. And hat does "Logs using GREP" mean?

We are using keepalive for Virtual IPs. All the IPs are added to the configuration of keepalive also, to establish the connections, but still we are unable to do it.

Not sure what that means exactly (in particular what you mean with virtual IP). But maybe you want to use auto=route so traffic triggers the connection.

#4 Updated by Imran Ullah 2 months ago

#5 Updated by Tobias Brunner 2 months ago

Jan 22 07:48:54 04[KNL] 1.1.1.1 is not a local address or the interface is down
Jan 22 07:48:54 04[ASN] file content is not binary ASN.1

Both are not errors (as long as the IP address in the first message is the remote IP).

For Logs, can you tell us what we should be seeing particularly, and sharing with you?

Obviously, depends on a lot of things. But you can find (successful) logs to compare in our test results. See HelpRequests for useful log settings for debugging.

What I think is it has something to do with the Leftsubnet settings in configuration file. Even if I put leftsubnet in configuration file, the tunnel does not establish.

Definitely possible. For IKEv1, the values of left|rightsubnet (traffic selectors) have to match on both ends. However, the error in the log indicates that there is a problem with the algorithm negotiation (NO_PROPOSAL_CHOSEN). Check the log on the other end for details (and double check that the configured proposals are correct).

we are using a pool of IP addresses as 'left subnet', not just native IP address.

You might be confusing things. "Virtual IP" and "pool" are terms used for negotiating tunnel IP addresses between client and server. Simply tunneling traffic from IP addresses from a subnet is something different (i.e. just configure left|rightsubnet accordingly in that case).

#6 Updated by Imran Ullah 2 months ago

Just for information, with the old version of IPSec, these tunnels are UP and running.

sample configurations on old server using 4.5.2

conn tunnel_name
type = tunnel
left = 1.1.1.1
leftid = "1.1.1.1"
leftsubnet = 10.206.130.128/27
leftsourceip = 10.206.130.129
right = 2.2.2.2
rightid = "2.2.2.2"
ikelifetime = 86400s
keylife = 3600s
esp = aes128-sha1
ike = aes256-sha1-modp1024
leftcert = /etc/ipsec.d/certs/icm.pem
leftsendcert = ifasked
dpdaction = restart

conn sub_tunnel1
rightsubnet = local_network/21
also = tunnel_name
auto = start

sample configurations for 5.3.5
conn tunnel_name
leftid =1.1.1.1
leftsubnet =10.206.130.128/27
right =2.2.2.2
rightid =2.2.2.2 (same as public IP)
keylife =3600s
esp =aes128-sha1
ike =aes256-sha1-modp1024
leftcert =/etc/ipsec.d/certs/icm.pem
leftsendcert =ifasked
dpdaction =restart

conn sub_tunnel
rightsubnet =local_network/21
also =tunnel_name

#7 Updated by Imran Ullah 2 months ago

Good Morning,

Just an Update:
I was able to connect the other tunnel by adding leftsourceip parameter in the configurations and then adding the route.

for the Tunnel mentioned above, waiting for the logs from the other side.

Also available in: Atom PDF