Differences

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

--- firewall:example_4 [2010/11/04 13:43] – created tibor
+++ firewall:example_4 [2010/11/04 14:00] (current) – tibor
@@ Line 10: / Line 10: @@
 It is however very seldom you need to create any flows on any other interfaces than the outside one. But there are certain special cases that demand use of flows on inside interfaces.
-In this example we will redirect all www.yourcompany.com web accesses to your own internal web server (192.168.10.31).
+In this example we will redirect all %%www.yourcompany.com%% web accesses to our own internal web server (192.168.10.31).
-. 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.
+{{:firewall:setup_fwall4.gif|Firewall path. See steps below for description.}}
-. The next stop for the packet will be the incoming user rules of the ET2 (inside) interface. Here we do the actual “hijack":
+**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.
+**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.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.
+**4.** The **outgoing user** and **super rules** of the ET4 interface are both **proto != noproto accept** thus they allow the packet through.
-modify static daddr 192.168.10.31 results in modifying the destination address in the packet to 192.168.10.31.
+**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 outgoing user and super rules of the USB interface are both proto != noproto accept  thus they allow the packet through.
+**6.** The answer will be addressed back to 192.168.0.31, and sent to the ET4 interface.
-. 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!
+**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 |
-. The answer will be addressed back to 192.168.0.31, and sent to the USB interface.
+**8.** The **incoming user rules** of the **ET4** 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 |
-. The incoming super rules of the USB interface allow the return packet through, as it comes from the 192.168.10.x subnet.
+**9.** The router sends the packet to ET1 as it is that interface that handles the 192.168.0.x subnet.
-saddr == 192.168.10.1/255.255.255.0 accept
+**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 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.20.1/255.255.255.0 || daddr == 192.168.0.1/255.255.255.0 accept
+**11.** The outgoing super rules of ET1 allow all packets through.
-. 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.
+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!
-. The outgoing super rules of ET2 allow all packets through.
+===== 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!