[7.901][BUG][FIXED] Site-to-Site VPN still dead

Unfortunately my old thread was closed, but the problem is still not fixed.

Old thread:
https://community.sophos.com/products/unified-threat-management/astaroorg/f/102/t/69222

Now tried to manually create the VPN with RSA keys. No chance to get it working.

Attached some logs from the V7.5 side. Looks still like the RSA key is wrong. No idea why. Also tried it after 7.901 updated.

After update, the key seems to be (re)geretated correct, right? (The perl snipped does not change anything now)

0 Astaro Beta Bot over 15 years ago

Astaro Beta Report

--------------------------------

Version: 7.901

Type: BUG

State: CLOSED/FIXED

Reporter: Whity++

Contributor: x-cimo

MantisID: 13309

Target version: 7.902

Fixed in version: 7.902

--------------------------------

0 UrsWeiss over 15 years ago in reply to Astaro Beta Bot

Oh, on the V8 side i get tons of these messages in the VPN log:

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: |

(Around 10MB per hour)

0 AngeloC over 15 years ago

Hi Whity,

I had this exact problem using a V8 Beta -> V7.504 ipsec site site tunnel. The problem was indeed the RSA key on the v8 box being mangled.

The first fix from d12k simply broke the ipsec daemon all together, but the second, perl based one totally solved the problem for me, i just pasted that into the command line, and re-copied the public key via webadmin (did NOT hit apply to regenerate it) into my v7 box, and it was all good again. (copy n paste all lines at once and hit enter)

perl -e 'use MIME::Base64;
my $cc = "/usr/local/bin/confd-client.plx";
my $ref = qx($cc get ipsec local_rsa);
$ref =~ s/.*(REF_.{10}).*/\1/;
my $obj = qx($cc get_object ${ref});
$obj =~ s/get_object returned//;
$obj =~ s/0x00/0x/g;
$obj =~ /Modulus: 0x([0-9a-f]*)/;
my $hex = "0103$1";
my $pubkey = "0s". encode_base64(pack("H". length($hex), $hex), "");
$obj =~ s/0s[0-9a-zA-z\\/+=]*/$pubkey/;
qx($cc set_object "$obj");'

Let me know if this fixes your issue, again, nothing changed ever on the V7 box, i just made the command line cut n paste, hit enter, waited 5 seconds, went into webadmin, grabbed the public rsa key out of the window and put it into the v7 remote gateway box for the RSA key.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 x-cimo over 15 years ago in reply to UrsWeiss

Oh, on the V8 side i get tons of these messages in the VPN log:

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: | 

2010:04:09-00:00:15 whity pluto[7458]: | *received kernel message

2010:04:09-00:00:15 whity pluto[7458]: | next event EVENT_DPD in 24 seconds for #13

2010:04:09-00:00:15 whity pluto[7458]: |

(Around 10MB per hour)

For those, make sure you have the VPN debugging off (a few checkbox in the vpn settings).

0 d12fk over 15 years ago

Attached some logs from the V7.5 side. Looks still like the RSA key is wrong. No idea why. Also tried it after 7.901 updated.

From the log file it looks like one of the ASGs is picking the wrong key. What kind of IPsec connections are active on the ASGs? Could you scan /var/sec/chroot-ipsec/etc/ipsec.secrets for lines starting with ": RSA" an tell me how many of those you have for the V8 and V7?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 Sascha Paris over 15 years ago in reply to d12fk

From the log file it looks like one of the ASGs is picking the wrong key. What kind of IPsec connections are active on the ASGs? Could you scan /var/sec/chroot-ipsec/etc/ipsec.secrets for lines starting with ": RSA" an tell me how many of those you have for the V8 and V7?

Hi d12fk

I have the same issue here. I posted you anonymized content of the ipsec.secrets file.

ipsec.secrets file of my VPN counterpart with V7.504


#
# IPSEC SECRET FILE
#


: RSA {
        # RSA 1024 bits   host.domain.example   Fri Jan 25 20:48:24 2008
        # for signatures only, UNSAFE FOR ENCRYPTION
        #pubkey=********
        Modulus: ********
        PublicExponent: 0x03
        # everything after this point is secret
        PrivateExponent: ********
        Prime1: ********
        Prime2: ********
        Exponent1: ********
        Exponent2: ********
        Coefficient: ********
        }



# if you want to add additional secrets by hand,
# please do below this message

ipsec.secrets file of my own ASG with V7.901. I wonder the 3rd line starting with 87.102.*.*, which is my public IP. The last line with ": RSA REF_..." also differs from V7 Machine.


# /etc/ipsec.secrets - strongSwan IPsec secrets file

87.102.*.* %any : PSK ********
: RSA {
        # RSA 1024 bits   host.domain.example   Fri Jan 25 20:48:24 2008
        # for signatures only, UNSAFE FOR ENCRYPTION
        #pubkey=********
        Modulus: ********
        PublicExponent: 0x03
        # everything after this point is secret
        PrivateExponent: ********
        Prime1: ********
        Prime2: ********
        Exponent1: ********
        Exponent2: ********
        Coefficient: ********
      }
: RSA REF_********.pem

Maybe this helps finding the issue. I'm Astaro employee too, so if you need access to my ASG, contact me ;o)

0 d12fk over 15 years ago in reply to Sascha Paris
I have the same issue here. I posted you anonymized content of the ipsec.secrets file.

ipsec.secrets file of my own ASG with V7.901. I wonder the 3rd line starting with 87.102.*.*, which is my public IP. The last line with ": RSA REF_..." also differs from V7 Machine.

# /etc/ipsec.secrets - strongSwan IPsec secrets file

87.102.*.* %any : PSK ********
: RSA {
        # RSA 1024 bits   host.domain.example   Fri Jan 25 20:48:24 2008
        # for signatures only, UNSAFE FOR ENCRYPTION
        #pubkey=********
        Modulus: ********
        PublicExponent: 0x03
        # everything after this point is secret
        PrivateExponent: ********
        Prime1: ********
        Prime2: ********
        Exponent1: ********
        Exponent2: ********
        Coefficient: ********
      }
: RSA REF_********.pem

You probably have another IPsec connection using x509 auth enabled. That's where the second RSA secrets entry comes from. So there's nothing wrong with it. The IKE daemon just can't figure out which of the two it should use for you site-to-site connection... and picks the wrong one. =(

I actually planned to fix this already, but since the "bug" was in V7 since the beginning I figured it's nothing people come across very often. Wrong. Will be fixed in the next update. Until then you can just disable the other connection if it's not important or use a strong PSK instead.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 d12fk over 15 years ago in reply to d12fk

I actually planned to fix this already, but since the "bug" was in V7 since the beginning I figured it's nothing people come across very often. Wrong.

Wrong again, this indeed was a subtle regression in V8, as it does not write the secrets in the same order than V7 did. This is fixed now and will be included in 7.902. Thanks for helping find this!
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel