Multiple TCP connections for logging

[Kaspars_Zibarts]

We have a small problem Houston.

One of our gateways is located in the kingdom far far away with over 200ms latency to the log server. Lately we noticed that part of the logs started to be saved locally on the gateway.

Investigation proved that we have reached the "limit" of a single TCP pipe (latency plus window size) that's around 1.5Mbps. Other evidence includes the fact that 2GB log file on log server never fills faster than 1.5hrs (note though that includes 2 VS logs so technically rate there is 2x1.5=3Mbps) and TCP send queue is noticeable on the gateway.

Solutions could be:

• keep disabling logging for highly used rules - not ideal as we already have cut a lot of fat
• bring log server closer to gateway - can't really as we have MLM that serves many other kingdoms far away
• increase TCP window - not ideal to go any higher as re-transmission overhead would grow a lot
• transfer locally saved files with a script - but that potentially would introduce noticeable latency in log delivery
• add the second TCP connection for log transfer because that would double transfer rate capacity

Does anyone know if it's really possible - to have multiple TCP connections for log transfer. I did some digging in UC but did not find anything. I'm interested in VSX "version"

Or does anyone know if we can "split" MLM or have two MLMs?

[Vladimir]

Unless Check Point has a multi-threaded log transfer agents already, I suspect that you are limited to the choices you have described.

One exception, possibly, is the use of the bandwidth (or WAN) optimization appliances on both sides. You really would not know if this approach works until you try. Riverbed is probably one of the better known names in that market.

WAN Optimization – WAN technologies from Riverbed 

You can give them a call and try to get their engineers' opinion on the subject and anticipated (or not) improvements.

[Kaspars_Zibarts]

hehe - we just ripped out all the WAN accelerators as all they did was cause headaches

Yeah - I'm bit curious about multi-threaded log transfer

Might migrate the secondary MDS to the kingdom far far away and use that as log server for local firewalls - seems like the most logical step with the least cost. Additionally it will make local FW admin much faster for local admins as SmartDashboard gets really slow with that sort of latency

[Vladimir]

...begs the obvious question: did you have these issues with log transfers when the WAN accelerators were in play?

[Kaspars_Zibarts]

no, but we didn't as many logs either  we have multiplied firewalls and logs ten-fold since then 

[Vladimir]

There is also a possibility of the UDP log shipping with TCP error checks.