For each ruleset, specify whether it can be used for local area networks and VPNs or for access via the Internet (provider). This distinction is an additional protection, so that you cannot accidentally define a rule with full access for connections from the Internet, for example.
Almost all protocols expect a response to a sent IP packet. With TCP, for example, data can only flow once the peer has confirmed the connection. Therefore, for almost all protocols not only the outward movement of the packets in the firewall must be allowed, but also the way back for the reply packets must be opened.
So that every rule does not have to be entered in two or more places, the Intra2net system can automatically assign each reply packet to the corresponding connection (Stateful Firewall). The "" option lets these response packets pass through the firewall automatically. Only in very few exceptions does it make sense to do without the automatic response rule.
A ruleset is processed from top to bottom. If all conditions of a rule apply ("Match"), the action of the rule is executed. For most actions, the run for this packet is completed, later rules have no effect (the first rule applies).
If no rule applies to a ruleset, the packet is rejected (implicit deny). This is visualized by the unchangeable rule at the end of the ruleset. If a packet is forwarded to another ruleset and no rule applies there, the packet is referred back to the original ruleset. The "Deny" rule displayed in the forwarded ruleset does not apply to the return step.
If different criteria of a rule are activated (e.g. source, service and connection status), all of these criteria must apply to the packet to execute the action. If no criteria are entered for a rule, the action is always executed.
Multiple options can be set for the criteria "source","destination" and "service". It is sufficient if one of them applies (logical OR linkage).
Example:
 |
 |
| Source | Service | Applies to |
|---|---|---|
| Client1 | Ping | No |
| Client1 | HTTP | Yes |
| Client1 | FTP | Yes |
| Client2 | HTTP | Yes |
| Client2 | FTP | Yes |
Objects can also be inserted into a rule with "Not". The action is executed if this object does not appear in the packet. If multiple objects are set with "Not", none of them may occur (and-link).
If objects with "Not" and normal objects in a condition are used together, at least one of the normal objects must apply (or link), but none of the objects with "Not" (and link).
Example:
| Source | Applies to |
|---|---|
| Client1 | No |
| Client2 | No |
| Client3 | Yes |
| Clients from the Internet | No |
The Actions at a Glance:
| Action | Description |
|---|---|
| Accept | Let packet through. |
| Deny | Discard packet, the sender does not receive an explicit error message (must wait for timeout). |
| Reject | Reject packet, send an error message to the sender (ICMP Port unreachable). |
| Nothing | Do nothing, packet goes through the other rules. The log option is still executed. |
| Forward to | Forwarding to another ruleset; forwarding is only possible to complete rulesets of the same type. |
| Return | Return to original ruleset. If no forwarding was used, this is equivalent to "Deny". |
| Transproxy | Redirection to the HTTP proxy of the Intra2net system (only for type "LAN, dialin and VPN"). Rules for the transparent proxy must always be at the beginning of a ruleset. |
We recommend using "Reject" to block packets from the LAN. The advantage compared to "Deny" is that the user immediately receives an error message and does not have to wait for a timeout.
For packets from the Internet (in a provider rule) we recommend "Deny", because the immediate feedback from "Reject" accelerates and simplifies a portscan from the Internet considerably.
The "Extra" tab contains further information.
Time profiles can be defined under Network > Firewall > Times. These time profiles can then be added as a condition for each rule. The condition only applies within the defined time profile; only then can the action be executed.
Logging is not a condition, but rather like another action: If logging is active and all conditions apply, then the packet data plus the logging text specified in the rules is logged in the messages log file.
Limits can be configured separately for action and logging. A limit for an action means that the action will not be executed if the limit is exceeded. A limitation for the log means that the packet is not logged if the limit is exceeded.
It is possible to limit the number of packets per time unit. The limit can be exceeded at short notice via the peak value. If the peak value was used in a time unit, it is only available again in the following time units if the limit was not used in a time unit.
A condition that applies when the packet has a size within the specified range.
The Intra2net system uses a stateful firewall. This means that it assigns each packet to a connection and can remember the state for each of these connections. This data can be accessed using the connection status condition.
| New | First packet that establishes a new connection |
| Invalid | The packet either requires an already present connection that does not exist, or does not match an existing connection status |
| Established | The packet belongs to an existing connection |
| Belongs to | The connection of this packet logically belongs to another, already existing connection (e.g. packets from ftp-data belong to ftp-control) |
| Port Forwarding | The connection of the packet is forwarded via port forwarding |
| Static NAT | The connection of the packet is forwarded via static NAT |
Some servers (especially public FTP servers) try to determine user data using the ident protocol when establishing a connection. To do this, the server establishes a connection to TCP port 113 of the calling client. Because of NAT, this call normally ends up in the Intra2net system and is blocked by the provider rule.
However, most of these servers are waiting for a timeout or an error message from the ident before they allow a login. Therefore, it has proven to be useful to insert a "reject" for the ident protocol into each provider rule.