[[tutorial|Firewall rule tutorial]] example 3:

====== Opening an outgoing port ======

^ :!: This description is addressed to advanced users only. ^
| Incorrect editing of the firewall rules may cause security risks! |

Say you want to allow any PC connected to ET1 to send data to TCP port 4044 on any computer on the Internet.

{{:firewall:setup_fwall3.gif|Firewall path. See steps below for description.}}

**1.** The port should be opened for **incoming** packets from the **inside** (ET1). Thus the first rule we need to enter is into the **incoming super rules** of the **ET1 (inside)** interface. Actually, that ruleset already contains the line:
| saddr == 192.168.0.1/24 accept |
meaning “accept everything coming from the 192.168.0.x subnet" (notice the IP mask). Thus the packet is allowed through.

**2.** The next stop for the packet will be the **incoming user rules** of the **ET1 (inside)** interface. Here we need to add a rule:
| **proto == tcp && dport == 4044 accept** |
this will allow all PCs on the ET1 subnet to access TCP port 4044.

**3.** Now the packet is sent to the router. The packet has a destination IP address pointing to somewhere on the Internet, thus the router will send it to its default gateway through the **outside** (WAN) interface, thus the packet is sent to that interface.

**4.** The next stop for the packet will be the **outgoing user rules** of the **outside** interface. Here is already a standard rule that needs some explanations:
| (saddr != 50.11.69.17/32) modify dynamic source 0 |
This rule means: “all packets not coming directly from the Internet Gate shall be modified: their source shall be changed to any available free port from pool 0".

This needs even more explanation.

**(saddr != 50.11.69.17/32)** means “all packets not coming directly from the Internet Gate“ – thus all packets coming from PCs behind the Internet Gate. Our packet has source address 192.168.0.31. Example of packets coming directly from the Internet Gate is packets sent by the e-mail notification – those packets are not handled by this rule. But all packets coming from PCs behind the Internet Gate are.

**modify dynamic source 0** means "modify the packet: its source shall be changed to any available free port from pool 0". We have used **modify static** in example 2, there we hard-coded what to modify. We cannot do it here, because if we used **modify static sport 5011** that would work for the first PC that connects, but would not for the second – that connection would attempt use the same port 5011 that is already taken by the first one!

**modify dynamic source 0** is similar to **modify static** in that it creates a flow and a return flow that will inspect and modify the packets in the data stream. However, **dynamic** means that the modification will be dynamic, different for each flow instance created. **source** means that it is the source address and port that will be modified: the source address will be changed to the global IP address (50.11.69.17), and the port will be changed to any available port from pool 0 (currently there is only pool 0 available – it contains ports 55000-65000, there are no other pools). Thus this first flow might use port 56327 as outgoing port. Another flow generated by this rule will use some other port – perhaps 62861. You do not know what port will be used, but it does not matter, either.

**modify dynamic source 0** also creates a return flow for the incoming data on the same data stream. More of it later, in step 9 below.

**5.** The next stop for the packet will be the **outgoing super rules** of the **outside** interface. This ruleset has a rule:
| (saddr == 50.11.69.17/255.255.255.255) accept |
meaning “allow all packets coming from my global IP address out". As the modifier has changed the source address of the packet, the packet will be allowed through.

**6.** The packet is sent by the **outside** interface to the default gateway of your operator, and that will send it further through the Internet to the computer it is destined to.

**7.** If that computer answers, the answer will be sent back on the same data path: it will be sent to the same port as the previous packet came from: port 56327 of IP address 50.11.69.17.

**8.** The return packet arrives to the **incoming** half of the **outside** interface, the **incoming super rules**. Actually, that ruleset already contains the line:
| (daddr == 50.11.69.17/32) accept |
meaning “accept everything coming to your global IP address (50.11.69.17)". That includes port 56327 too. Thus the data is allowed through.

**9.** The next stop is **not** the incoming user rules, as step 4 above has created a **return flow**, that matches packets coming to TCP port 56327 of the global IP address (50.11.69.17). The return packet matches that flow and therefore the incoming user rules will be ignored and bypassed. Instead, the flow will **inspect** the packet, then **modify** it. The modification will change the destination address and port of the packet. The modificator remembers that port 56327 is used by the data flow of PC 192.168.0.31 port 6066, thus it restores those values back into the packet header.

**10.** Now the packet destination address is 192.168.0.31 (as modified in step 9 above). Thus the router sends the packet to ET1, as it is ET1 that handles the 192.168.0.x subnet.

**11.** The next stop for the packet will be the **outgoing user rules** of the **ET1 (inside)** interface. Actually, that ruleset already contains the line:
| proto != noproto accept |
simply meaning “accept everything". Thus the data will pass through the **inside outgoing user rules**.

**12.** The next stop for the packet will be the **outgoing super rules** of the **ET1 (inside)** interface. That ruleset too contains the “accept everything" rule **proto != noproto accept**, thus allowing the packet through.

**13.** The return packet is transmitted by ET1 and reaches the PC.

As you can see, we once again needed to check each ruleset to make sure the packets are allowed through, though many rulesets already allow them and does not need to be modified. Actually you only needed to add only one rule (in step 2), the rest was already present. And the modify action of the outgoing rule also helps our incoming packet to get back in and be sent to the correct PC.

===== Entering the rule =====
You enter the rule of step 2 above into the "Additional rules" fields of the [[web GUI:security profile]] page:
| ET1 | Incoming user | post | proto == tcp && dport == 4044 accept |
All other necessary rules are already present in the standard firewall ruleset.