danadeb :
( I know I can turn the router into an AP on the switches LAN, by disabling DHCP in the router, not using its WAN port and hooking one of its LAN ports to the 24 port switch.....BUT... I use the routers access restrictions to limit my kids internet time and without using the WAN port the router does not keep the date and time)
It would be like doing file sharing from the internet to a private LAN but without the security concerns!
Any thoughts on file sharing????
As you yourself suggest, the proper solution is using the router as a WAP (wireless access point), connected LAN to LAN. But if you want to take advantage of the WAN and all that implies (firewall, time setting, access restrictions, etc.), then I can see the problem.
There are two approaches that come to mind, one obvious, the other not so obvious (w/ the not so obvious perhaps being significantly easier).
The obvious solution is to do what anyone would have to do when attempting to access your network remotely -- open the necessary ports on the wrt54g for Windows file sharing (iirc, 445 and 137-139).
But that’s only half the battle. Since each side of the WAN *must* be using different subnets (e.g., 192.168.1.x and 192.168.2.x), you have a “visibility” problem. Let’s assume those behind the wrt54g are using the 192.168.2.x subnet, while the rest of your network is using the 192.168.1.x subnet.
Any user of the 192.168.2.x subnet can “see” any device upstream (which includes the 192.168.1.x subnet and the Internet) simply because those users will always pass through the 192.168.1.x subnet whenever the location of a particular IP address is unknown. But the reverse is not true. Even if the firewall ports for file sharing are opened on the wrt54g, the users of the 192.168.1.x subnet don’t know how to find the 192.168.2.x subnet!
So what you need to do for users of the 192.168.1.x subnet is TELL THEM how to find the 192.168.2.x subnet, and you do that by adding a routing entry into their respective routing tables.
route add 192.168.2.0 255.255.255.0 192.168.1.2
What this says is, you can locate any device on the 192.168.2.x subnet by using the gateway at 192.168.1.2. In this example, I’m assuming the WAN IP assigned to the wrt54g is 192.168.1.2. Obviously it could be anything if the WAN is using DHCP and getting it’s IP from your primary router’s DHCP server. That’s why it’s important in this case to use a static/fixed IP for the wrt54g’s WAN IP, so it doesn’t break your routing tables!
Now any time users on the 192.168.1.x subnet need to access the 192.168.2.x network, they know the wrt54g (192.168.1.2) will get them there.
So those changes solve the problem of gaining access to the shares, and how to find them. The final part of the puzzle is, those shares are typically accessed by name, but the namespace is only relevant to the current subnet. IOW, any attempt to access shares across subnets, by name, will fail. You’ll either have to address those shares using explicit IP addressing (e.g., \\192.168.2.100\myshare ), or else update the client’s hosts or lmhosts file w/ mappings of names to IP addresses (or if you had a WINS server on each side of the wrt54g, use that).
As you can see, it all gets a bit messy and a bit of a management headache. But if your network is relatively small and stable, it might be doable. If your primary router supports modification of its routing table, then you could add the routing information I described above to the router’s routing tables rather than individual clients. In that case, those clients will be redirected by the primary router over to the wrt54g whenever a reference is made to the 192.168.2.x subnet. It just makes it easier to manage if you can modify the router rather than each and every client.
So that’s the gist of it. And that’s why ppl avoid creating another subnet, firewall, etc., whenever possible. It adds significantly to your network management.
The less obvious solution is to use
LogMeIn Hamachi. In this case, you install Hamachi on all your clients (both subnets) and create a private, shared Hamachi network. Hamachi installs a virtual network adapter and configures it for the 5.x.x.x subnet. Any device w/ Hamachi installed and who is part of the same named network (a name you choose) behaves as if they are on the same physical network! IOW, it’s as if there are no walls or obstructions of any kind between your clients, even though in reality they exist on different subnets. Normally ppl would use Hamachi to create a private, distributed network across the Internet. But nothing says you can’t treat your own internal subnets in the same fashion.
The beauty of Hamachi is its simplicity. No firewalls to manage, no routing tables to manage, none of that. Plus, if you install it on a laptop, you can continue to use Hamachi remotely and have access to those same subnets. And since Hamachi runs over SSL, it’s absolutely secure. Besides file/printer sharing, you can use RDP, HTTP, FTP, VNC, just about anything, even things that otherwise would NOT be secure, in complete privacy and security!
Of course, you run into the namespace problem here too. You might want to add entries to your host files to map meaningful names to your shares now available over the 5.x.x.x network.
So it’s up to you. Personally I would avoid the use of a second subnet if at all possible. If not, I think Hamachi is a nice solution since it eliminates a lot of the management headaches, and you gain remote access features as a bonus. Manually configuring the network changes is certainly doable and effective, but I’m just leery whether you’d want to manage that for the long term.
Facebook
Twitter
Instagram