Differences

This shows you the differences between two versions of the page.

--- firewall:example_3 [2010/11/04 13:32]
tibor
+++ firewall:example_3 [2010/11/04 13:58] (current)
tibor
@@ Line 34: / Line 34: @@
 **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.
-. The next stop for the packet will be the outgoing super rules of the outside interface. This ruleset has a rule:
+**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 |
-(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.
-. 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.
+**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.
-. 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.
-. The return packet arrives to the incoming half of the outside interface, the incoming super rules . Actually, that ruleset already contains the line:
+**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.
-(daddr == 50.11.69.17/255.255.255.255) accept
+**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.
-. 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.
+**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.
-. Now the packet destination address is 192.168.0.31 (as modified in step 9 above). Thus the router sends the packet to ET2, as it is ET2 that handles the 192.168.0.x subnet.
+**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.
-. The next stop for the packet will be the outgoing user rules of the ET2 (inside) interface. Actually, that ruleset already contains the line:
+**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**.
-proto != noproto accept
+**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.
-simply meaning “accept everything". Thus the data will pass through the inside outgoing user rules .
-. The next stop for the packet will be the outgoing super rules of the ET2 (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.
-. The return packet is transmitted by ET2 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.
-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 change one rule, 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.

firewall/example_3.1288873960.txt.gz · Last modified: 2010/11/04 13:32 by tibor

Show page Old revisions