CheckPoint, Azure, Scaleset - not all traffic forwarded.

[vinceneil666]

Hi, I have a very strange issue with a scaleset in Azure. I have implemented these several times before, pretty much the same way, but I have never had this problem before.

The setup is as of now pretty simple, I have the scaleset up n running in a VNET that also has a VirtualNetworkGateway wtih a route based vpn to onprem. And there is another VNET peered in, that has UDR's pointing it to the internal load balancer fo the scaleset.

The thing is - near everything works:

• - I can ping both ways (from onprem serv to azure server)
• -Run SSH from onprem to a server in the peered vnet..
• - RDP works same way..
• Traffic is inspected by firewall and flowing normal. (ccap verifies this, I have traffic entering and exiting on the internal nic)
• Internet traffic from the peered vnet hits mye scaleset, natted, and works fine. Ping to internet, works fin.

But, for some reason - I am unable to getanything but the standard ports to work. :

As an example (this is the same for lots of other ports): I try to open port tcp1433 from a server in the peered vnet - the traffic enters my scaleset, is processed and then sent out towards the virtual network gateway. And then it is gone.... I am unable to see it entering the onprem checkpoint at all.... its just gone.  If I did tcp3389 or tc22 from, and to, the same IP's... it works..

So I just have an issue with some/lots of ports not working.. I have checked all NSG's and all policies, run debug.. It just seems to be lost in Azure somewhere ? 

Have anyone had this issue ? 

[_Val_]

@Shay_Levin can you pelase assist?

[Shay_Levin]

Hi, 

What is the routing on the Azure VPN GW , towards your peered vnet subnet ? 

The next hop of your Azure VPN GW towards your peered vnet subnet , should point on the front NLB 

[vinceneil666]

To the front NLB ? - I have a routing table attached to mye virt net gw pointing towards the inside / private load balancer. 

[Shay_Levin]

I have never tested a scenario in which you place the VPN GW inside the CloudGuard vNet

Why not to set a dedicated vNet to the Azure VPN Gateway and connect it with peering to the CloudGuard vNet?

[vinceneil666]

Yeah - I could do that, but I cant see that really helping me out, it will pretty much change a bit on how I do my routing - and my routing is working fine. I usually see this setup at most of my customers - the vpn gateway on the same vnet as the CheckPoint scale set / or just a "regular Cloudguard fw.

This is the log, this is me running telnet on different ports from one of the CheckPoints in Azure. The thing I want to see here is of course the DECRYPT icon, as seen on line-3 from the top. I have tried the same test with the traffic beeing allowed on the on-prem firewall to..same issue..

If I telnet on port tcp3389 - the traffic goes over the tunnel and is decrypted.

If I telnet on tcp22 or tcp1433  (or tcp 6566,,tcp6666, tcp9189...etc etc) it do not seem to hit the tunnel at all... there is no decrypt. Same ip used for src and dest in all tests.

I have tried editing the NSG to any any, I have removed the NSG completley. I have done /32 routes in the UDR - done /24 and /8's. But no go....

The very very weird thing, is that traffic FROM on-prem, TO the example server in Azure - works fine..all ports works fine.

 

[Shay_Levin]

Just to try to understand where the problem is , what about create a VM in the Cloudguard vNet, external subnet  , and try to open connection from that vm to the on prem server on different ports ( the cloudguard network external subnet needs to be part of the encryption domain in that case) 

You can do the test  form the cloudguard gw as well , For eliminate other potential issues , do it from a vm will be better.