I have been out of the loop for a few months, so one of the McAfee guys may be able to give you an more authoritative answer. But, I have a feeling you may find yourself needing to re-install if you want to switch between routed and transparent mode.
Certainly, I think you'll find that the Firewall only looks for a quick start file if it is booting-up for the first time from a clean software installation - it realises that the basic config has yet to be applied and then goes in search of the quick start config file (or if you have a screen and keyboard connected will prompt you to start the initial set-up process manually - which, because when I first started working with Firewall Enterprise was the only option, tends to be the method I still use). Otherwise, if a configuration already exists, it will simply boot as normal. So, I don't believe you can take an existing installation, complete with a configuration, and try to re-apply a quick start config file without first re-installing the core Firewall software.
Thanks for your reply Phil. The product guide mentions hybrid mode, so my assumption is you could swap between either mode without a reinstall.
"The firewall can be simultaneously configured with a single bridge and additional routed interfaces.
The following figure illustrates the firewall configured with a transparent interface and a routed
interface. In this example, the firewall protects the internal and DMZ networks from each other and
from the Internet."
Just to clarify, I'm not necessarily wanting to use the quick start file. If someone can provide the config changes required to make bridged mode work, then I'm more than happy to follow that.
But, while the statement you have included in your reply is essentially correct - you can have a bridge interface and then employ any of the remaining interfaces in routed mode - the only reference I can see to configuring bridge mode in the admin guide is in the section concerning initial deployment (p29). I can't seem to see anything that suggests you can retrospectively turn a configured bridge back into individual routed interfaces, or anything that indicates you can create a bridged pair after the initial configuration process has been performed.
Raise a call with McAfee support and they'll be able to provide you with a definite answer.
Thanks for replying again Phil. I eventually gave up the search and did as you suggested which was a reinstall. Wasn't as painful as I was expecting it to be.
Turns out using the QSW config file for bridged mode still didn't get the firewall to work in my environment. So I've just gone back to routed mode.
You can look at this answer here for the commands that can be used to troubleshoot a bridged/transparent setup. If you are trying to setup a bridged firewall in VMWare then read this thread. The most common issue, by far, is that you have the cables plugged-in incorrectly on the firewall. At the lowest level a bridged interface sees ARP Requests and ARP Responses from devices in the network of its IP address/mask on that interface and then builds a bridge table based on the physical interface which 'saw' the ARP Response. You can say the firewall does 'proxy ARP' in this setup since it passes ARPs across physical interfaces and zones (which it cannot do with a standard interface). The machine 10.1.1.1 says "ARP WHO HAS 10.1.1.2," this hits the firewall on interface em1, the firewall passes this ARP request across the bridge out em0, gets a response (hopefully), and then modifies its bridge table to say "10.1.1.1 is off em1, 10.1.1.2 is off em0." Each interface in the bridge has a different zone and the firewall rules are, usually, directional (from internal zone to external, for example), so if you've plugged the interfaces in 'backwards' this will cause the firewall to add the IPs to the bridge table backwards and thus the rules won't work. Flipping the cables and flushing the bridge table will fix that.
You can add a bridged/transparent interface to any firewall with standard interfaces. If you wanted a firewall with standard interfaces to have only a transparent interface containing the current two standard interfaces in the bridge you can configure this. Simply create a new transparent interface, select the current two standard interfaces you already have set up as the two bridge members, and then configure the current internal IP address of the firewall (or a new one in the same network) as the IP of this bridge. Now when you Save this it will erase all the IPs on the current two standard interfaces (both internal and external) and disable them and then enable the bridged interface with this new IP. This will prevent traffic from flowing through the firewall, however, because the IP address of this bridge interface is no longer in the same network (most likely) of the firewall's default route (which was in the network of the external interface, whose IP address is now gone). The firewall still has to do routing in whatever mode it's in, standard, bridged/transparent, or hybrid, so when its IP address is not in same network as its default route it cannot forward traffic on. To get traffic to flow through the firewall you either change the default route of the firewall to be an IP in the network of the bridge (this is what you should do, as the point of the bridge is to control traffic between devices on the same subnet) or simply add an alias IP to this bridge which is in the network of the default route (you can add the old external IP of the firewall as an alias on this bridge). If you do the second one you'll have to have some of the 10.1.1.x clients and the 192.168.1.x default-router plugged into the same switch on one side of the bridge. Or, you can add a new standard interface with an IP address in the network of your default route. The clients on the two sides of the bridge then talk to each other through the bridged interfaces and talk to the anyone else through the standard interface.
There may be some things I missed here when I think about it. If the default route of the firewall is on the same side of the bridge as some of the clients (which it would be if it's in the same network as the bridge IP/mask) then these clients are going to send traffic that is external to the firewall to the same interface and zone from which it's going to leave (the traffic source zone is client2 let's say and the destination zone is also client2, since the default route is on the same side of the bridge). This is called intrazone-forwarding and must be enabled explicitly to 'bounce' traffic off the firewall, essentially. Come to think of it intrazone-forwarding seems essential in a bridged setup where all the IPs are in the same network, although that's not stated anywhere. It would take some testing to confirm that this is always true. Something to think about at least.
Remember: If you have 10 clients on the same network plugged into the same switch and you want to divide these in half to control policy between 5 on one side and 5 on the other (or whatever number you want), you must unplug 5 of them from the switch and introduce a new switch to the setup. The old switch is plugged into one NIC on the firewall (one side of the bridge) and the new switch is plugged into the other NIC which makes up the bridge.
If you have any questions at all let me know.
Wow, thanks for the detailed response sliedl. I wish it had come a few weeks earlier as I'm no longer working on site. I have the firewall in routed mode and working, so I'll refrain from tinkering with it again.
But just to explain my setup (or desired setup), I was wanting to put the firewall between the internet router and the internal switch to monitor and control traffic to and from the internet.
Before hand the network looked like this: pcs&servers -> switch <- internet router <- internet
I wanted to introduce the firewall like this: pcs&servers -> switch -> firewall <- internet router <- internet
I wanted to set it up in bridged mode to reduce the amount of config required. I had the internal switch plugged into the internal port and the internet router plugged into the external port. Those ports were then bridged together.
A few things you mentioned caught my eye. With bridged mode, I had the default route pointing to the the internet router (lets say the network is addressed 192.168.1.x with the bridge address as .1.200, and the internet router as .1.254). Is that correct?
Also, would intrazone forwarding have been necessary in my setup? The internet router was the only device in the external zone. All clients and servers were in the internal zone.
When you put a transparent firewall between devices you're supposed to treat it "like it's not even there." The devices internal to the firewall still point to their same default route, in this case 192.168.1.254. The firewall also points at this router for its default route, just like you had, as it must always have a default route that it can reach. You would not have had to turn on intrazone-forwarding in your case.
You know, thinking about it more, if you had clients on the same side as the internet router and they were plugged-in to the same switch they would simply ARP and send their traffic to the internet router; it would not 'bounce off' the firewall since they are on the same switch (duh, I should have thought of that). If you had two sets of PCs/servers and you wanted the firewall to filter traffic between them and you wanted to filter traffic from the internet also you'd add a third interface to the bridge and put the internet router off one interface in the bridge, one set of PCs off a different interface and the servers off yet another interface. You can also use VLANs instead of multiple switches.
Your setup looked perfectly fine. The fact that it "didn't work" could be simply that DNS wasn't working correctly, something simple like that. Tcpdumps, audit, 'ifconfig bridge0 addr,' etc., would have solved the problem I'm sure.