[Openswan Users] problems with INVALID_KEY_INFORMATION on Debian
Jim Blake
jim at blakes.homeip.net
Fri May 25 03:46:41 EDT 2007
The problem is fixed. I blew away Openswan on both systems, and did a
clean reinstall on each.
I then did what you suggested for key creation:
"ipsec newhostkey --output /etc/ipsec.secrets --hostname xy.example.com
chmod 600 /etc/ipsec.secrets"
Then I rebuilt the existing ipsec.conf file with the right left and right
keys,, loaded the same .conf file on both ends, and it just worked!
Three possibilities for the fix, I changed all three at once so I can't be
sure what fixed it (bad diagnostic practice, sorry!)
Possibility 1: the chmod was necessary and I didn't do it before
Possibility 2: The original key generation process I used:
"ipsec newhostkey --output /root/tmpkey
cat /root/tmpkey >> /etc/ipsec.secrets
rm /root/tmpkey"
munged the keys in some way.
Possibility 3: Finger trouble on my part
Whatever it was, it's working now, so having got my testbed working, I'm
going to try to get roadwarriors operating through a Shorewall NAT-ing
firewall. You may not have heard the last of this :)
Thanks for all the help
Jim
>> -----Original Message-----
>> From: Jim Blake [mailto:jim at blakes.homeip.net]
>> Sent: May 23, 2007 4:17 PM
>> To: petermcgill at goco.net
>> Cc: jim at blakes.homeip.net; users at openswan.org
>> Subject: RE: [Openswan Users] problems with
>> INVALID_KEY_INFORMATION on Debian
>>
>> Hi Peter
>>
>> <<SNIP>>
>> >>
>> >> input: ipsec newhostkey --output /root/tmpkey
>> >> input: cat /root/tmpkey >> /etc/ipsec.secrets
>> >> input: rm /root/tmpkey
>>
>> <<SNIP>>
>>
>> Did you do this once for each of the two machines?
>>
>> Yes, and took leftkey from the left machine, and rightkey
>> from the right
>>
>>
>>
>> >
>> > This isn't your problem, openswan just uses plain rsa keys
>> > By default, no certs, there is nothing wrong with plain rsa keys.
>> > Whack is just part of the ipsec process.
>>
>> Fair enough, thats what I originally thought, but when it
>> didn't work, I
>> began to wonder....
>>
>>
>> >
>> > Your two confs, should be nearly the same, something like this...
>> > (But using your own keys, ips and subnets, etc...)
>>
>> My two confs were absolutely identical...I created the
>> ipsec.conf file on
>> a memory stick and copied it to both machines without change
>
> That's fine, openswan doesn't care which end is left or right.
> We just like to switch them so left is always local, and right
> Is remote, but it will work either way.
>
>> > Host A:
>> > /etc/ipsec.conf
>> > conn stmarys-office-net-to-london-office-net
>> > left=66...
>> > leftnexthop=%defaultroute
>> > leftid=@sheridan.london.goco.net
>> > # RSA 2192 bits sheridan.london.goco.net
>> > leftrsasigkey=0sAQNd...
>> > leftsubnet=172.21.3.0/24
>> > leftsourceip=172.21.3.101
>> > right=69...
>> > rightnexthop=%defaultroute
>> > rightid=@delenn.stmarys.goco.net
>> > # RSA 2192 bits delenn.stmarys.goco.net
>> > rightsasigkey=0sAQNs...
>> > rightsubnet=172.21.1.0/24
>> > rightsourceip=172.21.1.49
>> > auto=start
>> > /etc/ipsec.secrets
>> > : RSA {
>> > # RSA 2192 bits sheridan.london.goco.net
>> > # for signatures only, UNSAFE FOR ENCRYPTION
>> > #pubkey=0sAQNd...
>> > ...
>> > }
>> > # do not change the indenting of that "}"
>> >
>> > Host B:
>> > /etc/ipsec.conf
>> > conn stmarys-office-net-to-london-office-net
>> > left=69...
>> > leftnexthop=%defaultroute
>> > leftid=@delenn.stmarys.goco.net
>> > # RSA 2192 bits delenn.stmarys.goco.net
>> > leftsasigkey=0sAQNs...
>> > leftsubnet=172.21.1.0/24
>> > leftsourceip=172.21.1.49
>> > right=66...
>> > rightnexthop=%defaultroute
>> > rightid=@sheridan.london.goco.net
>> > # RSA 2192 bits sheridan.london.goco.net
>> > rightrsasigkey=0sAQNd...
>> > rightsubnet=172.21.3.0/24
>> > rightsourceip=172.21.3.101
>> > auto=start
>> > /etc/ipsec.secrets
>> > : RSA {
>> > # RSA 2192 bits delenn.stmarys.goco.net
>> > # for signatures only, UNSAFE FOR ENCRYPTION
>> > #pubkey=0sAQNs...
>> > ...
>> > }
>> > # do not change the indenting of that "}"
>>
>> Were your ipsec.secrets files created automatically, or did
>> you build them
>> manually?
>
> I used the method in doc/ which works the same as what you did.
> ipsec newhostkey --output /etc/ipsec.secrets --hostname xy.example.com
> chmod 600 /etc/ipsec.secrets
>
> And
> ipsec showhostkey --left
> To get the public part of the key for use in ipsec.conf.
>
>> > Make sure your keys copied into your confs are one big
>> line, they will
>> > wrap
>> > a few times on an 80 column terminal, and all conn lines
>> are indented with
>> > a tab.
>>
>> Yes, I did that.........
>>
>> Here's the ipsec.conf file, suitably anonimised:
>> version 2.0 # conforms to second version of
>> ipsec.conf specification
>>
>> config setup
>> interfaces=%defaultroute
>> # klipsdebug=all
>> #plutodebug=control
>> # plutodebug / klipsdebug = "all", "none" or a
>> combation from below:
>> # "raw crypt parsing emitting control klips pfkey natt
>> x509 private"
>> # eg: plutodebug="control parsing"
>> #
>> # Only enable klipsdebug=all if you are a developer
>> #
>> # NAT-TRAVERSAL support, see README.NAT-Traversal
>> # nat_traversal=yes
>> #
>> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
>> #
>> # enable this if you see "failed to find any available worker"
>> # nhelpers=0
>>
>> conn %default
>> authby=rsasig
>>
>> conn left-to-right
>> left=81.2.96.38
>> leftsubnet=10.0.0.0/24
>> leftid=@swan.blakes.homeip.net
>>
>> leftrsasigkey=0sAQNZqfnhuiIaYV/kEfWTNKaQbo5AwR8qqGzBk+YupzUt8D
> O616Etb/xXD2GD5fXnetzYHC/E/GXLZ6aSRyZYLhCXhAzl17zErPFec4PFdynKyAH6i0DIPh3H7n7J8t+bfeKldc+h1H/UKgFqwJsGm0p3BRo5oQ+bKq1SQVlt>
> +AVBTcHIUR+++XJVTNkUaBZ34vwggHs/jITQ8doKe0HdSgIIEn0qEPsUKuFlgg
>> PJDgFzWDmrXn61234B5zumJCsgxV3yLobIr1IiztPiVmuA1z7tqIyrvQ85xv+c
>> mCmvvoRWjCEZZWaGan4rPVz2zVqkBlgAYvXtzpDzplesCBntHseJ6BfVh3Twcd
>> niksIA/8j5Qod1
>> leftnexthop=%defaultroute
>> right=81.2.96.36
>> rightsubnet=10.0.1.0/24
>> rightid=@debian.blakes.homeip.net
>>
>> rightrsasigkey=0sAQOMVVGFuFKdtyEB7p0pLatx4oO3G1LB8Ln/KpkVbzHbs
> Uymgp0UUHTId3MJcMppOoL6PuwHMgJaO6mf9otSyxLzj/D1AhvdTaLsNZqKNOLmEhhJicrXMUp0wOACr1OeGqfiVLaT6tzyBki9nbhqUzlhtpYvRggHpYpS5aM>
> Na217isk45XyeCIDB6yKJDqdTzSBD81VWF07V82laYSDY/1YqKeZf/Kufh75vK
>> bCBeA/9jnBkCeRdDfxXCIf22vvy0jqewTi/b/tS8XWKe/wrEoHiNVv2uzBzbCa
>> V6fFeFnxroMcRig0exEe8Lwbq3vOxaCH9VXWJY072g+2kxB3YKHFXwqjMBd6ml
>> /kydskyN/vip7LZ
>> rightnexthop=%defaultroute
>> auto=add
>>
>> #Disable Opportunistic Encryption
>> include /etc/ipsec.d/examples/no_oe.conf
>
> Can't see anything wrong here, don't know why it's saying
> INVALID_KEY_INFORMATION.
>
> Found this in an old post:
>> You have more then one RSA key in there and it is picking the wrong one?
>> This happens when you use two entries like ":RSA" where no specific
>> identifier
>> is used with the particular rsa key. Easy way is to just have that one
>> key
>> in there, and comment out the other. Run 'ipsec secrets' to reread the
>> file.
>>
>> Paul
>
>> >> input: ipsec newhostkey --output /root/tmpkey
>> >> input: cat /root/tmpkey >> /etc/ipsec.secrets
>> >> input: rm /root/tmpkey
>
> Your ipsec.secrets file should contain only the private key for the local
> machine,
> if there was already a default key in the file, when you did this you now
> Have two keys, that's not good, delete the first one from your
> ipsec.secrets file.
>
> If that doesn't solve it, try the following.
>
> Can you do an ipsec --version and ipsec verify and show us the results.
>
> Peter
>
>
More information about the Users
mailing list