Management Interface Setup with PBR

[jberg712]

I've been tasked with developing a management network and segmenting certain traffic and that task would potentially include our Check Point environment.  We have distributed environment with 1 Management server and 2 Gateways.  The 2 Gateways are located in 2 separate physical and logical locations so there would be some routing involved.  Ideally, if possible and not too complicated, while each Gateway has an interface for normal traffic, i'd like to add a management interface for SIC, policy pushing, log traffic, Gaia web/ssh management (again, if feasible and possible).  (i.e  GW1 - LAN:  192.168.1.1/24 - MGMT: 10.10.10.1/24 | GW2 - LAN:  192.168.2.1/24 - MGMT:  10.10.11.1/24) 

I've looked over several articles and other Check Mates posts about this.  I know that the GW shares the routing table.  I've seen where people are using MDPS and VSX to accomplish this, primarily with a cluster.  We're not clustering our GWs.  I'm not even familiar enough with Clustering or MDPS.  I'm not sure that would fit this scenario.  And I know there's not a dedicated separate management routing table

I'm curious if it's possible to utilize the Policy Based Routing (PBR) to accomplish this?  Has anyone attempted or tried to set something up like this to override the standard routing table.  It seems just using the normal routing table while communication can happen on these interfaces, there seems to be some dependence on the LAN interface or something for communication to happen.  It's very strange how it behaves.

And I'll ask this, are we just better off utilizing the LAN interface as the management interface to keep it simple?  The only caveat I see to this is any possible overhead to the management/log traffic along with all the normal actual traffic that needs to happen on the same interface.  I know it's probably been done like this for years but i'm curious also if that has ever been a problem?

[simonemantovani]

In my opinion you can use PBR (I've configured PBR in a maestro environment for the management interface of the Security Group); I'm not a fun of PBR, but it's simpler than MDPS, only because you can add or remoteve the PBR configuration with less impact than configure MDPS.

From a technical point of view, MDPS is more sophisticated than PBR and quite similar to the approach ued by other Firewall's vendor.

[jberg712]

Thanks Simone.  This is good do know.  Could you elaborate a bit on what it looks like?  I'm familiar enough with how it operates from a Cisco perspective (i.e. building your ACL, setting the PBR and destination and applying it to an interface).  The way Gaia seems to do it it wants you to build a table with destination route and then a section with policy rules where I can select a table.  I'm assuming I would want to build a table (i'll call it Management).  This table is the action it takes.  Then I build a policy rule to match the traffic.  How does it get applied to the Mgmt interface?  I can see where you can MATCH the interface, but it seems all i'm doing is stating a matching parameter and not necessarily applying the PBR on the interface.

[simonemantovani]

This is how I configured:

When a rule is matched than the nexthop configuured in the table is used.

172.28.1.4/32 - IP address of the management interface

DEFINE THE TABLE
set pbr table Mgmt static-route default nexthop gateway address 172.28.1.1 priority 1

DEFINE THE PBR RULES AND ASSOCIATE THEM TO THE TABLE
set pbr rule priority 10 match from 172.28.0.138/32
set pbr rule priority 10 match to 172.28.1.4/32
set pbr rule priority 10 action table Mgmt
set pbr rule priority 20 match from 172.28.1.4/32
set pbr rule priority 20 match to 172.28.0.138/32
set pbr rule priority 20 action table Mgmt

[jberg712]

So you are doing 2 separate rules essentially for bi-direction route processing.  1 for the ingress and 1 for the egress?  To and from your gateway and to the management server?

[simonemantovani]

The rules are configured to match exactly the traffic based on the source (FROM) and the destination (TO), so when a connection from 172.28.0.138/32 is arriving to 172.28.1.4/32 (MGMT IP address of the firewall) then the firewall will use the nexthop 172.28.1.1

[Chris_Atkinson]

Last I checked PBR still had a limitation that it couldn't be used for locally originated traffic.

Please check sk167135 for details.