Differences

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

firewall:example_2 [2010/11/04 13:04]
tibor
firewall:example_2 [2010/11/04 13:20] (current)
tibor
Line 15: Line 15:
**2.** The next stop for the packet will be the **incoming user rules** of the **outside** interface. Here we do not have any rule allowing TCP port 5032 through, thus we need to add one: **2.** The next stop for the packet will be the **incoming user rules** of the **outside** interface. Here we do not have any rule allowing TCP port 5032 through, thus we need to add one:
-| dport == 5032 && proto == tcp modify static daddr 192.168.0.31 |+| **dport == 5032 && proto == tcp modify static daddr 192.168.0.31** |
This needs some explanation. This needs some explanation.
Line 40: Line 40:
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.
-9. 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 5032 through, thus we need to add one: +**9.** The next stop for the packet will be the **incoming user rules** of the **ET1 (inside)** interface. Here we do not have any rule allowing TCP port 5032 through, thus we need to add one: 
- +| **saddr == 192.168.0.31 && sport == 5032 && proto == tcp accept** |
-saddr == 192.168.0.31 && sport == 5032 && proto == tcp accept+
meaning “accept TCP packets coming from port 5032 of PC 192.168.0.31". meaning “accept TCP packets coming from port 5032 of PC 192.168.0.31".
-10. Now the packet is sent to the router. The packet has a destination IP address pointing to somewhere on the Internet. As that address is not on any of the inside subnets of SafeGate, the router will send it to its default gateway, the one you have received from your operator. That gateway is accessed through the outside (WAN) interface, thus the packet is sent to that interface.+**10.** Now the packet is sent to the router. The packet has a destination IP address pointing to somewhere on the Internet. As that address is not on any of the inside subnets of the Internet Gate, the router will send it to its default gateway, the one you have received from your operator. That gateway is accessed through the **outside** (WAN) interface, thus the packet is sent to that interface.
-11. Thus the next stop for the packet is the outgoing side of the outside interface. But it is not the user rules there, as there is a matching flow.+**11.** Thus the next stop for the packet is the **outgoing** side of the **outside** interface. But it is **not the user rules** there, as there is a matching **flow**.
This needs some explanation. This needs some explanation.
-In step 2 above we have added a modify static rule that created two flows: one that inspected and modified the incoming data on this interface, and a return flow with the reverse. The return flow is set to match data coming in the reverse direction on the data path, thus coming on TCP port 5032 from PC 192.168.0.31. Our return packet matches that description exactly.+In step 2 above we have added a **modify static** rule that created **two** flows: one that inspected and modified the **incoming** data on this interface, and a **return flow** with the reverse. The return flow is set to match data coming in the reverse direction on the data path, thus coming on TCP port 5032 from PC 192.168.0.31. Our return packet matches that description exactly
 + 
 +As there is already a matching flow, the outgoing user rules of the outside interface are **bypassed entirely**! The flow instead takes the packet to the **modifier** that modifies the **source address** of the packet back from 192.168.0.31 to your global IP address 50.11.69.17. This is how Internet Gate hides your local IP addresses. 
 + 
 +Then the flow takes the packet to the **stateful inspector** making sure the packet follows the TCP rules. If the packet violates any of the TCP rules, it will be stopped by the stateful inspection, but all well-behaved packets will be let through.
-As there is already a matching flow, the outgoing user rules of the outside interface are bypassed entirely ! The flow instead takes the packet to the modifier that modifies the source address of the packet back from 192.168.0.31 to your global IP address 50.11.69.17. This is how SafeGate hides your local IP addresses.+**12.** The last stop for the packet through the firewall is the **outgoing super rules** of the **outside** interface. This ruleset has a rule: 
 +| (saddr == 50.11.69.17/32) accept | 
 +meaning “allow all packets coming from your global IP address out". As the source address of the packet has been changed by the modifier, the packet will be allowed through.
-Then the flow takes the packet to the stateful inspector making sure the packet follows the TCP rules. If the packet violates any of the TCP rules, it will be stopped by the stateful inspection, but all well-behaved packets will be let through.+**13.** Now both the incoming and return packets has been allowed through the firewall. The return 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.
-12. The last stop for the packet through the firewall is the outgoing super rules of the outside interface. This ruleset has a rule:+As you can see, we need 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. And the **modify** action of the incoming rule also helps our outgoing packet to get back out.
-(saddr == 50.11.69.17/255.255.255.255) accept +===== Entering the rules ===== 
-meaning “allow all packets coming from my global IP address out". As the source address of the packet has been changed by the modifier, the packet will be allowed through.+As you can see we need to enter two rules to allow the data through. One in step 2 above and one in step 9. You enter the rules into the "Additional rules" fields of the [[web GUI:security profile]] page: 
 +| LINE | Incoming user | post | dport == 5032 && proto == tcp modify static daddr 192.168.0.31 | 
 +| ET1 | Incoming user | post | saddr == 192.168.0.31 && sport == 5032 && proto == tcp accept | 
 +All other necessary rules are already present in the standard firewall ruleset.
-13. Now both the incoming and return packets has been allowed through the firewall. The return 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. 
-As you can see, we need 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. And the modify action of the incoming rule also helps our outgoing packet to get back out. 
firewall/example_2.1288872281.txt.gz · Last modified: 2010/11/04 13:04 by tibor
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0