Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Abhishek_Singh1
Contributor
Jump to solution

Azure VMSS R80.30 issue

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

0 Kudos
1 Solution

Accepted Solutions
Dmitry_Gorn
Employee
Employee

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

 

View solution in original post

5 Replies
Abhishek_Singh1
Contributor

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

0 Kudos
Daniel_Goldenst
Employee Alumnus
Employee Alumnus

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

0 Kudos
Abhishek_Singh1
Contributor
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 ??
0 Kudos
Matthias_Haas
Advisor

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

0 Kudos
Dmitry_Gorn
Employee
Employee

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

 

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.