The “Host Network Identity” is a great security feature, it allows you pre-assign the DHCP address for your computers, it is secure because it depends on the MAC address of the host computer. If I was running wireless network (like an Airport) then there is nothing to stop someone else with a wireless Network Interface Card obtaining a DHCP address and using my network as a free Internet connection. This is a very common hacking method now, we refer to it as Drive-by hacking. To stop this you tell the ISB SOHO the MAC of every device in your network that will ask for a DHCP address, thereby excluding any other device that you do not know about.
The filters below allow you to create rules for blocking traffic between the LAN ports and the WAN port. By default everyone on the LAN gets full access to everything. The use of groups gives you a finer control over who has access what, by applying certain filters to certain groups of users.
Should you wish you can block some types of traffic that your LAN users would generate, and to do this you would use the “Access Filters”. Here, using the pre-defined “Quick access filters”, we blocked all HTTP traffic- this stopped all Browser traffic dead in it’s tracks.
A very useful one click button is “Block All Internet Access”, this cuts all your LAN users access through the WAN port- sure beats pulling the cable out in an emergency!
We did the same HTTP block using the “Custom Filters” fields. It was all very simple and after pressing “Save” the filter took immediate effect.
A quick firewall 101on PAT & NAT (I do not describe the handshake process in full)-
When a LAN user starts a session outbound through the WAN port, the ISB SOHO makes a that-
<!--[if !supportLists]--> 1.<!--[endif]-->computer1 using source IP address 192.168.0.4 source port 1320 is heading for destination IP address 184.108.40.206 destination port 80. When the packet gets to the WAN port it is changed as follows-
<!--[if !supportLists]--> 2.<!--[endif]-->computer1 becomes source IP address 60.152,152.152:2486 (or whatever is the first available port). The ISB SOHO makes a note in it’s translation table of this change. The packet is still heading for destination IP address 220.127.116.11:80.
<!--[if !supportLists]--> 3.<!--[endif]-->When 18.104.22.168:80 receives the packet it responds back. Within the response packet it now becomes source address IP address 22.214.171.124:2002 (or whatever it jumps to) and the destination IP address stays as 60.152,152.152:2486.
<!--[if !supportLists]--> 4.<!--[endif]-->When the ISB SOHO receives the packet it looks in it’s translation table to see what the source and destination is associated with for the translation back to 192.168.0.4:1320.
The bottom line being that when the WAN port receives a packet, it checks the source and destination IP & port against it’s translation table for a match.
Now what happens when someone on the Internet sends a packet to the ISB SOHOout-of-the-blue? Well the ISB SOHO isn’t going to have a session already listed in it’s translation table for those details, so it quietly discards the packet. This can also be a hindrance if you have a strange protocol you want to use (usually UDP based), if you are on the Internet and require access to you LAN, or if you use a protocol that can only used fixed port numbers and therefore fails when PAT hands out seemingly random port numbers.
To cater for these situations we have “Special Applications”, where you can pre-define protocols which would normally fail through the ISB SOHO. As such I can’t imagine a situation that couldn’t be fixed whilst using this feature and “Virtual Servers”.
Here we have a minor gripe. The manual says that some pre-configured tricky applications have already been installed, only waiting to be turned on as necessary. We looked high and low, read the same paragraph over and over, but couldn’t find them. This is shame, as this is just the sort of value added feature we have come to expect from Nexland.
UPDATE from NEXLAND: "
The pre-configured settings used to be in the unit but games and applications tended to change ports so we left them out of the current fimrwares. The newer manuals will reflect this."
Well OK, you have your Broadband connection and you fancy becoming the next Bill Gates, so you want to put up a Web server with pictures of your dog, and take credit card details for the privilege. The “Virtual Servers” gives you the option to allow Internet access to a service(s) that exist on your LAN computers. And here we pass on the word of caution with facility. If you advertise a service for access by the big bad Internet, then you have to be VERY, VERY sure that the service doesn’t have an exploit that a hacker can get into. As an example, you may have an MS IIS Web Server on your LAN for public access. For that server make sure it has ALL the patches, because the firewall cannot stop someone hacking into your system (and thereafter your LAN) via a vulnerable IIS server exploit. By using this facility you are no longer hidden from the world- use with care and ONLY expose those services absolutely necessary.
Nexland have once again thoughtfully provided a collection of the most common services people access, so you cannot go wrong. The method is simple, you configure the Lan IP address of the services say 192.168.0.3, this server is accepting HTTP port 80 requests. Once configured into the ISB SOHO, it will be available as WAN IP 126.96.36.199:80. Any ping sweeps will find this WEB port 80 open!
There is a note on screen which you should heed, so make sure that any advertised server has a reserved IP address, you don’t want a new PC to boot-up and get the advertised IP address by mistake.
If you do not find a pre-defined service to your liking, you can create a custom port service to be available. We successfully configured in SSH (not shown) and through this application we were able to run a remote application called VNC on a LAN computer, so that we could managed the ISB SOHO management port through the WAN side of the unit.
KEITHLEE2zdeconfigurator/configs/INFUSIONSOFT_OVERLAY.phpzdeconfigurator/configs/ OFFLOADING INFUSIONSOFTLOADING INFUSIONSOFT 1debug:overlay status: OFF overlay not displayed overlay cookie defined: TI_CAMPAIGN_1012_D OVERLAY COOKIE set: status off