Port Triggering in firewall - TR069 support

Port triggering feature allows firewall to create pin holes on a connection trigger. These pin holes allow connections that are not explicitly opened by the administrator. Trigger connection details and pin hole details are configured by the administrator. This feature allows pin hole creation in the same direction of the trigger connection or in reverse direction or in both directions. This is specifically useful in cases where applications make new dynamic connections - Client initiated or server initiated connections. TCP/UDP ports used by these dynamic connections are known information. One can say that if this information is known, why can't administrator create the ACL rules? What is the need for port triggering? If ACL rules are created, they are permanent, that is, access on these ports are allowed even in cases where application is not run. In cases where local machines are getting the IP addresses from DHCP Server, it is difficult and some times not possible to create the ACL rules and administrator may be forced to open the door wider.

Examples of port triggering:

IRC: IRC client when it makes connections to IRC Server on one of the ports between 6660 to 76670, IRC server makes connection back to IRC client on port TCP 113 (IDENT protocol). Administartor does not need to open access 113 to all machines inside permanently. Admin is expected to allow only outbound connections on IRC (6660-6670) and configure port triggering functionality to open pin hole to allow reverse IDENT connection. Port triggering functionality, upon trigger connection, opens pin hole to allow IDENT connection coming from IRC Server to IRC client.

Microsoft ActiveSync protocol: Client makes connections to ActiveSync Server on Port 5678. Server makes connection back to on port 990. In this case too, port triggering record with trigger port as 5678 and reverse pin hole creation with port 990, allows inbound connection without having to create permanent ACL rule.

Firewall have capability to even create pin holes when the NAT is involved. There is one issue though when NAT is present. If there are multiple machines behind NAT are making connections to the same server and if server uses same port for reverse or forward dynamic connections, then firewall/NAT functionality will not have enough information to redirect the connections to the right machine. If server is different, there is no issue though.

Many firewalls do support this feature. Configuration consists of a list (non-ordered) containing port triggering rules with each rule having:

• Name : for identification
  
• Description: Description of this record - Mainly for administrators to give some descriptive information.
• Enable/Disable
  
• Triggering information
• Protocol : IP Protocol
• Port Range: Destination Ports of the triggering connection.
• Same direction pin hole details : If the triggering connection is made from 'corporate' to 'external', then the pin holes configured here will allow connections initiated from 'corporate' to 'external'. Many applications work fine with three ranges of pin hole settings.
  
• Protocol
  
• Port Range : Firewall opens the connections to these ports and protocol once the triggger connection is detected.
• Reverse direction pin hole details: Pin holes allow connections in reverse direction of the triggering connection. As per above example, pin holes in this section are created for connections from 'external' to 'corporate' from original server IP to original client IP. Here too, I feel three ranges are good enough for many applications.
• Protocol
• Port Range: Firewall opens the connections to these ports in reverse direction upon detecting the trigger connection.
• Disassociate pin holes from trigger connection: If this is set, then the pin holes exist even if the trigger connection is terminated. If this is not set, then the pin holes are removed along with the trigger connection.
• Inactivity timeout of pin holes: Typically, inactivity timeout is derived from the trigger connection inactivity. Administrator can set this explicitly using this parameter.

TR-069 data model:

• internetGatewayDevice.security.VirtualInstance.{i}.firewall.portTriggerRules.{i} PC
• Name: String(32), RW - Since this is identifier, once this record is created with a name, this can't be changed.
• Description: String9128), RW
• Enable : Boolean, RW - Takes value 1 or 0
• TriggerProtocol: String(16), RW - Takes values such as 'udp', 'tcp', 'udptcp', integer value in string to represent other protocols.
• TriggerPortRange: String(16), RW - Since it is range, the low and high values of the range must be separated by '-'. Example: 1000-2000
• forwardPinHoleProtocol1: String(16), RW - It takes values 'udp', 'tcp', 'udptcp', and any integer value representing protocol.
• forwardPinHolePortRange1: String(16), RW: Destination Ports for forward pin holes.
  
• forwardPinHoleProtocol2: String(16), RW
  
• forwardPinHolePortRange2 : String(16), RW
  
• forwardPinHoleProtocol3: String(16), RW
  
• forwardPinHolePortRange3: String(16), RW
• reversePinHoleProtocol1: String(16), RW - It takes values 'udp', 'tcp', 'udptcp', and any integer value representing protocol.
• reversePinHolePortRange1: String(16), RW: Destination Ports for reverse pin holes.
  
• reversePinHoleProtocol2: String(16), RW
  
• reversePinHolePortRange2 : String(16), RW
  
• reversePinHoleProtocol3: String(16), RW
  
• reversePinHolePortRange3: String(16), RW
• DisassociatePinHolesWithTrigger: Boolean, RW - Takes value 1 or 0. 1 means the pin holes are not removed whenever trigger connections times out or terminated.
  
• PinHoleInactitityTimeout: unsigned int, RW - 0 means that it inherits the inactivity timeout from trigger connection. Any other value provided specific inactivity timeout.