Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Juan_
Collaborator

Assign IPs or Network to a fw_worker

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!

0 Kudos
8 Replies
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 ?

0 Kudos
Juan_
Collaborator

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;

0 Kudos
HristoGrigorov

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

0 Kudos
Juan_
Collaborator

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.


0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
Juan_
Collaborator

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. 

0 Kudos
PhoneBoy
Admin
Admin

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

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events