VPN

Hi,

Is there any method available to define the AES/Rijndael key length for an IPSEC Phase 1 negotiation in M0n0 1.33/1.34 as I have a specific need to define this for setting up a VPN via m0n0 and another endpoint firewall which is not under my control?

When setting up a VPN between the two networks, Phase 1 negotiation is requesting from the endpoint using AES256 (which I cannot enforce to get changed to AES128 from the endpoint firewall team which I know works fine with standard m0n0), while m0n0 requests AES128t. I am also unable to use 3des or any other encryption methods for other security reasons also requested by the endpoint firewall team, hence my query.

An old post suggested that it can be possible by editing the ipsec_vpn_edit.php file as per post http://m0n0.ch/wall/list-dev/showmsg.php?id=0/06 to have AES256

But this is slightly different in 1.33 as it looks like it is now embedded within "guiconfig.inc" as the following...

Code:

$p1_ealgos = array('des' => 'DES', '3des' => '3DES', 'blowfish' => 'Blowfish',
'cast128' => 'CAST128', 'aes' => 'AES');
$p2_ealgos = array('des' => 'DES', '3des' => '3DES', 'blowfish' => 'Blowfish',
'cast128' => 'CAST128', 'rijndael' => 'Rijndael (AES)');

Would editing the inclusion file above to have the following defined instead allow 256 bit to work with the version of racoon supplied on monowall ver 1.33/1.34 and still retain the ability to specify AES128 for other uses?

Code:

$p1_ealgos = array('des' => 'DES', '3des' => '3DES', 'blowfish' => 'Blowfish',
'cast128' => 'CAST128', 'aes' => 'AES', 'aes 256' => 'AES (256)');
$p2_ealgos = array('des' => 'DES', '3des' => '3DES', 'blowfish' => 'Blowfish',
'cast128' => 'CAST128', 'rijndael' => 'Rijndael (AES)', 'rijndael 256' => 'Rijndael (256)');

I could see the above using the exec.php method to download the file held in

/usr/local/www/guiconfig.inc

If the above is possible, how would I go about overwriting the above file on the m0n0wall device to allow the config to remain should a reboot be required?

This is using the embedded image on an ALIX 2d3 not generic/pc version. Also, would there be any issues using this on an ALIX 2d3 device if possible?

Any help would be most beneficial for me.

Thanks

If you make the change as you have outlined, it should work fine.   manually edit the guiconfig.inc  by downloading, editing and uploading, then moving into the right directory.

if it works as expected, detail the change back here, and I'll patch in 1.8

Thank you for the reply... but forgive my silly question, how would I go about moving the file?

Does uploading the file place in a specific location and would I need to make any changes to permissions, etc?

I'm assuming by the exec.php, but have not used the exec.php before now so have very limited "experience" with it.

Thank you

yes, use exec.php

there is an option to download and upload a file.

download /usr/local/www/guiconfig.inc , edit it, upload it, then in exec.php  enter

Code:

chmod a+rx /tmp/guiconfig.inc

then

Code:

mv /tmp/guiconfig.inc /usr/local/www/guiconfig.inc

worst case you will need to reboot if it all goes wrong.

you can check your config after making the changes etc.  by

Code:

cat /var/etc/racoon.conf

Hi,

Just to let you know that when the revised inc file is updated on m0n0 (thankyou for instruction), the IPSEC options appear to display the changes and the racoon.conf file is updated with the revision to AES key lengths when saved.

But we are having some trouble testing the tunnel properly as when we apply some config and a reboot is required, the guiconfig.inc file appears to be either overwritten or reset on any reboot.

When the inc file is re-applied as per your info the options re-appear correctly to change the config and resave.

Is there any other settings needed to ensure the inc file is not overwritten on reboot? I'm guessing there is some sort of Image file which re-creates the defaults on a reboot and then the config applied after?

Otherwise, its looking promising to add AES256 to m0n0wall as standard 
Cheers
John

Changes to the file system made via exec.php are not permanent and are lost upon reboot.

Doesn't the latest beta r541 provide the AES256 you are looking for?

yes,  I added in the changes last night, as per John's post.

however, the changes should be persistent across reboots with what you have done,  the file you have changed just controls the display of options, once you selected the new option and applied the change, it's written too your config.  the way the VPN code works, it takes this setting from the config and applies it, so after a reboot, you should see your racoon.conf has the right settings ?

Perhaps I misread the OP's message that some or all of the uploaded changes were lost on reboot?

Moot point if the latest r541 incorporates the requested changes.

Hi,

Yes the racoon.conf file is updated with the changes when the guiconfig.inc file has been uploaded and is retained upon reboot, but if the m0n0wall is rebooted (for whatever reason) and the guiconfig.inc is reverted back to the base image, what would be the consequences of the racoon.conf file if I edit any other IPSEC tunnel (for what ever reason) that does not use AES256 or even the original tunnel that did need AES256?

Isn't the racoon config file then re-written from scratch with whatever options are available at that time of the save for all tunnels? (i.e. does just the individual tunnel get updated, or does the whole file get effectively wiped and then rebuilt?) If so, wouldn't the tunnel requiring AES256 become corrupt or reverted back to AES128?

It will be something that can be tested on Monday for our 1.33/1.34 setup, but unfortunately we are unable to use the Beta m0n0wall as using AES256 is a requirement for a live network.

If the settings are wiped and corrupts/disrupts the config, then the only possibility I could see working would be to ensure that any future updates to any of the IPSEC tunnels would require the guiconfig.inc to be re-uploaded prior to saving the tunnels to ensure the racoonf.conf file has the correct parameters saved within and retained upon any reboot. Of course up until a production release of M0n0wall incorporate AES256 by default.

Will test the above scenario and report back the outcome next week.

Thanks
John

It will be something that can be tested on Monday for our 1.33/1.34 setup, but unfortunately we are unable to use the Beta m0n0wall as using AES256 is a requirement for a live network.

From what I can see m0n0wall 1.8b r541 is AES256 capable and that enhancement seems to have been added to address the concerns of this thread.

What am I missing?

He dosen't want to use a beta version of m0n0wall in his production environment, so he is trying to get a stable release to work with his needs, I was surprised myself m0n0wall doesn't support AES256 until the recent beta.

Yes. I didn't want to use a Beta system in Production (also as recommended by the site not to use beta in production anyway) just in case there are any security holes, etc... and i'm sure the endpoint Firewall Team would not be too pleased having their commercial firewall connected to a Beta product!

But just to confirm some good news that the mod to the guiconfig.inc for using AES256 does correctly allow AES256 for Phase 1 negotiation once the racoon.conf has been saved. This is successfully connecting our M0n0wall to a Checkpoint commercial firewall and does not seem to hinder the ALIX 2d3 when passing traffic for the higher encryption.

Tunnel also comes up correctly when rebooted, but obviously the options will not be shown unless the guiconfig.inc is re-uploaded to allow changes.

So the method to edit any IPSEC tunnels after using the modded inc file is to remember to re-upload the guiconfig.inc file (if there have been any reboots and has reverted back to default) to ensure the updates parameters are correctly added to the racoon.conf.

Happy days and another string to the m0n0wall bow for features!

I had to put a few in production due to unsupported hardware.  Now I have a fewe more because they have been so solid, and the updates are nice!