Routing traffic through wrong interface

Hi Christian,

Is the .14 defined as a Host in the UTM? If so, my first idea would be to have a look at Definitions & Users, Network Definitions, and click the button labeled as "show where this object is in use". It might be a rule routing this Host thru ETH1 that you are not aware of. Or maybe the Host is member of a group that is treated somewhere.

Basically there are two possibilities: The Host is routed according to your rules over ETH1, and you missed one of the rules. Or it is not covered by any rules and the general routing takes place over ETH1.

If this doesn't work out, I hope someone else can help you further. It could be that there are some leftover rules which are not shown in the GUI. This could be fixed on command line. Or probably by deleting the host within the GUI and setting it up again.

Good luck!

Axel

Hi Axel.

Just a quick response about what I found:

I found the reason, why I can route .10 through eht7. My bad: we put Cloudflare between us and the .10. So, our sites that are bound through .10 are resolving with a different IP, this is why .10 routing through eth7 correctly. It looks like this:

internal network: www. xyz . com (resolves to Cloudflare's IPs) -> UTM:eth7 -> Cloudflare -> (different firewall):.10 -> apache

I guess that, without Cloudflare, .10 wouldn't go over eht7.

So my situation currently is:

UTM:eth1 is default gateway (gw => 123.123.123.1) and has bound the following IP adresseses

123.123.123.3/28 to 123.123.123.14/28, with the exception of .10 and .14.

UTM:eth7 is default gateway (gw => 192.168.178.1) and is on DHCP, DHCP-server is a FritzBox.

So here comes the point that may be I am thinking wrong about:

I thought, I can route from internal network (192.168.0.x/24) to 123.123.123.14 through eth7, but this isn't possible.

When I should guess why, I would say that this is because I want to access an IP-Adress wich Subnet is bound to a different interface. This puts me in a problematic situation and I currently have no solution to fix this.

Regards, Christian

Christian, good to hear you found out about the first issue. The new issue is above my horizon, but I guess someone else on here will be able to help.

A quick idea I have for you: as far as I know, firewall rules are walked thru from top to bottom. So probably re-arranging some of your rules could help. Place the rule "from 0.x. to .123.14 thru ETH7" above the rules for the default gateway and it may work. I don't know if the same applies for routing, but it could be.

But, I don't want you to look into stuff that is probably not really true, so I am hoping someone else will chime in.

Hi.

Do you mean re-arranging NAT rules? We do not have such thing than a common/general gateway firewall rule.

We do this either by NAT (that automatically create firewall rules) and Multi-path.

I am not quite sure, that putting them higher to the top has an effect. I was thinking about splitting our /28 into smaller parts. But a) I don't know, if this is possible, b) something complete new for me and c) for my understanding, we have first to move the IP addresses for our services because currently they are spread across the /28 space.

Hgrmpf. ;-)

Regards, Christian

I need a picture.    I think you describe something like this:

Intranet                                                   Intranet
|                                                               |
New Firewall                                             UTM ---- dial-up users
|                                                               |
--------------------Internal Network--------------
   |
Internal Clients

I think you want UTM to send some internet-bound traffic to "New Firewall" even though UTM can easily send it to the Internet using its own interface.  Is this correct?

Which device is the default gateway for your Internal Clients -- UTM, New Firewall, or a router that is not shown?

We also need clarity about the traffic that you want to redirect:

- no filtering expected - traffic should flow directly from Internal Client to New firewall

- UTM filtering with a Transparent Mode proxy - traffic should flow to UTM but be forced over to New Firewall after filtering.

- UTM filtering with a Standard Mode proxy - traffic is sent to UTM then relayed to New Firewall after filtering.

I am not convinced that any of these things are possible, but we need to start with a more precise problem statement.

Hi Douglas. I am not good at ASCII art, so I painted it on a paper:

The UTM eth1 interface has 123.123.123.3/28 as primary IP with some other IPs, relating to this subnet. We use eth1 for incomming traffic such as Citrix, in/outbound Email, ... . The interface eth7 is on DHCP by the FritzBox router. eth7 is the gateway, handling client traffic (http(s)) that goes out on the internet. So when I open up a client browser and go to ripe.net, I see the IP of the FritzBox, not the one of eth1.

The new firewall has 123.123.123.10/28 and 123.123.123.14/28. When I now try to access a site that resolves to 123.123.123.10/28 from a client on the internal network, traffic gets routed through UTM eth1 and the new Firewall drops it because it sees that the IP packages has a private IPv4 address - the one from the internal client.

What I want is, that clients go through UTM eth7, even when accessing 123.123.123.10/28 and 123.123.123.14/28.

Regards, Christian

I basically see two options for you:

1. SNAT traffic from INTERNAL using service ANY to .10 translate source to fritzbox.

2. Route the traffic thru fritzbox, so it physically takes the long route.

If this does not help: at least your painting looks great! :-)

Hi.

SNAT is always my first option for things like this, so I tried this without success.

Same result, the request times out because the other firewall sees incoming requests from internal client ip addresses and drops it. The leaves the UTM over eth1, SNAT gets ignored.

I guess, I have to consider splitting my subnet and bind one part at the new firewall and one at the UTMs eth1. I think, the UTM cannot route traffic for a subnet, bound to eth1 over a different interface... Maybe I have here a misunderstanding of IP routing in general and this has nothing to do with UTM in special.

reag said:

If this does not help: at least your painting looks great! :-)

:-D

Regards, Christian

You cannot have your new firewall entirely on the internet.    Besides, in that position it cannot add any value other than changing the source address.   If you just want to use a special source address for some devices, SNAT will do what you want with just UTM.

You cannot have your new firewall entirely on the internet.    Besides, in that position it cannot add any value other than changing the source address.   If you just want to use a special source address for some devices, SNAT will do what you want with just UTM.

Hi.

DouglasFoster said:

You cannot have your new firewall entirely on the internet.

Hm, I am not sure what you mean because this is the way it works right now. The only side effect I am seeing is, that I cannot route from one FW to the other.

The value for me is, that I have physically divided networks with own IP addresses, servers and switches behind both firewalls.

So, if we assume, a hacker has access to a server behind one of my firewalls, he is on the internal side of my network, when the firewall is the UTM. Even if there is a VLAN, dividing the hacked server and my client network, he is behind my UTM. I don't have to care about Switch-ACLs, VLANs or any other stuff that puts walls between the hacked server and my internal client network.

Now, he "only" is behind a second firewall and hasn't any physical connection to the network behind the UTM. Right, he is on the server, but is not able to get into production systems or databases any other than is on the network behind the second firewall. So let's say, he is on the "public side" of our network. 

Changing the source address (the one that the communication comes from when communicating with the internet) is done by UTM itself, when using a different interface than eth1. We once used this for outgoing emails send through a specific public IP address.

I agree about SNAT. But, as written before, it does not work for me here and I was curious about why.

Regards,

Christian

It sounds like your real objective is a DMZ, to separate dial-up from internal users.   The DMZ needs its own subnet on a private IP, perhaps 10.10.10.0/24.   Options can be:

One device, three interfaces:

Internet-UTM-Internal
               \___DMZ-dialup

Two devices:

Internet-UTM-DMZ-Firewall-Internal
                \___dialup

or

Internal-Firewall-DMZ-UTM-Internal
                \___dialup

Assuming that you want UTM filtering on both dial-up and internal connections, UTM needs to be in front, so I would just use the UTM with three interfaces, eliminating the firewall.   Then you configure what can and cannot be done using standard UTM features like Allowed Networks lists and User Groups.

UTM with three zones can be a little tricky because you have to configure each proxy separate to ensure that you have correctly controlled what is allowed from DMZ to Internal.   There is a KB article to help.

The DMZ eliminates the need for SNAT.    

Hi.

First, let me thank you all for your thoughts and your support :-)

DouglasFoster said:

It sounds like your real objective is a DMZ, to separate dial-up from internal users.   The DMZ needs its own subnet on a private IP, perhaps 10.10.10.0/24.   Options can be:

You are right, my objective is a DMZ with own private IPv4/v6 subnets, physically divided from my UTM and its networks.

If you mean by "dial-up" that users connecting over the internet into the internal network, than the answer is no. I mentioned "dialup" above, meaning that the internet line is a dialup and not a permanent connection. It gets kicked every 24h and has to dial up again. And this line is only used for getting web traffic for our internal users into the internet. There are no other services associated with this internet connection.

To make this clear, there is no reason for _direct_ communication from the DMZ (behind the new firewall) to the (internal network behind the) UTM.

In the DMZ behind the new firewall, there are only webservers and some (next-/own/...)-cloud stuff, that can be securely accessed through the internet. No user has direct access to the network behind the new firewall, no DHCP is running there, no VPN access is allowed for anyone.

I am currently in the phase of talking with my carrier about splitting our /28 in two /29 networks, so that my UTM and my new firewall have its own real IPv4 networks. I think, this makes routing a lot easier.

Regards, Christian