I'm not aware of anything Juniper specific, but I feel your pain because I've had to go through this exercise myself before!
Probably the single largest aggrivation is defining all of the network object values (IP adresses, hostnames, and such like) and if you can get to grips with the CLI environment you can find yourself at an advantage.
The CLI pre-dates the GUI for this product by a number of years - I can remember v5 where none of the DNS & Mail configuration could be performed through the GUI - and all of the Firewall configuration specific commands are prefixed with "cf". If you connect directly to the box, or run an ssh session you can enter "man cf" and the whole adventure starts from there! I think there are any number of KB articles available. The key, of course, is knowing the commands you need to use.
For example, the command for creating an IP address object is:-
cf ipaddr add name=My-Test-IP ipaddr=192.168.1.1 description='Test IP address'
or if you don't want to add a description
cf ipaddr add name=My-Test-IP ipaddr=192.168.1.1 description=''
If you create a plain text file containing these entries (minus the "cf" part) like so:-
ipaddr add name=My-Test-IP ipaddr=192.168.1.1 description='Test IP address 1'
ipaddr add name=My-Test-IP2 ipaddr=192.168.1.2 description='Test IP address 2'
ipaddr add name=My-Test-IP3 ipaddr=192.168.1.3 description='Test IP address3'
...and so on....
and copy this file into the /home/<username> directory you can then use the following command to import the whole lot in one go:-
cf -f <filename>
If you are able to extract this information from the Juniper box into a text file you should then be able to manipulate it into the format required by MFE.
The rest, as far as I know, is then down to someone configuring the services, rules, and such like by hand. But, I hope this gives you something to start with.
Like Phil said the fastest way to do this is with the 'cf' command on the CLI. I wrote a bit about the cf command here on my blog.
There is no tool for converting Juniper configs directly, no. I just asked Product Management again but I've never heard of such a tool.
Honestly, if you build the policy by hand you will find things (rules, etc.) you don't need. You will also learn how to use the firewall much faster than just 'all of a sudden' having a converted policy and then trying to figure out what the heck happened to it (converted policies are always, always going to be messy).
Thank you guys.
I will start using the cli to import all the network objects and create all the policies later by hand. The cli commands above will help me a lot.
There are other types of object available to you, so rather than sifting through the man pages to find the format of each (though it is a useful learning exercises), you can create a single instance of each of the main object types (IP Address, Hostname, Domain Name, Subnet and Netgroup) and use the "cf <command-type> query" command to output the format of each:-
IP Addresses - cf ipaddr query
Hostnames - cf host query
Domains - cf domain query
Subnets - cf subnet query
Netgroup - cf netgroup query
As previously mentioned, the input for these commands is exactly what you see, minus the "cf" bit. Create a text file containing the entries in question (I, personally, have tended to opt for individual files for each object type) and you can then use the cf -f <filename> command to perform a bulk import.
If you do want to take a look through the man pages for yourself there is a specific format, as it seems the Unix man function doesn't like spaces.So, man cf will take you to the section relating to the top-level cf command. Even though the command for creating an IP Address object is cf ipaddr, the man page for the command is actually man cf_ipaddr
I agree with Sam in relation to transferring rulesets. Yes, if the existing ruleset is very large it can be a painfully tedious exercise to do by hand. But, on more than one occasion I have presented a customer with their newly configured McAfee Firewall Enterprise appliance and while taking them through the rules I've been told "Oh, we don't need that one any more, or that one, or that one....". It would probably be a good idea to audit the existing ruleset first, run through it with the applicable parties and weed out the redundant rules before configuring the new appliance.
On a couple of (admittedly rare occasions) I've encountered a situation where the firewall to replace has been managed by so many different people in the past that no one really knows what it is actually doing and the decision is taken to start with a blank slate. The key services/functions are agreed and the Firewall rule set is configured accordingly. As and when new requirements are identified, new rules are added. But as they are being added by the same team, they (at least to start off with) will remain relatively organised.