what are the advantages of using Bridge mode? Can I use Bridge and Routed modes on the same gateway?
Typically people will use Bridge Mode in situations where they cannot change the routing topology (or don't want to for various reasons).
You can use both modes on the same gateway with one important limitation: traffic cannot pass through the gateway twice.
If you're using VSX, you cannot pass through the same Virtual System more than once.
Can you expand on "If you're using VSX, you cannot pass through the same Virtual System more than once."?
I am about to do a job with VSX and mixed VS' in routing and bridge mode and this could be pertinent.
Pretend each VS is a physical gateway and follow the bouncing packet.
If it passes through a given VS a second time, it will be dropped.
Perhaps another example to use bridge mode is when you want inline IPS/IDS without adding in IP information . . basically vlan to vlan with a open FW policy and explicit IPS policy. I am doing some investigation on how to do just this thing with multiple VS's . . 1 for each customer if you will. Add a new customer, spin up a new VS with a new policy and 2 new vlans.
Since I am not ware of a current IPS provider that does Virtual ips instances on a appliance and need a agrregate throughput of at least 10GB, the above solution makes the most sense.
These are some of the examples:
You have a /24 network that contains a subset of hosts that you want to protect with the firewall, IPS, etc., (i.e. for limiting probability of lateral threat propagation).
You can either split it in multiple VLANs or are already have those hosts connected to different physical switches (i.e. departmental network with each switch serving one row of traders, for instance).
Connect each segment through bridge to your core router (and, subsequently, perimeter firewall).
You can have same IP network riding on different VLANs on each side of the bridge which may also be advantageous if, for instance, same VLANs on different switches were assigned to carry different networks and you need to span those.
If you are not assigning IP to the gateway or VS in a bridge mode, you can use it as DDOS limiter, as it can drop a lot of bad traffic without being addressable, before the rest reaches your routing gateways.
Do I loose "security inspections" in bridged mode? does it inspect traffic, including payload, with all blades and all layers "up to 9 lOl" as it does in routed environment? All responses so far address VS/VSX configurations only?
Can I have routed and bridged mode on the same platform/appliance that will have to terminate VPNs and serve internal VLANs/networks at the same time?
There are some limitations. As per Dameon's post above:
"You can use both modes on the same gateway with one important limitation: traffic cannot pass through the gateway twice."
So yes, you can use same hardware for both with this caveat.
As to comparison of the features, these screenshots are from VSX VS, but are applicable to the physical appliances as well, if one of them is ONLY working in a bridge mode and another is in routed mode:
In “Virtual System In Bridge Mode” section, you’ll find comprehensive description of its capabilities.
Here are the “traditional” and bridge mode VS’ side-by-side (R77.30):
See which blades are available (or not) in each case.
Note, that as strange as it sounds, you CAN assign IP address to the bridge, which makes a lot of "conventional" functionality possible.
As per Installation and Upgrade Guide R80.10 (Part of Check Point Infinity) , which I encourage you to read, these are the differences between physical and VSX VS bridges:
As far as I know, you can't put an IP on a VS bridge though.
You can (as per screenshots above), but it is used only for VS monitoring.
Functionality constraints are as per table shown.
Essentially, in VS it is limited to Firewall, IPS and Threat Emulation (although I am not sure how practical it is to run that last one in VS).
URLF and App Control will not work effectively, since there is no HTTPS inspection capabilities.
These blades may work if you are employing external SSL decoder, such as Gigamon or Ixia and piping unencrypted traffic through it, returning it to SSL acceleration appliance for re-encryption on the way to its destination.
But this last statement is purely conceptual, as I have not tried it in practice.
Retrieving data ...