DMZ host-host connection via RED dropped by firewall

Hi, I’m struggling with some weird HTTP errors and I think my IPFire box is to blame, but I can’t figure it out.

The Setup:
DMZ server #1 10.0.0.1 is my nginx webserver & ssl proxy.
DMZ server #2 10.0.0.2 is my Onlyoffice document server.
IPFire is configured with DNAT rules (port forwarding to server #1) to allow users to connect to the webserver.
Up to this point everything works fine. Every user can reach the webserver, HTTPS is configured correctly.

What I want to do:
The document server (#2) needs access to files served by the webserver (#1). It basically works like this:

documents@server2:~$ wget https://my.tld/some.file

What I expect:
Server #2 downloads the file from server #1

What happens instead:
Server #2 resolves my.tld to my RED IP and tries to connect. The request times out, server #1 was never reached (no access/error log). But my IPFire logs a dropped connection:

DROP_FORWARD orange0 TCP 10.0.0.2 10.0.0.1

A simple direct connection (wget https://10.0.0.1/some.file) works fine.
Unfortunately, I can’t configure the Onlyoffice server to use this method without breaking everything else.

What firewall rules do I need to make this work?

If i understand your setup correct, you only want access from outside to your server 1 (your reverse proxy). So you dont need any other rule for server 2 because they are on the same subnet, they dont need any rule to reach each other. Or in other words no data go through IPF. This seems your setting problem is your nginx/server2

That is correct. They can reach each other just fine if I use their private IPs.

This is where it gets weird.
Server 2 connects to a URL of server 1, which resolves to the IPFire RED public IP.
The RED IP is then forwarded to server 1:
10.0.0.2 -> lookup & connect to RED IP -> redirect/DNAT to 10.0.0.1

This connection then gets dropped as “DROP_FORWARD” by IPFire.

You can do now the following.

  • You only want access to server 1 from the outside, so why not communicate with IP to reach each other (internal). Looks ok for me.
  • You can set a hosts entry on the server. For example Linux /etc/hosts

To say it this time more clearly :wink: I think this have nothing to do with IPF. No rule missing.

1 Like

Hi Tulpenknicker, thanks

That would also be my preffered solution. Unfortunately there is the following problem: I can only specifiy a single URL which then gets passed to the Javascript/HTML user interface and the Document server.
Therefore specifying a private IP instead of the URL breaks the user interface for all my remote users. Not good at all.

Well, I’m stubborn :grin:
So I took some inspiration from the Wiki and tried it anyway with the following rule:

Source: IP 10.0.0.2 (the client)
Destination: IP 10.0.0.1 (the webserver)
NAT: Source NAT, new Source ORANGE
Protocol: HTTPS

Of course IPFire complained:

The last generated rule may never match, because source and destination subnets may overlap.
Please double-check if this rule makes sense: Source: 10.0.0.2/32 Target: 10.0.0.1/32

But it works fine now!

Obviously I don’t know how exactly this works. So I would appreciate it if someone could explain this to me (or at least confirm that it is safe).

Edit: this is wrong. It’s not a bug.

The complain that 10.0.0.2/32 and 10.0.0.1/32 overlaps is a bug. Check if there is already a bug report in bugzilla. If not open one.

Can you please tell what answer you expected?

If the target is the IPFire itself it should not complain because the rule matches. So it should give no answer and accept the rule.

But its not IPF…

You are correct. It is not a bug. It is correct, The rule matches only because the DNAT rule to RED IP.
But the rule is also the correct solution for the problem.

With the little information the OP gave, the following is given. There is a reverse proxy server with 10.0.0.1. Only this server should accessible in orange. The second server 10.0.0.2 is hidden behind the reverse proxy. For my understanding the following happens. He use a fqdn maybe dyndns or whatever plays not really a role and get back the red ip. So the direction is not internal in 10.0.0.x its now a loop for my understanding. The only thing what you now support is this loop. This rule can not be correct and its for my understanding absolute wrong and not necessary.

So IPFire receive the connection from 1.0.0.2 with target to the RED IP which is translated to 1.0.0.1 by the dnat. So the firewall logs 1.0.0.2 to 1.0.0.1 which need a extra rule because the source is orange. (from red this rule for dnat will autogenerated but not from orange)

1 Like

So I’m not gonna file a bug report :slight_smile:
But would you agree that such a setup should actually work without further rules? I don’t think it’s uncommon for services to interconnect via their public IP/URL. Which (in my opinion) should work without further action as soon as the domain and port forwarding ist set up correctly.

Edit: We posted at the same time. Thank you very much for the explanation! Adding this firewall SNAT rule is therefore correct.

What additional information are you missing? I’d be happy to provide it.

And exactly here ends my understanding. Iam not able to understand this :wink:

The most important question for me is, do i really complete understand your setup? Server 1 only accessible and all goes through this server (because reverse proxy)? If so why its not enough to provide the missing information with a hosts entry. If a IP not enough… So IPF is not involved what for my POV the preferred solution for a server to server connection in the same subnet.

1.0.0.2 sends a request to RED_IP:80 to it’s default gateway which is the IPFire. It will translated to 1.0.0.2 -> 1.0.0.1:80 by the dnat and then runs to the firewall which has no rule for this connection.

1 Like