WebProtection: Routing to Internal Networks when "Optional: Interface for Outgoing traffic" is used

Hi, Daniel, and welcome to the UTM Community!

I like Doug's suggestion, but your topology isn't clear to me.  Perhaps a simple diagram or pictures of the Edits of your Web Filtering Profiles?

Cheers - Bob
PS Moving this thread to the Web Protection forum.

Network.pdf

Hi,

I created an overview of the network topology.

So there are connected multiple customers to the UTM with an IPsec tunnel. We have configured the webfilter profiles with "Optional: Interface for Outgoing traffic", so that every customer gets another outgoing IP for Web Surfing.

Now if the customer (e.g. Client 10.2.0.1) connects to Webserver 22.33.44.55 everything works fine. But if the customer wants to connect to 10.0.0.1, the proxy shows the error "an error occoured while handling your request (no route to host)".

I think it is because we have staticaly assigned an outgoing Interface (e.g. eth1) and of course the Webserver 10.0.0.1 is not reachable over this interface.

When we assign the network 10.0.0.0/24 to "Skip Transparent Mode Destination..." in the webprotection settings it works, because then the normal routing tables are used.

Now I want to know if it is possible to user the Proxy also for the internal webservers and use the option "Optional: Interface for Outgoing traffic"

Regards,

Daniel

Thanks, Daniel, that helps!

It looks like A & C are connected as in Hub and Spoke Site-to-Site VPNs.  In that case, you should skip the Proxy as you have done.

If A is not the same corporation as C, I agree with Doug about accessing 10.0.0.1 via WAF.  That would require modifying the tunnel to NOT include the direct connection between A & C and to make some DNS changes and to modify the webserver to look for the X-FORWARDED-FOR header.

In order to reach the server at 22.33.44.55 through an IPsec tunnel, you would need to add it to the tunnel, but I don't think that was a part of your question.

Cheers - Bob

You don't seem to embracing the idea of using WAF for access to non-internet websites, so I will talk a little about the alternative.

Assume you have a client-facing webserver on 192.168.x.5

You also have switches, routers, wireless hardware, and other web-capable systems on 192.168.x.0/24

In the Filter Action for Client A, 

• create an allow rule for 192.168.x.5 and its host name (web1.example.local)
• create a block rule for 192.168.x.0/24 and a regex or name block for your internal domain suffix (example.local).  You could also use a website tag instead of a regex block.

This configuration should work because Support has told me that the priority sequence in a Filter Action is:

• Allow website/regex rules have highest priority.
• Block website/regex rules apply next.
• Tag rules (block or allow) are applied third.
• Category and reputation rules apply when none of the above are applicable.

If tags conflict, I assume that the most extensive match takes precedence.   However, I have never needed a Filter Action with overlapping allow/block rules, so you should test thoroughly.

Another approach is to verify that all of your private websites will be evaluated as uncategorized, then have a rule to block all uncategorized sites.   Because of some glitches in the way UTM applies categories, this tactic leads to a lot of internet web pages being blocked, so it may do more than you want.

You don't seem to embracing the idea of using WAF for access to non-internet websites, so I will talk a little about the alternative.

Assume you have a client-facing webserver on 192.168.x.5

You also have switches, routers, wireless hardware, and other web-capable systems on 192.168.x.0/24

In the Filter Action for Client A, 

• create an allow rule for 192.168.x.5 and its host name (web1.example.local)
• create a block rule for 192.168.x.0/24 and a regex or name block for your internal domain suffix (example.local).  You could also use a website tag instead of a regex block.

This configuration should work because Support has told me that the priority sequence in a Filter Action is:

• Allow website/regex rules have highest priority.
• Block website/regex rules apply next.
• Tag rules (block or allow) are applied third.
• Category and reputation rules apply when none of the above are applicable.

If tags conflict, I assume that the most extensive match takes precedence.   However, I have never needed a Filter Action with overlapping allow/block rules, so you should test thoroughly.

Another approach is to verify that all of your private websites will be evaluated as uncategorized, then have a rule to block all uncategorized sites.   Because of some glitches in the way UTM applies categories, this tactic leads to a lot of internet web pages being blocked, so it may do more than you want.