[[tutorial|Firewall rule tutorial]] example 4:

====== "Hijacking" a site ======

^ :!: This description is addressed to advanced users only. ^
| Incorrect editing of the firewall rules may cause security risks! |

As you can see by [[example 2|examples 2]] [[example 3|and 3]], it is usually the outside interface that handles the flows. But all interfaces are capable of creating flows.

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 our own internal web server (192.168.10.31).

{{:firewall:setup_fwall4.gif|Firewall path. See steps below for description.}}

**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** |

This needs some explanation.

**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.

**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%%!

**6.** The answer will be addressed back to 192.168.0.31, and sent to the ET4 interface.

**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 |

**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 |

**9.** The router sends the packet to ET1 as it is that interface that handles the 192.168.0.x subnet.

**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**.

**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.