Asym routing and policies

[Alex_Samad]

Hi

If I have a TCP stream that is initiated and because of routing changes now has to flow through my PA, how to I allow this through.

On my other firewall's I can allow non SYN and SYN/ACK through but block SYN's.. How does one do that on a PA with policies ?

Alex

[pulukas · Accepted solution]

Instructions are here.  Be sure to correct to symmetrical routing as soon as possible and remove.

https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Set-the-Palo-Alto-Networks-Firewa...

[Remo]

I totally agree sith @pulukas. There is something wrong in the network if you have (new/additional) traffic on the firewall because of a routing change/asymetric routing.

But ... because of this post I had the following idea: Would it be possible to temporary use this "security issue" for pa-200-cluster upgrades without having the sessions interrupted?

[Alex_Samad]

Hi

Thanks, for the link.

So tell me how would you deal with this scenario.  2 DC at each DC I have a HA Cluster.  The HA Clusters are first hops onto the internet say 2 transit providers at each site.  You publish your Prefix out.

You have long lived TCP streams to addresses inside so 

inside server (with public ip address) -> core network -> PA HA cluster -> ISP -> internet -> Client fw -> client server

just say there is an issue with one of the providers, so the stream that was coming from one internet provider and over the HA pair at DC A is now coming over the internet on HA pair at DC B.

I don't see any reson why the TCP session should be dropped and re created

Alex

[Remo]

Hi @Alex_Samad

With this description your situation makes more sense to me and I understand why you want to allow non-syn-tcp traffic. What I did not unterstand: do you want to allow this traffic globally ond both of your clusters or for traffic coming from your internal network?

I evaluate the risk as lower when you only allow this traffic from internal network.

Allowing this traffic from the internet exposes your infrastructure to the following risks:

• Reconnaisance holes: many servers (windows for example) respond to packets on closed ports with a TCP RST. On open ports the server does not respond to tcp-non-syn traffic. An attacker may use these facts to probe if there is a server behind a specific IP and may also probe the server and the firewallruleset
• Session table flooding: because of no required TCP Handshake the firewall has to install a session in the session table for every packet. So there is a risk for full session tables and the firewall will not be able to process normal sessions. (With tcp-non-syn traffic dropped there are still syn-flood attacks, but there are methods like syn cookie or RED against that type of attack. These protections are useless when allowing tcp-non-syn traffic)

When you allow this traffic "only" from internal, there are still packets which will be dropped, but at least answers from publicly available servers/requests from internal clients will be processed without the need to establish the session again.

Regards,

Remo

[Alex_Samad]

Hi

No my hope was to only allow say port 443.

If I have a long lived websocket connection so only 443. I would hope to allow non syn tcp packets only if they are destined for a specific IP and only specific port.

Alex

[reaper]

security policy will still be applied, so you can limit the total exposure somewhat, but disabling tcp sanity with non-syn is a system wide setting and can't be limited to a specific port only

-- one gotcha: in zone protection profiles you can also opt to disable non-syn checks, which would allow you to only disable this for one or two specific zones while still enforcing syn on other zones, this could be helpful ? (a little? maybe? 🙂 )

[Alex_Samad]

Hmmm, okay have to keep that in mind

thanks

[Remo]

---

@reaperwrote:

-- one gotcha: in zone protection profiles you can also opt to disable non-syn checks, which would allow you to only disable this for one or two specific zones while still enforcing syn on other zones, this could be helpful ? (a little? maybe? 🙂 )

---

as I wrote, but as soon as you disable these checks from the internet you have the potential problem of session table flooding ...

[reaper]

true true, disabling non-syn protection is never a good idea and should only be enabled to temporarily solve an issue or for troubleshooting

[pulukas]

Ideally, I would create a connection between the peering routers at the two DC upstream of the PA clusters.

Have the PA cluster at each DC assume primary routing for particular subnets or even specific addresses that are published to the internet.  Advertise these specific routes up to the peering routers.

Now both peering routers have specific internal routes for the services published to the internet and that will be the path taken no matter which ISP or DC the traffic arrives on.

Not the assymetry issue will only arise during a failover situation where the prefix or address has to move from DC to DC.  And the need to re-establish the session will be far less disruptive and only need to happen at the time of failover.

[Alex_Samad]

So that seems to be a work around a failing of the PA's

Sorry i think the mantra asym routing is bad is well not the issue. I think I outline a situation where it can happen quite easily.

Happy to accept that the PA don't handle it the best and I will have to take that into account when I build out my network.

But thanks for the input, definitely learning alot 

[pulukas]

Just to clarify,  the reason asymmetrical routing is bad is because the PA is doing deep packet inspection for the entire flow.  In order to fully protect for threats the PA needs to see all of the packets.  When you have asymmetrical routing the each side is only seeing some of the packets and neither has the full picture to evaluate and block the threats.

[Alex_Samad]

Ok some across an interesting problem around asym routing

again pa1 pa2 ... active active HA config

vlan 13 is my OSPF network 

vlan 17 is my client network dgw (10.0.17.1) is a HA arp load sharing ip 

loopback.2 is my global protect ip -> this is a /32 and is a HA fail over bound to primary.

I have a pc on vlan 17, it just happens to be hashed to pa2 (backup) dgw.

So packet destined for GP (global protect portal), go pc -> PA2 VLAN17 interface -> vlan 13 (this is the interface is learns about the address via OSPF ) -> PA1 vlan 13 -> loopback.2 from there there return path is loopback.2 -> out vlan 17

And I am having issues with packets not making it to some  clients 

I can't make global protect portal on a arp load share ... So what to do ...

[pulukas]

I am having troube picturing the path here.

Is loopback.2 in the same zone as vlan 13?