The scenario

We have a web server behind a NetWall firewall that handles our company website. We want users behind the firewall to be able to surf to our website by using the server’s public IP address via a DNS lookup of the URI. However, this does not work for clients that are on the same network as the web server.

Note: This scenario is most frequently encountered when using legacy IP Rules instead of the newer IP Policy. However, it can still occur with an IP Policy, depending on how the network and cOS Core rule sets are configured. It is, in fact, quite unusual to place the client and public web server(s) in the same layer 2 segment. It is usually recommended to place such servers behind their own interface on a separate network behind the firewall (sometimes referred to as the DMZ network).

The problem

In most scenarios this would work fine. The problem occurs when we have users on the same network segment as the web server and those users are trying to access the server’s external public IP. The diagrams below illustrate the packet flow direction problem. This first diagram illustrates a scenario that works fine using the standard SAT/Allow IP rule combination.

This second diagram below illustrates the scenario where things do not work (due to the web server being on the same network as the client):

The solution

The solution is to address translate the connection from the client to the web server. So if we use scenario-2 as example we have the following rule setup:

SAT Any All-Nets Core IP_Wan HTTP SetDest=Webserver
Allow Any All-Nets Core IP_Wan HTTP

We then create a NAT rule between the SAT and the Allow rule that triggers for traffic from the Lan interface like this:

SAT Any All-Nets Core IP_Wan HTTP SetDest=Webserver
NAT Lan Lannet Core IP_Wan HTTP
Allow Any All-Nets Core IP_Wan HTTP

When traffic arrives at the web server with this setup, it will see that the sender is its own gateway address (192.168.100.1) and will reply to this IP. The packet flow will be intact as the firewall handles the entire conversation. The reply is sent back to the client by the firewall based on the connection created earlier.

An alternative solution would be to only change the allowing rule set entry to trigger for external traffic, like this:

SAT Any All-Nets Core IP_Wan HTTP SetDest=Webserver
Allow Wan All-Nets Core IP_Wan HTTP

This way, the Allow IP rule will not trigger if you connect from the Lan interface. cOS Core will continue through the rule set to try find a matching Allow or NAT rule for the SAT rule. In most cases the administrator will have created an outgoing NAT rule somewhere in the rule set. They should just must make sure that the SAT IP rule is above the NAT IP rule so it triggers first.

Note: If using IP Policy instead of IP Rule, simply set the source translation to be NAT instead of the default <auto> value.

Related articles

No related articles found.