Differences

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

--- firewall:example_4 [2010/11/04 13:45]
tibor
+++ firewall:example_4 [2010/11/04 14:00] (current)
tibor
@@ Line 12: / Line 12: @@
 In this example we will redirect all %%www.yourcompany.com%% web accesses to our own internal web server (192.168.10.31).
-{{:firewall:setup_fwall4.gif|}}
+{{:firewall:setup_fwall4.gif|Firewall path. See steps below for description.}}
-. The web access will come as a TCP packet from your PC (192.168.0.31) going to port 80 of IP Address 80.244.64.10 (the IP address www.yourcompany.com resolves to). The packet arrives to the incoming super rules of the ET2 (inside) interface. That ruleset already contains a saddr == 192.168.0.1/255.255.255.0 accept  rule allowing the packet through.
+**1.** The web access will come as a TCP packet from your PC (192.168.0.31) going to port 80 of IP Address 80.244.64.10 (the IP address %%www.yourcompany.com%% resolves to). The packet arrives to the **incoming super rules** of the **ET1 (inside)** interface. That ruleset already contains a **saddr == 192.168.0.1/24 accept** rule allowing the packet through.
-. The next stop for the packet will be the incoming user rules of the ET2 (inside) interface. Here we do the actual “hijack":
+**2.** The next stop for the packet will be the **incoming user rules** of the **ET1 (inside)** interface. Here we do the actual “hijack":
+| **daddr ==  %%www.yourcompany.com%% modify static daddr 192.168.30.31** |
-daddr ==  www.yourcompany.com modify static daddr 192.168.10.31
 This needs some explanation.
-daddr == www.yourcompany.com is resolved to daddr == 80.244.64.10 when the security profile becomes activated.
+**daddr == %%www.yourcompany.com%%** is resolved to **daddr == 80.244.64.10** when the security profile becomes activated.((Please notice that it is resolved only **once**, at the time firewall rules are loaded. It is **not** resolved for each packet received! Also, if the URL resolves to several IP addresses only one of them will be used!))
-modify static daddr 192.168.10.31 results in modifying the destination address in the packet to 192.168.10.31.
+**modify static daddr 192.168.30.31** results in modifying the destination address in the packet to 192.168.30.31, an address on the ET4 subnet. The router will forward the packet to ET4.
-. The outgoing user and super rules of the USB interface are both proto != noproto accept  thus they allow the packet through.
+**4.** The **outgoing user** and **super rules** of the ET4 interface are both **proto != noproto accept** thus they allow the packet through.
-. The packet is thus sent out on the USB interface to port 80 of the 192.168.10.31 PC connected to it. If you run a web server on that PC, that web server will answer instead of www.yourcompany.com!
+**5.** The packet is thus sent out on the ET4 interface to port 80 of the 192.168.30.31 PC connected to it. If you run a web server on that PC, that web server will answer instead of %%www.yourcompany.com%%!
-. The answer will be addressed back to 192.168.0.31, and sent to the USB interface.
+**6.** The answer will be addressed back to 192.168.0.31, and sent to the ET4 interface.
-. The incoming super rules of the USB interface allow the return packet through, as it comes from the 192.168.10.x subnet.
+**7.** The **incoming super rules** of the **ET4** interface allow the return packet through, as it comes from the 192.168.10.x subnet:
+| saddr == 192.168.30.1/24 accept |
-saddr == 192.168.10.1/255.255.255.0 accept
+**8.** The **incoming user rules** of the **ET4** interface also allow the packet through, as it goes to the 192.168.0.x subnet:
-. The incoming user rules of the USB interface also allow the packet through, as it goes to the 192.168.0.x subnet:
+| daddr == 192.168.50.1/24 %%||%% daddr == 192.168.0.1/24 accept |
-daddr == 192.168.20.1/255.255.255.0 || daddr == 192.168.0.1/255.255.255.0 accept
+**9.** The router sends the packet to ET1 as it is that interface that handles the 192.168.0.x subnet.
-. The router sends the packet to ET2 as it is that interface that handles the 192.168.0.x subnet.
-. As we have created a flow and a return flow in step 2 above, the outgoing user rules of ET2 are ignored, as the return packet matches the return flow.
+**10.** As we have created a flow and a return flow in step 2 above, the outgoing user rules of ET1 are **ignored**, as the return packet matches the **return flow**.
-. The outgoing super rules of ET2 allow all packets through.
+**11.** The outgoing super rules of ET1 allow all packets through.
+Now all data flows headed to %%www.yourcompany.com%% are “hijacked" and redirected to your internal server, without your web browser noticing anything. An otherwise impossible task to configure is very easily done by manually adding one simple rule to the right ruleset!
+===== 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 | daddr == %%www.yourcompany.com%% modify static daddr 192.168.10.31 |
+All other necessary rules are already present in the standard firewall ruleset.
-Now all data flows headed to www.yourcompany.com are “hijacked" and redirected to your internal server, without your web browser noticing anything. An otherwise impossible task to configure is very easily done by manually adding one simple rule to the right ruleset!

firewall/example_4.1288874710.txt.gz · Last modified: 2010/11/04 13:45 by tibor

Show page Old revisions