Evolution Payroll service bureaus allowing their customers to use Evolution Remote must clearly make provisions in the firewall to allow the inbound traffic, but merely opening ports 9901/tcp - 9903/tcp is often not enough.

Virtually all firewalls maintain a NAT (Network Address Translation) table that keeps track of ongoing connections, and entries in this table come and go as connections are opened, transacted, and closed. Though most NAT table entries are deleted when the connction is closed, not all connections actually do close - computers crash, traffic is lost on the internet, etc. - so without special arrangements, these entries would stay around forever.

So that the firewall doesn't run out of resources, each NAT table entry includes a timeout, and if no activity is seen on that connection within that time period, it's simply discarded. Short timeouts are fine for traffic like HTTP (websurfing) that only uses connections briefly, but for long-open connections like Evo Remote, this ends up cutting off users who have stepped away from the computer for a short time.

Our approach is to add the usual rule for allowing inbound Evo Remote, but to greatly increase the inactivity timeout to keep these connections open much longer.

Adding the Evolution Service Definition

The first step, before adding the rule, is to add the port and protocol definition of the Evolution Remote service: This step makes it available to an access rule that's defined next.

Skip this step if the Service name has been configured already.

Login to the Sonicwall with the admin user
Click the Access button on the left
Click the Add Service tab at the top
Add the Evolution Remote service as defined by this illustration (TCP ports 9901..9903), then click Add:

This step has only added a new service definition, and it should appear in the right-side panel of this Services tab. But the firewall access rules themselves have not changed - it's still allowing and blocking the same traffic it was before. However, we now have a convenient name for the list of Evolution ports that are required to change that access rule.

Adding the Access Rule

Next, we must open a hole in the firewall for the service defined above, but this relies on having the proper One-to-One NAT defined for the server already (which is beyond the scope of this Tech Tip). We'll be using the internal IP address of the server running the Remote Access Server. In our case, it's 192.168.1.31.

Assuming you're still logged in as admin:

Click the Access button on the left (this may already be current)
Click the Rules tab at the top
Click Add New Rule at bottom of the page, which brings up this popup window:

Once this rule has been saved, inbound Evolution Remote traffic will be permitted, and routed to the Remote Access Server machine. It will use the much longer NAT timeout, which should reduce the "hangups" that customers see if they leave the program idle for a time.

NOTE: these instructions only modify the Sonicwall's NAT timeout, and the customer's firewall - of unknown time - could be imposing its own, shorter timeout. The first timeout that expires is what destroys the session, and there is little that can be done from the server side to ameliorate this.

The real solution is for iSystems to teach Evolution Remote to send a no-operation (NOOP) packet every once in a while -- perhaps every five minutes -- to keep the connections alive.

This information is not produced or endorsed by iSystems, LLC.

First published: 2005/02/23

More Evo Tips

Does this site look plain?

Steve Friedl's Evolution Tech Tips

Sonicwall firewall access rules for Evolution Remote

Adding the Evolution Service Definition

Adding the Access Rule