Multitech’s new SOHO RF550VPN Router is an inexpensive ($179.00 list ) Internet access router with VPN capabilities suitable for home or small office use.
Features not found in lower end products include
- Five (5) IPSEC VPN tunnels
- Automatic dialup to emergency ISP if WAN connection fails
- Both client and WAN side filtering
- Virtual servers (inward port redirection)
- Redirect RF550VPN logging to a syslog server
- Flash upgradable firmware
Of course it also includes the normal features you would expect in this sort of unit such as DHCP, PPPOE, and WAN sid MAC address control.
I set this up both as a home office router and also used a pair of these to connect two offices with a VPN.
Physically, this is a small (7.1 x 4.9 x 1.4 inches high) unit with a WAN ethernet port, 4 LAN ports (10/100 switch), and a DB-9 RS232 connector. You aren’t limited to 4 connected computers; up to 253 client computers can use this (simply connect one of the 4 LAN ports to your existing hub or switch).
Unfortunately, the current version of this does not include support for additional subnets.
Small Office/Home Office Internet Access
The RF550VPN comes preset with a 192.168.2.1 IP address and with DHCP active. The simplest way to handle this is to disconnect a machine from the rest of your network, set it to use DHCP, and plug it into one of the LAN ports (the WAN port can be connected or unconnected at this time). Reboot the PC, and it will get address 192.168.2.2. You can now use a browser to configure the RF550VPN by using http://192.168.2.1. You’ll be able to change this to work with your current network later.
WARNING: There is apparently a bug with some versions of Netscape and older versions of Internet Explorer that can cause problems. The only place I noticed this was in setting up VPN’s (see below). It’s probably best to use the current IE6 version of Internet Explorer to configure these. Using an older Netscape browser broke the VPN- I had to redo it with IE to restablish the connection.
Choose the Setup Wizard from the main menu to begin configuring the unit. After setting the time, you get to change the IP address and subnet mask. This change won’t actually take affect until you save and restart. There’s no point in doing that until you finish the rest of the configuration, at which time you can connect this to the rest of the network and reset the PC to its normal settings.
Next is Cable and ISP settings. You can leave the ISP address blank for a DHCP assigned address or fill in a static address. You can fill in a DNS address in either case. Only one DNS address is requested; that’s probably something that should be fixed in future upgrades.
ISP Additional Settings lets you configure such things as PPPOE where a user name and password are required by your ISP. You can also assign a specific host name if required, and force this router to use a specific hardware MAC address when the ISP has installed setup software on a PC that locks you into one specific network card. The RF550VPN will use that address in all its WAN traffic (you can leave the PC that had this MAC address on the internal networ; the RF550VPN only uses the assigned address for the WAN port).
If you have a backup dialup account, you can configure the RF550VPN to use that if the Cable or DSL line goes down.
The final section of the Wizard is VPN settings; I’ll cover that further down.
For many simple setups, you are now done. Save and restart, and it is ready to go. If you aren’t using the DHCP here to assign IP addresses to your PC’s, you’ll need to give them a default address pointing at this and configure them for DNS.
If you are using DHCP or have a more complex network, there are adjustments you may want to make under Advanced Settings.
Under DHCP Server Settings you can enable or disable DHCP and assign the IP address range to use. You can also reserve specific ip addresses for machines by MAC address, but you can’t control any other DHCP settings; this is a very basic DHCP server. If you need more capability, you need to use something else within your network.
Virtual Server Settings lets you forward ports to your internal network. You’d use this if you have internal mail or web servers.
If you have internal subnets, you may need to add Static Routing. You could also learn routes through RIP by turning that on in Dynamic Routing.
Filter Settings lets you apply simple rules to LAN and WAN side packets.
Modem Settings would only be used if you have a dialup account and your modem is non-standard.
VPN
The RF550VPN supports up to 5 IPSEC VPN’s. These can be router to router (completely transparent to client machines; no software on the clients) or, for road warriors, you can use (additional cost) client software.
The combined throughput of all 5 VPN’s is limited to 700k bps. This is as much data as it can encrypt. Unless your Internet connection is quite a bit faster than that, that’s not really a limitation.
I setup a router to router VPN. The necessary information is very simple. Each side of the connection has to have a name (it can be the same name on both sides or different). You need to specify the ip address scheme of the remote network and it needs to be different than the other end. For example, here we show one side of the VPN. This side uses a 10.1.1.0 network; the VPN it is connecting to uses 192.168.2.0. You also need at least ONE of the sides to have a static IP address- you specify the address or leave it at 0’s if the other side is dynamic.
The only other piece of information that can’t be left at defaults is the shared key. This will be the same on both sides. This key obviously should be long and composed of alphanumeric, numeric and punctuation characters for good security.
Once both sides are set up, all it takes to activate is an attempt by one side to reach something on the other side. For example, a machine on the 10.1.0.0 network could ping 192.168.2.1 (if one of the sides is dynamic, it is THAT side that will have to initiate the connection).
Windows NT etc.
In most VPN situations, we have the unfortunate circumstance of having to deal with an NT server at one end of the connection. The problem with this is a chicken and egg scenario: the clients need to authenticate to the NT server, but broadcasts to find the server do not cross routers (and a VPN is a router).
The easiest (though most expensive) way to solve this is to put in another NT server at the remote end and enable Wins resolution. The cheap way (the way I’ll discuss here) is to use LMHOSTS files on the remote clients.
Note: it’s not LMHOSTS.TXT or LMHOSTS.SAM- it’s LMHOSTS with no extension. It’s too easy to get this wrong in the Windows GUI- Windows stupidly hides file extensions and Windows programs are adverse to creating files without extensions. It’s better to drop down to a DOS command prompt to work on these files.
Windows people get confused by HOSTS and LMHOSTS. You can have either or both in your C:WINDOWS ( or WINNT or wherever your system root is) and under some conditions they could even be identical, but they serve different purposes. It’s really very simple: HOSTS is exactly like Unix /etc/hosts and serves exactly the same purpose. An LMHOSTS can look like a HOSTS file, but it also supports different syntax and its purpose is for browsing across subnets. Here’s an example of each; these files would be installed on the 192.168.2.0 machines of the network described above:
# C:windowshosts 127.0.0.1 localhost 10.1.1.1 ntserv1 10.1.1.15 ntserv2 # C:windowslmhosts 10.1.1.1 "MYDOMAIN x1b" #PRE 10.1.1.1 NTSERV1 #PRE #DOM:MYDOMAIN 10.1.1.15 NTSERV2 #PRE #DOM:MYDOMAIN
Here we have a PDC (NTSERV1, Primary Domain Controller) and a BDC (NTSERV2, Backup Domain Controller).
The magic line here is the one in LMHOSTS with the 0x1b. That has to be the 16th character of the stuff between quotes, so various domain names would look like this:
10.1.1.1 "MYDOMAIN x1b" #PRE 10.1.1.1 "DOMAIN x1b" #PRE 10.1.1.1 "LONGERDOMAIN x1b" #PRE 10.1.1.1 "SHRT x1b" #PRE
Put those files in place and either reboot or run:
nbtstat -R nbtstat -c
The “-c” should show you that it has picked up the information:
NTSERV1 <03> UNIQUE 10.1.1.1 -1 NTSERV1 <00> UNIQUE 10.1.1.1 -1 NTSERV1 <20> UNIQUE 10.1.1.1 -1 NTSERV2 <03> UNIQUE 10.1.1.15 -1 NTSERV2 <00> UNIQUE 10.1.1.15 -1 NTSERV2 <20> UNIQUE 10.1.1.15 -1 MYDOMAIN <1B> UNIQUE 10.1.1.1 -1
Now the remote clients can log into the NT domain and access resources as though they were local. I have found that the first attempt to login often fails; click cancel and try again- the second try usually gets through.
If you have other machines on the LAN, you need to list them if you want to be able to access them. If you don’t, you’ll see them in network neighborhood, but you won’t be able to open them. You would be able to access them by ip address however: start run 10.1.1.91 would work.
This of course means that you can’t conveniently use DHCP for machines with shared resources. NT Wins would overcome that.
The same is true from the “main” side- if those machines need to access clients on the remote VPN, you have to have Wins or LMHOSTS files there also. These would have 192.168.2.x listings.
When testing this, be sure you know a working login and password. If you have an incorrect name or password, you may still get a message that would make you think that you were unable to connect to the NT machine. I also advise trying it from more than one machine- I had one machine that was somehow screwed up internally- it could access the internet, but it could NOT access across the VPN. As it was due for replacement anyway I never did get to find out why, but this machine tied me up for almost an hour thinking there was something wrong with the VPN itself. There was not anything wrong; it was just this machine.
Please read this disclaimer
Copyright and reprint info
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
