Sustainable Sustworks - Tools for Internet Travel
Inspired Tools for the Mac


Application Note 2001

Setting Up IPNetSentry - IPNetAuthorize for Remote Authorized Access

Consider the following scenario

You only want to give specified remote Internet users access to your network (or your single machine, if only one machine is connected to the Internet).

If the remote users have static IP addresses, there is no problem. You simply BLOCK all access to specific services on your network with either IPNetSentry or IPNetRouter, then "punch holes" in these filters to PASS the specified remote users with static IP addresses.

BUT, what do you do when remote users have dynamic IP addresses? (which is often the case) In this situation you cannot simply punch holes in your firewall filters because you never know the exact IP address of the remote user.

This is the function of a new feature in IPNetSentry (v1.3.8 or later) when used in conjunction with the IPNetAuthorize client: providing authorized access to remote users who have dynamic IP addresses.

Setting It Up

1. You must have IPNetSentry v1.3.8 or later installed.

2. Turn OFF IPNetSentry with the IPNetSentry Companion.

3. Open the IPNetSentry Config file with SimpleText (or BBEdit, etc.). Choose a port for which you wish to use for authorization. Many ISPs intentionally block incoming traffic on ports below 1024, so you might wish to choose a port above this range. For this example we will assume we have chosen port 2525.

4. Add the following line to your IPNetSentry Config file (right below the #set/payload_inspection commands):

#set\password\\2525\trythis\Password Access\\600

The above command will authorize a remote user who comes in on UDP Port 2525 using the Password "trythis". Access will be permitted for 600 seconds. When access is granted, the alert will display "Password Access" as the service.

The general syntax of the #set\password command is:


If no interface is specificed, the default interface will be used (as setup in the TCP/IP control panel)

If no notification is provided, the default IPNetSentry notification mechanism will be used.

5. IF you are not running IPNetRouter, then you will need to add the BLOCK service filters in the IPNetSentry Config file. For example, let's say you are running a web server on Port 80 and a mail server on Ports 25 and 110. BUT you only want authorized remote users to have access to this server. You need to block ALL access to these servers, which can be done with the following filter commands in the IPNetSentry Config file:


Another approach is to just block ALL tcp ports below 1024, e.g.:


IF you ARE running IPNetRouter, you can add similar filters directly through the IPNetRouter Filter window.

6. Save the IPNetSentry Config file and close it. Turn ON IPNetSentry.

7. On a remote machine, download and install the appropriate IPNetAuthorize client for your remote platform:

IPNetAuthorize Client for Mac OS X

IPNetAuthorize Client for Classic Mac OS

IPNetAuthorize Client for Windows (95, Me, NT, 2000, XP)

8. Launch the IPNetAuthorize client on the remote machine. Enter the destination (IP address or Domain Name), Port (2525 in our example), and password ("trythis" in our example). Click the "Authorize" button. IPNetSentry should recognize the incoming datagram and insert a PASS filter for this specific IP address. This filter will expire in 600 seconds (as set in our example #set/password command).


- You cannot use the same password simultaneously from two different remote IP addresses. Using the same password more than once will automatically remove any existing PASS filters which were invoked by that same password. This is a security feature. For example, say your PPP connection dropped during your session. You then reconnect to your dial-up ISP, and are assigned a new IP address. You then re-authorize using the IPNetAuthorize client. Your re-authorization would automatically drop the existing PASS filter for your previous PPP connection.

- Unauthorization can only be performed by the aged filter timeout mechanism. While this has some limitations, it also ensures that unattended access will always timeout.

- There is NO encryption performed by IPNetAuthorize nor IPNetSentry. Hence this solution is not a general replacement for virtual private networks (VPNs). In many cases, however, users are not so concerned about data encryption as they are about unauthorized access to their server(s) or network.

Other Uses

There are situations when you might also wish to limit access to services on internal LAN machines. For example, say that you want to give LAN clients universal access to web and email services. But only one machine on the LAN at a time should have general access for all other services (webcasts, streaming audio, etc.). You can easily do this with IPNetRouter, IPNetSentry, and IPNetAutorize.

First you would add the filters to IPNetRouter which prevent access to all services below port 1024. You would then punch holes in this main blocking filter to give access to essential services such as HTTP, POP, SMTP, DNS, DHCP (if needed).

Then, in the IPNetSentry Config file you would add a #set\password command to permit access by any one of the client machines to all services:

#set\password\Ethernet slot J9\2525\trythis\Password Access\\600

Note that we have specified the interface on which this password command will be set (we are assuming our private LAN is connected to the Ethernet slot J9 port).

In this manner only one of the client machines at a time will have access to all services. In addition, when any client machine requests such access, you will have a log of this event in this IPNetSentry Log file.


Please send questions, comments, or suggestions using our general requests form:


Back to IPNetSentry Application Notes