Testing Traffic Shaping

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.

4.1 Limiting the entire band of outgoing traffic.

Yes, the outgoing Internet traffic is limited, but the average speed is a little higher (~70Kbit) than it's required.

4.2 Limiting the entire band of incoming traffic.

The download traffic is also limited, but the average speed exceeds the required one approximately by 100Kbit.

4.3 Limiting the outgoing traffic by ports (creating queue groups).

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 limit.

Thus, we set the general download/upload limit to 2048/768 and created several traffic classes (see the above screenshot). 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).

On the first diagram the traffic was going out from Ports 80,23,110,25 (testing traffic filtering by outgoing ports), on the second diagram – vice versa, the traffic was going out from a random port to specified Ports 80,23,110,25 (testing traffic filtering by destination ports). It's clear that the rules intercept traffic by destination ports, but they do not react to traffic by outgoing ports. And again the overall traffic limit is a tad higher than it should have been.

When the rules snap into action (filtering by destination ports) everything is just fine – high priority protocols seize most of the band, and at these moments the low priority protocols slump, that is everything is working as it should. But this is the case only with filtering traffic by destination ports. For outgoing traffic it is hardly useful at all (strictly speaking, its usage is very limited, e.g. this rule can be used to limit the outgoing mail traffic to an external smtp server).

4.4 Limiting the incoming traffic by ports (creating queue groups).

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 from Internet.

On the first diagram the traffic comes to LAN from Ports 80,23,110,25. On the second diagram, vice versa, the traffic is coming from a random port to specified Ports 80,23,110,25.

The situation is similar to that in the previous test. The rules react only to traffic by destination ports. And the the upper limit of the traffic is again higher than required.

Let's sum it all up. Outgoing/incoming traffic shaping by custom rules works great, but the rules can react only to traffic by destination ports. It means that the existing traffic shaping method (or creating queue groups) will be of little use, most users need tools to filter the traffic into queues by outgoing ports.

3CR860 and 3CR870 security tests

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):

• Abridged
• Full

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.

Availability

When this review was written, both devices couldn't be found on sale.

Conclusions

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.

Pros

• High routing performance (transfer between the LAN and WAN segments)
• VPN server IPSec/L2TP/PPTP
• High performance of the embedded VPN server supporting IPSec
• IPSec/L2TP/PPTP pass-through support
• Fairly good security level with an option to auto-detect attacks and block intruders
• There is an option (though primitive) to limit the incoming and outgoing traffic
• Detailed logs, which can be stored on the external syslog server
• Filtering web-servers by content (by subscription to special services)

Cons:

• No certificate support in IPSec (works only with pre-shared keys)
• Impossible to set up different encryption modes in IPSec for the first and the second stages of connection establishment
• IPSec encryption speed (in the 3DES mode) between two 3Com routers is lower than in case of a Linux host connection
• (Only in 3CR870) buggy traffic shaping – upper traffic limits are not observed, outgoing traffic shaping by selected ports does not work (it works only by destination ports), primitive shaping criteria
• Poor means to set up rules for the on-board firewall
• Telnet control is not supported
• SNMP is not supported

Navigation:

• Overview, circuitry, and specifications
• Excursus to settings
• Performance tests
• Testing traffic shaping, security; availability and conclusions