×
all 13 comments

[–]janus_god 2 points3 points  (1 child)

I would confirm Signiant is limited to 90 mbps, not 90 MBps as that would exceed the 500mbps. A google search on the product doesn't seem to show much detail around the UDP flows. My concern for a firewall would be how large each UDP PDU is and the pps rate of the UDP PDUs. Also any fragementation performed by the firewall could impact it, as well as large buffers getting filled with many UDP frames that cause TCP ACKs to go missing and cause browsing traffic to experience retransmissions. How about IPsec is this traffic being tunneled between the sites?

Perhaps the best starting place is pps/bps on the SonicWall "trusted" interface facing the Signiant media endpoint and comparing those numbers against the SonicWall spec sheet during a file transmission. If the interface numbers are close to the limits on the SonicWall it may simply be too much for the unit.

[–]basher09[S] 0 points1 point  (0 children)

Yeah, it caps at around 11MBps. I will run a packet cap when we do another upload to see what sort of PDUs we are looking at. It is very possible the buffer is getting filled. The firewall's UI seems to become slow to respond during an upload, even from a different network than where the traffic is originating. I haven't noticed that the firewall's CPU is overly taxed during the upload, so I don't think it is doing excessive inspection. The firewall is an NSA 4600, which has a pretty decent capacity for most things.

[–]marx1ACSA | VCP-DCV | VCA-DCV | JNCIA | VCP-DCV | PCNSE | BCNE 2 points3 points  (3 children)

Make sure your model can run a full 500mb of throughput with all the features you have turned on. It's very possible that it's rated above 500 with everything off, but much lower with specific features on.

[–]basher09[S] 0 points1 point  (2 children)

It's an NSA 4600. It should be able to handle much more than we are throwing at it. And for the most part it works without issue. It just gets bogged down by something with this UDP traffic.

[–]marx1ACSA | VCP-DCV | VCA-DCV | JNCIA | VCP-DCV | PCNSE | BCNE 0 points1 point  (1 child)

Go check those specs again... 800mb full DPI inspection.

[–]basher09[S] 0 points1 point  (0 children)

Right, which should be more than enough. We generally don't go over 100-200 Mbps, even with an upload happening. We pay for up to 500 from our ISP, but rarely hit that.

[–]whiteknivesSchool of port knocks 1 point2 points  (1 child)

Run some tests without Media Shuttle running and ensure that you actually can use 500mbps?

[–]basher09[S] 0 points1 point  (0 children)

Yep, everything runs fine when a file is not being uploaded. I've run IPerf across the firewall both while Media Shuttle is running a file upload and not. I get good speeds when Media Shuttle is not running, but as soon as a file upload is started, speeds crash.

*We have a fiber provided by our ISP

[–]FuzzybunnyofdoomI like graphs 1 point2 points  (1 child)

UDP senders do not limit or increase sending rates based on traffic shaping. There is no congestion-control mechanism for UDP traffic like TCP. If you're limiting the traffic on the Sonicwall, the Signiant is probably doing its best to continue sending at full speed since its sending via UDP. Sonicwall will most likely attempt to either delay or drop non-compliant packets in the UDP stream. If delay, it will probably overflow its own buffers and fail at doing anything productive. If drop, you'll likely see failed uploads unless Signiant has some checksum mechanism on the backend.

What is the Sonicwall's CPU usage like when you're testing this?

[–]basher09[S] 0 points1 point  (0 children)

The Signiant software does handle checksum. All CPU cores indicate about 50% utilization- higher than normal traffic, but not excessive. The UDP traffic seems to get through without an issue. It's all other traffic that suffers. I'm not doing anything to specifically limit bandwidth on the firewall. The bandwidth cap comes from the Signiant portal (server side), and can be changed by the portal owner. We are uploading to a third party who is the owner of the portal. I think buffer overflow may be an issue.

[–]DarrenRoskow 0 points1 point  (2 children)

This is exactly where I usually suggest BitTorrent for moving large files with integrity checking / resume / etc. Setup an internal tracker and let it rip site to site with appropriate bandwidth limits.

That said, I would exclude your endpoints at both sides from any additional inspections (IPS, Anti-virus, etc.) as your firewall might be trying to reassemble the communication stream to assess payload.

[–]basher09[S] 0 points1 point  (1 child)

Unfortunately, we are uploading to a third party, and they require the use of the Signiant software. I have added the remote server addresses to my exclusion list since the last upload, so we will see if it makes a difference. The NSA 4600 should be able to handle that volume of traffic without an issue, even with full DPI.

[–]DarrenRoskow 1 point2 points  (0 children)

I was thinking the inspection could be a memory / buffer issue rather than inspection bandwidth. In that respect I was thinking about it trying to re-assmeble then entire UDP stream, or at least huge chunks of floating windows (overlap) and chewing through RAM in the process. Not sure on SonicWalls though, as much as i worked with them in the past, they aren't really enterprise class, so less about their internal traffic processing tends to be known.