[[firewall:example_3]]
Show page
Recent ChangesSitemap

Differences

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

Link to this comparison view

Next revision		Previous revision
firewall:example_3 [2010/11/04 13:23] – created tiborfirewall:example_3 [2010/11/04 13:58] (current) – tibor
Line 10: Line 10:
 {{:firewall:setup_fwall3.gif|Firewall path. See steps below for description.}} {{:firewall:setup_fwall3.gif|Firewall path. See steps below for description.}}
  
-1. The port should be opened for incoming packets from the inside (ET2). Thus the first rule we need to enter is into the incoming super rules of the ET2 (inside) interface. Actually, that ruleset already contains the line: +**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 |
-saddr == 192.168.0.1/255.255.255.0 accept +
 meaning “accept everything coming from the 192.168.0.x subnet" (notice the IP mask). Thus the packet is allowed through. 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 ET2 (inside) interface. Here we do not have any rule allowing TCP port 4044 through, but there is one allowing some other TCP ports out. Instead of entering a new rule, we add port 4044 to the current one:+**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.
  
-proto == tcp && (dport == 22 || dport == 25 || dport == 80 || dport == 110 || dport == 119 || dport == 143 || dport == 443 || dport == 4044 || dport == 8080) accept  +**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.
-this will allow all PCs on the ET2 subnet to access TCP port 4044, as well as a variety of other standard TCP ports. Editing the rule is more effective than adding a new one.+
  
-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 | 
-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: +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".
- +
-(saddr != 50.11.69.17/255.255.255.255) modify dynamic source 0 +
-This rule means: “all packets not coming directly from the SafeGate shall be modified: their source shall be changed to any available free port from pool 0".+
  
 This needs even more explanation. This needs even more explanation.
  
-(saddr != 50.11.69.17/255.255.255.255) means “all packets not coming directly from the SafeGate“ – thus all packets coming from PCs behind the SafeGate. Our packet has source address 192.168.0.31. Example of packets coming directly from the SafeGate is packets sent by the e-mail notification – those packets are not handled by this rule. But all packets coming from PCs behind the SafeGate are.+**(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, as 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** 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** 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.+**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: +**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. 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. +**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:+**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. 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.+**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 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.
  
-11. 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 .+
  
-12. 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.
  
-13. 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.1288873396.txt.gz · Last modified: by tibor
Show pageOld revisions
Media ManagerBack to top
CC Attribution-Noncommercial-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0