Azure VMSS R80.30 issue

[Abhishek_Singh1]

Hi Mates, 

I have deployed the VMSS solution with custom blades and everything looks fine from management, gateway, policy perspective. 

On the day of actual cutover of traffic from traditional cluster to the VMSS Lb, it failed really bad 🙂 .

The traffic we are testing is EAST - West, with no NAT needed. 

On investigation, I could see the the initial traffic reaching the destination sever and response coming to my VMSS gateway... But for some reason the response / reply is not reaching the source machine. 

( and I know it's not lb persistence issue, since added persistence with client up &port -> all the traffic is passing thru one gateway) 

I have checked all the routing, NSG, etc --- everything is pretty much same, since we are just changing the routes to point to the new vmss lb, instead of old cluster lb ... 

I can see that eth0 - in vmss instance has ipforwarding as false in Azure ,  also eth1 doesnot has the default NSG attached... Is this correct?? 

Anyone faced same issue?? Do let me know if I am missing something in the VMSS deployment.

Tx, 

Abhishek

[Abhishek_Singh1]

Just an update, since un the template I could see etho - is false for ip-forwarding in Azure VMSS setting. 

I changed the routing to exit from eth1 instead and it worked. 

Can someone from Checkpoint development team can confirm is the setting for eth0 is the standard going forward, if not how can I change that in Azure VMSS, since changing the route will be an design change for our organization, we will be interested in getting the routing working thru eth0 preferrably. 

Tx, 

Abhishek

[Daniel_Goldenst]

Hi,

According to our VMSS deployment guide, our architecture is based on the fact that East/West traffic inspection is done through ETH1 only.

Please note that Internal Load Balancer should be connected to ETH1 of the scale set and all customer’s back end application and VNEts should point to this ILB via UDR

[Abhishek_Singh1]

Yes , I have seen that in deployment guide . But for some reason , in our environment eth0 is also used to connect to internal VNETs .

Is there any work-around / tweak we can make use of may be in Azure / Checkpoint to make it work ??

From the pcaps run on the VMSS gateways , I could see any traffic exiting from eth0 , is picked up by the external LB -- by default . Is there a way to change is behavior ??

[Matthias_Haas]

what does the Routing on your FW look like ?

Make sure to have a route for the VNETs/Azure network with the first IP of the subnet, eth1 is connected to, as the gateway

[Dmitry_Gorn · Accepted solution]

Hi,

Our VMSS solution does not support handling E-W traffic via eth0. The External Load Balancer is connected to eth0 and the Internal Load Balancer is connected to eth1 and used for internal traffic.

Since internal E-W traffic's next-hop should be the ILB's frontend IP, traffic will enter the Check Point GWs on eth1.

In addition, using eth1 and Azure's internal load balancer (with HA ports) for E-W traffic allows forwarding E-W traffic without doing Source NAT.

I suggest to reconsider the architecture. If the problem is subnet address spaces you can consider redeploying the VMSS solution and switching the subnets of the VMSS frontend and backend.

Regards,

Dmitry