• SGS 320 has four LAN ports, one WAN port and no VPN support
• SGS 360 has eight LAN ports, two WAN ports and no VPN support
• SGS 360R is like SGS 360 but wih VPN support

Here’s a video (Flash) which shows differences between these three models in more detail.

SGS 360R comes with 10 client licenses for VPN. That means you can have maximum 10 people using VPN at the same time. Unless you use some other VPN method like OpenVPN for example. The VPN client software is only available for Windows and there are two issues I’ve found during usage. First it doesn’t work when Windows firewall is enabled. Third party firewalls work fine, problem is only with the built-in firewall of Windows XP. The second issue is that after installing the VPN client on a laptop the Remote Desktop functionality on the same laptop stopped working. This has occurred on all the machines where the VPN client was installed. I haven’t had the time to exclude the possibility of the culprit being actually some other application since all the PCs had a very similar set of programs installed on them.

SGS can be easily configured using a web browser. It has multiple security features like SPI firewall, IPSec VPN, intrusion detection and prevention, anti-virus policy enforcement and content filtering. It can also be extended with a wireless card to allow WiFi access.

At this point SGS is a bit old as a product, but it looks like it can be still bought.

A few months ago we started having some additional problems with this router. For example, it would drop connection to Internet from time to time (every couple of weeks or so). I’m actually suspecting that the problem was somewhere outside our office since recently we’ve moved and now the problem is gone (ain’t I the Sherlock). We’re even using both WAN ports for load balancing and redundancy. In one of my previous posts I talked about another router Linksys RVS4000. We bought it because of the intermittent connection loss on SGS. For a week or two the Linksys router was working fine but then it died after a firmware update. It wouldn’t connect to the Internet at all. We still had SGS and I was able to put it back in action in a few minutes. Then I connected the second WAN line and everybody noticed speed improvement on downloads.

So what’s the overall verdict? Symantec SGS 360R works fine. Now with double speed.

Related post(s)

• OpenVPN and Linksys RVS4000 (2)

We’ve got OpenVPN server setup in the office to allow access to our internal network via Internet. I had to make the router allow this traffic in and out. Previously we were using Symantec SGS 300 which was working pretty well but recently started crashing from time to time. Anyway, I knew how to setup the new router to allow OpenVPN traffic. At least I thought I knew…

OpenVPN connections arrive to the router at TCP port 1194 (which is the standard OpenVPN port). The router would normally reject those packets but for OpenVPN to work it needs to forward them to the OpenVPN server within the network. So step one is to setup port forwarding for TCP port 1194 and direct this traffic to the IP address of OpenVPN server. The OpenVPN server is inside the LAN so the IP address is in the private range. Let’s say it’s 192.168.0.10 although you need to check your set up if you want to follow these instructions. In order to set up port forwarding on Linksys RVS4000 you need to log on to the router, then select Firewall followed by Single Port Forwarding. Scroll to the bottom of the page and add a new rule:

• Application: OpenVPN
• External Port: 1194
• Internal Port: 1194
• Protocol: TCP
• IP Address: 192.168.0.10 (this is the IP address of the OpenVPN server on the LAN)

When you’re done press Save Settings.

So now we can start an OpenVPN client somewhere outside the office network and have it connect to the OpenVPN server within the LAN. If you try to connect to other machines on the LAN directly from the client you won’t be able to see them though. You can only do it by connecting first to the OpenVPN server and from there to the target computer. Why is that happening? You see, when the OpenVPN client connects to the OpenVPN server it gets an IP address on a different subnet than the office LAN. Depending on your OpenVPN configuration it could be for example 192.168.22.20. Now, the OpenVPN server is connected to both the office LAN (192.68.0.0/24 subnet) and the OpenVPN subnet (192.168.22.0/24 subnet) and it acts as a router between these subnets. You could think that is enough – we’ve got two subnets and a router between them, so they should be connected. Well, there’s one thing missing.

All the other machines on the office LAN (beside the OpenVPN server) have no clue about talking to the IP addresses on the OpenVPN subnet where the client is connected. In fact they use the default route which points to the router, in my case Linksys RVS4000. And that makes sense – if the IP address is not on the LAN that means it’s outside and the traffic should go through the router. Unfortunately the router so far has no idea how to connect to the OpenVPN subnet. It’s a private subnet and the only way to connect to it is via the OpenVPN server. OK, so we need to tell the router to direct all the traffic destined for the OpenVPN subnet to the OpenVPN server. OpenVPN server will then nicely encapsulate those packets in OpenVPN packets and send them back to the router to be forwarded to the outside client over the Internet. The difference is that this time the destination IP address will be the public IP address of the client on the Internet (for example this could be the external IP address of you DSL connection). The router knows how to deal with the public IP addresses. But before that happens we need to setup a static route to tell the router that all traffic with destination IP address in the OpenVPN subnet (192.168.22.0/24 subnet) should be forwarded to the OpenVPN server at address 192.168.0.10. To add the static route on Linksys RVS4000 you need to log on to the router, then select Setup followed by Advanced Routing. Scroll to the lower half of the page and add a new entry in the Static Routing section:

• Select Set Number: 1 (or any other entry which is not in use)
• Destination IP Address: 192.168.22.0 (IP address of the OpenVPN subnet)
• Subnet Mask: 255.255.255.0
• Gateway: 192.168.0.10 (this is the IP address of the OpenVPN server on the LAN)
• Hop Count: 2 (that’s the default value and changing it won’t make a difference in this setup)

When you’re done press Save Settings.

After this you should be able to connect with your OpenVPN client to any machine on the office LAN. Unless like me you decided to be smart

You see, on the Advanced Routing page where we’ve just configured the static route there’s also another configuration option: Inter-VLAN Routing. This option can be either enabled or disabled. If you access the online help on Linksys RVS4000 you can read that “When Inter-VLAN Routing is enabled, packets can be routed to the VLANs that are in different IP subnets.” If you’re like me after reading this you probably thought: “I’ve got no VLANs, I’m going to disable this option”. I did just that, I disabled the Inter-VLAN Routing. The result was that I lost VPN access to other machines than the OpenVPN server. For some reason Linksys RVS4000 needs this option to be enabled unless you want it to completely ignore the static route you’ve just configured. I don’t know why it works like that since as far as I know there’s no actual VLAN being used by the OpenVPN. The router is supposed to just forward the packets with the destination IP address in 192.168.22.0/24 subnet to the 192.168.0.10 IP address of the OpenVPN server. There’s no VLAN tagging or untagging involved. I don’t know enough about VLANs to tell you whether Cisco engineers had a good reason to design it this way or that’s a bug. It took me awhile to figure this out since I made some other changes at the same time… Hopefully these instructions will help other people.

Related post(s)

• Experiences with Symantec SGS 360R (1)