Assign IPs or Network to a fw_worker

[Juan_]

Hi Guys,

I guess my answer is NO since i've never heard of this before.

But i'm having a rather peculiar issue i need to workaround.

I'd need to assign a network or an IP to a specific worker since the normal hashing or dynamic dispatching won't work in this case.

Is it possible?

Many thanks!

[HristoGrigorov]

May be first explain what you are trying to achieve ? Do you want to have dedicated fw worker that is processing only traffic from/to single network/IP and nothing else ?

[Juan_]

Hi Hristo,

Doesn't matter if its nothing else, but i'd like to have a rule like

"srcip:192.168.70.20 > fw_1"

"srcip=192.168.60.0/24 > fw_2" 

Issue am having is due to asymmetric routing. When inbound and outbound flows (different connections to the Ckp) fall in the same core it fails, but if it falls in different cores it works. That's the reason why i need this. 

The application/network design doesn't allow to fix the reason for the asymmetry in the first place unfortunately. 

Drop beign: dropped by fw_conn_post_inspect Reason: fwconn_key_init_links (OUTBOUND) failed;

[HristoGrigorov]

And by "fails" you mean packets are dropped because of stateful inspection ?

[Juan_]

No, it sees it as a new connection since the IPs change (there is NAT involved), it's also UDP traffic.

But when it tries to rearm the NAT outbound back it sees the inbound connection and it fails to create the link, when inbound and outbound fall in the same core.

[PhoneBoy]

Have you opened a TAC case on this?
As far as I know, there's no way to manually influence the CoreXL hashing algorithm.

[Juan_]

Yes, case opened some time ago.. i've been labbing the issue heavily and it appears this is the culprit. Waiting on TAC to see if there is any possible workaround. 

[PhoneBoy]

Just to caution you: this could be a "workaround' for the true issue.
Which is probably why R&D needs to have a closer look at this. 

[Timothy_Hall]

The Dynamic Dispatcher can be bypassed for certain ports as described here, which was mentioned starting in the second edition of my book as an undocumented feature at that time:

sk108894: Difficulties in connecting to untrusted sites when both HTTPS Inspection and CoreXL Dynami...

When the bypass is active the old hash function will allocate which firewall worker gets the new connection, you don't get to pick which firewall worker instance.  I don't see any exposed mechanism for doing what you want by IP address.

What happens if you fast_accel the traffic through SecureXL? sk156672: SecureXL Fast Accelerator (fw fast_accel) for R80.20 and above  Even though there are multiple cores assigned to SND/IRQ functions, it is really still just one instance of the sim (SecureXL Implementation Module) driver in the kernel and might help avoid the asymmetry you are seeing.