Modifying Public Interface Topology

[Neck]

Sorry for the long post!

I am decommissioning an old ASA HA pair. I have my Check Point HA ClusterXL (R81.10 Take 177) in place and have migrated all my site-to-site VPN tunnels over to it. My Check Point Cluster has its own /27 public IP block and the old ASA HA pair has two /27 public IP blocks. My ISP is going to routed those two /27 blocks over to my Check Point cluster so I will end up with all three of those /27 blocks available on the Check Point side.

My first thought was to just create sub-interfaces (aliases) under the existing public interface but I looked into that and found that is not possible with ClusterXL. I opened a case with Check Point and they said I could create vlan sub-interfaces but looking into that I would obviously need to create new vlans and make changes on the switches as well and we don't want to have to do that.

In order to get my Check Point to accept those two new /27 blocks, Check Point then recommended that I just modify the existing /27 public interface with a larger mask that would encompass all three of the /27 blocks that will belong to us. I thought that was perfect and would solve my issue so I checked and a /20 would encompass the three subnets.

For example: My Check point is currently 126.22.149.96/27. My ISP will be re-routing 126.22.149.32/27 and 126.22.157.64/27 from my ASA to my Check Point. If I change my existing mask to a /20 on my current interface it would encompass those other 2 blocks as well (and obviously more addresses that are not ours).

I called my ISP just to make sure that is okay and they agreed it should work on the Check Point side so that they accept all three of those subnets as part of their topology. The ISP was concerned though about what might happen if the Check Point sent ARP requests out for all the other IP addresses in that /20 that don't actually belong to us. They are going to look into that and let me know if it would cause them an issue.

My question, does anyone know if this is an issue or of a better approach I should be taking?

Thanks and sorry for the lengthy post!

[the_rock]

Just make sure there are not overlapping subnets/routes.

[Wolfgang]

Another idea… use one of your /27 subnets for you new Check Points cluster and the other subnets can be routed from your ISP to your new cluster. No change of the subnets is needed only some routing done by the ISP. You can use the routed subnets on another interfaces or only for NAT stuff.

[Duane_Toler]

There are several problems with this.

1. Your /20 is way too large for the 3 /27 subnets. You will be answering for networks you don't own.

2. You can't cleanly summarize 3 /27 subnets into any single subnet (cleanly).  The closest you can get is a /25, but then you're still pretending to answer for a fourth /27 that you don't own.  This is a problem if you are trying to reach an external site that lives within that fourth /27.  Nothing on the Internet is going to be sending packets to you for that 4th subnet; it's just a problem for you.  The best you are going to get is a /26 (for two of the /27 subnets), and still have the third /27 that doesn't summarize.

3.  How is your next-hop gateway handling these subnets?  If it is expecting 3 distinct /27 subnets, all addressed locally, then you have 3 broadcast domains with 3 different next-hops.  Who controls the configuration on your next-hop gateway (router, switch, whatever it is)?

4. Is the ISP collating these 3 /27s into any type of single network for you and routing them to your next-hop gateway?

Separate from all of the above:  How do you intend to utilize the addresses in these subnets?  Are you just using them for Hide or Static NAT?  Are you expecting to answer for an IP in these networks (e.g.: assign one of these addresses to your firewall interfaces)?  Depending on how you plan to use the IPs, that will determine how you can configure the firewall for them.  There are some tricks you can do (that many don't know about), but it's very dependent on your usage plans and who controls the configuration of your next-hop gateway device.