[an error occurred while processing this directive]
This feature is supported only in 3CR870. The company claims that the device can limit incoming as well as outgoing traffic.
That's why we set the incoming/outgoing traffic limits to 1024/512 and started traffic generators.
Traffic shaping, upload only, NetIQ Chariot, Throughput.scr
Yes, the outgoing Internet traffic is limited, but the average speed is a little higher (~70Kbit) than it's required.
Traffic shaping, download only, NetIQ Chariot, Throughput.scr
The download traffic is also limited, but the average speed exceeds the required one approximately by 100Kbit.
Overall limitation of the incoming/outgoing traffic is a good thing, but sometimes you need to limit the traffic for certain protocols/applications. Unfortunately 3CR870 does not have a comprehensive system for such configuration. You can only limit the traffic through a certain port (it's not clear if it's for incoming or outgoing) and set one of the two priorities to this limitation.
Thus, we set the general download/upload limitation to 2048/768 and created several traffic classes:
I repeat that in this case we test the outgoing traffic model, that is in reality this traffic would be generated (in Internet) by computers in LAN behind the 3Com router (registered as virtual servers).
Traffic shaping by port, upload only, NetIQ Chariot, Throughput.scr
Except for the fact that the upper limit is again higher than required, everything is excellent - high priority protocols grab the larger part of the band, and the low priority ones slump at these moments - that is everything works as it's supposed to.
Of course the outgoing traffic shaping is not necessary to everybody (not everyone has servers generating heavy Internet traffic), but the option to cut down the incoming Internet traffic and sharing by priorities is needed by many people.
So we shall repeat the previous test, but now the incoming traffic goes through Internet Ports 4662, 80/443 etc.
Traffic shaping by port, download only, NetIQ Chariot, Throughput.scr
Here is the glitch. The traffic is not detected by the rules. Or it is detected but cannot be shaped - at least all the threads get an even share of the band, and the high priority traffic does not exceed the low priority one.
The tests were carried out according to this technique.
All the settings of the device were set to default (firewall enabled) before scanning. Enabling/disabling ICMP ping in the WAN interface did not have any impact on the results, so we left the ping option enabled.
Nessus reports (identical in both devices):
Note that it was very difficult to scan the devices - both routers often lighted the Alert LED and added records to the log saying that so-and-so IP had been trying to scan or attack and was blocked. However Nessus scanned the ports in the careful mode (rare attempts) and its scans didn't alert the guard, but we didn't manage to scan the device anyway.
Thus, the Nessus report is almost empty (that is everything is fine), however we managed to find one critical security breach. Theoretically it allows to freeze or reboot the device. I hope that this breach will be fixed in the new version of firmware.
When this review was written, both devices couldn't be found on sale.
Both devices are thorough revisions of 3Com OfficeConnect Cable/DSL Secure Gateway. Both possess good performance and fairly good (except for the found breach) security level. Support for a productive VPN server IPSec/PPTP/L2TP allows to establish secure connections between the networks.
But as always, there is a fly in the ointment. There is no remote administration feature (via the web interface at WAN port) and the embedded firewall is far from flexible.
Pros and cons common for the both devices.