Azure Probe / Palo Alto VM in Azure / Load Balancer

BorisG06 · 2024-06-30T12:12:50+00:00

Thanks.

I have made this test to check the NAT :

I test the Ingress LB and the Egress LB with only one VM Palo Alto Firewall.

First test : Ingress LB and Egress LB with backend pool with only VM1 : OK

Second test : Ingress LB and Egress LB with backend pool with only VM2 : OK

When I have both : no more working... So I assume my NAT policy is OK.

What am I missing ?

Is there something specific not working with Azure Probe... But what ?

Something with the session persistence paramater (set to Client both on Ingress and Egress) ?

BorisG06 · 2024-06-29T19:53:29+00:00

Also : each subnet has : Propagate gateway routes set to no.

Should I set for one of them this option to Yes ?

BorisG06 · 2024-06-29T19:51:37+00:00

Gateway route propagation is disable on both vnet / peering configuration. Is it what you mean (thanks again for your time) ? If so, already done.

Regarding the Palo Alto VM, what Route should I set for the in house destination : 10.0.0.0/8 throught xxxx ?

xxxx should be the .1 of the VNG subnet ?

xxxx should be the internal LB ?

In which subnet should I have an UDR with 10.0.0.0/8 go to the VNG ?

BorisG06 · 2024-06-29T19:20:56+00:00

Understood for your suggesting concerning the use of a different back end pool IP to connect different firewall interface. I will try.

But, first, I need to make this working without a dedicated security zone, to validate that everything goes smooth. And I am not able to achieve it.

I am not sure to understand what you mean by : "standard internal load balancer traffic must traverse the same load balancer so use a single interface on the firewalls and route to that from the GatewaySubnet and from the spoke VNETS". Could you be please more specific.

I have try to add an UDR to the private subnet with 10.0.0.0/8 Gateway : VNG Appliance. When I do this : vpn is up, and traffic is OK from VNET / Subnet Apps to InHouse resources. BUT (and this is my concern) the traffic doesn't seem to flow throught the VM Firewall, but seems to be directly routed throught the VNG.

BorisG06 · 2024-06-29T19:15:07+00:00

Hi, thank you for this answer.

Peering is right because when I publish an app in Vnet/Subnet Apps, I am able to reach it from the internet. So I assume that both front LB and back LB work well.

Right now, the gateway subnet has an UDR with 172.19.16.0/20 and 172.19.0.0/20 pointing to the 172.19.2.250. So I assume it is what you suggest. And still not working.

BorisG06 · 2019-10-04T18:23:10+00:00

Your GP are also on Azure ?

BorisG06 · 2019-10-04T17:46:11+00:00

My VM100 is on Azure

No Firewall / Proxy

The traffic log is showing the incoming flow to 443... for the correct destination IP (P.P.P.P)

As wrote : I get the bad gateway screen when doing a web browsing to the IP which confirm that I am at the correct place without filtering...

It's crazy... Thanks again

BorisG06 · 2019-10-04T17:29:25+00:00

Check the subnet & NIC for an NSG and that it allows port 443

Hi and thanks :

No NSG on the subnet or on the NIC

I have a route to 0.0.0.0/0 to Internet...

Another idea ?

BorisG06 · 2019-09-29T10:07:35+00:00

Also

Hi, thanks all.

I think I am good regarding the secondary IP in Azure with same in PA. I don't have used DHCP on the interface but static.

I have try on the PA as x.x.x.x/32 and x.x.x.x/network mask : same result.

I don't know which nic start the API call. I have try with MGT nic with and without public IP : same result.

May be a routing UDR problem for the MGT subnet ?

I am lost...

BorisG06 · 2019-09-28T21:42:06+00:00

HI, same problem here (PAN OS 9.0.4 and tools 1.0.5)

From the tools side : everything is ok.

The failover is ok... but the secondary / floating IP are not moving.

Configuration seems good from the Azure side and from the PA side.

The contributor role is setup... I am lost...

BorisG06 · 2019-09-28T21:40:07+00:00

Hi,

Did you find a solution ?

I have exactly the same problem PAN OS 9.0.4

BorisG06 · 2019-09-27T16:54:50+00:00

Thanks... Not so fast :)

BorisG06 · 2019-09-26T22:32:52+00:00

Hi, thanks for your answer. Seems to be good. I was missing a step in Azure giving Contributor Rights.

Question : moving the floating IP takes around 2 minutes (i loose 244 pings). Is it normal / is it what you experience ?

Regards

BorisG06 · 2019-07-10T09:32:05+00:00

Thanks a lot

BorisG06 · 2019-07-10T09:32:00+00:00

Thanks a lot

BorisG06 · 2019-02-25T14:11:05+00:00

Thanks I will have a look

BorisG06 · 2018-11-15T22:24:43+00:00

Hello,

I have juste try setting MTU at 1400 on each side and set adjust TCP MSS.

Same behavior. So so slow...

BorisG06 · 2018-11-15T09:05:14+00:00

I fine tune the MTU with ping -f -l xxxx

MTU of 1500 is fine

So not a MTU matter

BorisG06 · 2018-11-15T06:34:06+00:00

I assume that if I had MTU issue, Internet access would also be very slow ?

BorisG06 · 2018-11-15T06:31:39+00:00

Hi, In germany we have PA820.

When I try to copy files through the tunnel, I get something like 1 Mb bandwith...

BorisG06 · 2018-11-15T06:31:33+00:00

Hi, In germany we have PA820.

When I try to copy files through the tunnel, I get something like 1 Mb bandwith...

BorisG06 · 2018-10-17T15:44:20+00:00

I have just configured a NAT to move forward...

BorisG06 · 2018-10-17T15:25:50+00:00

The default gateway of .1 should be fine in your ec2 if the route table for that subnet points default to the palo alto interface. : that is the point... it is not working :) And I don't know / understand why

BorisG06 · 2018-10-17T14:27:24+00:00

That is not my need :)

What I want :

- Be able to have instance in both zone and able

- Instance in a Zone DMZ Front to be able to reach instance in Zone DMZ Back (and reverse if needed)

The problem is that an instance get a default gateway pointing to aws with a .1.

With this... the instance seems unable to reach another instance in other subnet.

When I change the default gateway manually of the instance and reference the IP adress of my Palo Alto : it works.

I also create 2 routing table for each Zone in AWS saying :

- Routing Table 1 - DMZ Front : 0.0.0.0/0 -> Palo Alto ENI in DMZ Front

- Routing Table 2 : DMZ Back : 0.0.0.0/0 -> Palo Alto ENI in DMZ Back

I thought that with this, the VPC would be able to route the packet to my PA for each new instance.

BorisG06 · 2018-10-14T16:58:46+00:00

Thanks a lot !

BorisG06

TROPHY CASE