topic Re: Asym routing and policies in General Topics

Asym routing and policies

Alex_Samad — Sun, 28 May 2017 01:27:42 GMT

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

Re: Asym routing and policies

pulukas — Sun, 28 May 2017 13:34:29 GMT

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-Firewall-to-Allow-non-Syn/ta-p/62868

Re: Asym routing and policies

Remo — Sun, 28 May 2017 15:19:25 GMT

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?

Re: Asym routing and policies

Alex_Samad — Sun, 28 May 2017 20:28:56 GMT

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

Re: Asym routing and policies

Remo — Sun, 28 May 2017 23:23:33 GMT

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

Re: Asym routing and policies

Alex_Samad — Sun, 28 May 2017 23:40:59 GMT

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

Re: Asym routing and policies

reaper — Mon, 29 May 2017 08:17:54 GMT

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? 🙂 )

Re: Asym routing and policies

Alex_Samad — Mon, 29 May 2017 08:50:50 GMT

Hmmm, okay have to keep that in mind

thanks

Re: Asym routing and policies

Remo — Mon, 29 May 2017 09:48:26 GMT

@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 ...

Re: Asym routing and policies

reaper — Mon, 29 May 2017 13:32:50 GMT

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

Re: Asym routing and policies

pulukas — Mon, 29 May 2017 17:07:56 GMT

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.

Re: Asym routing and policies

Alex_Samad — Mon, 29 May 2017 22:24:58 GMT

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

Re: Asym routing and policies

pulukas — Wed, 31 May 2017 00:52:23 GMT

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.

Re: Asym routing and policies

Alex_Samad — Fri, 16 Jun 2017 06:00:27 GMT

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 ...

Re: Asym routing and policies

pulukas — Tue, 20 Jun 2017 22:54:35 GMT

I am having troube picturing the path here.

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

Re: Asym routing and policies

Alex_Samad — Tue, 20 Jun 2017 23:03:46 GMT

No loopback.2 is not part of the same zone.

does zoning influence routing ?

I will see if I can describe it again, maybe better.

2 PA - active active

1 trunk (LACP) into the switch ae.1

2 vlans'

213 zone ospf

217 zone app server

loopback.1 zone ospf - routerid

loopback.2 zone inf - Global protect portal - HA IP but fail over , bound to primary no ip arp loading sharing

213 - no HA active ip. but active OSPF interface

217 - HA active ip, enabled ospf but passive ip - arp load sharing

this is duplicated on the PA's - pa1 and pa2 ... pa1 is the active primary and pa2 - active backup

if I have a host PC in vlan 217 that happens to use PA2 , because of the algo used to share.

A packet going from the PC to GP portal goes like this

PC -> vlan 217 -> PA2 -> out via vlan 213 - because OSPF routes this way -> PA1 -> loopback.2

return path

loopback.2 -> vlan 217 because its directly attached to vlan217.

Re: Asym routing and policies

Alex_Samad — Sun, 25 Jun 2017 07:07:51 GMT

Found best practise setup for OSPF Active / Active

https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-OSPF/ta-p/52283?attachment-id=2880

With asym