1

I have a CentOS 7 box with 2 NICs acting as a gateway; one NIC is connected to the internet while the other NIC is connected to our LAN.

The first NIC belongs to the 'external' zone of firewalld, it has masquerading on and is set to forward port 22, 80 and 443 to those boxes inside the internal network that manage SSH and the web servers; let's say that, from the internet, the box appears as "example.com" at address "1.2.3.4" while its name in the LAN is "gateway.lan" with address "192.168.1.1".

Everything works, with a significant caveat; since we want to be able to connect via SSH using the internet name of the box (ssh example.com) also from within the LAN (where the SSH box is named "server.lan" and has address 192.168.1.10), the only way to make this work seems to be setting a rule in firewalld's 'internal' zone forwarding all accesses to port 22 of "1.2.3.4" back to port 22 of the SSH box:

internal (active)
target: default
icmp-block-inversion: no
interfaces: XXXXXX
sources:
services: dns
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
      rule family="ipv4" destination address="1.2.3.4" forward-port port="22" protocol="tcp" to-port="22" to-addr="192.168.1.10"

The rule alone does not work unless masquerading is on for the 'internal' zone; unfortunately, this also obviously causes the external IPs that hammer that box trying to brute-force a root password to appear as coming from "192.168.1.1" (the "gateway.lan" address) in the logs of "server.lan", which makes it impossible to use Fail2Ban on the "server.lan" box to hamper the thousands of daily attempted accesses.

What am I doing wrong? I think enabling masquerading on the "internal" zone is conceptually wrong but I could find no other way the make the firewalld rule work. I have no qualms in keeping the masquerading on but I'd like to know how Fail2Ban may be then made to work when behind a gateway...

Any advice to any other way to make a configuration like this work as I'm expecting?

Francesco
  • 45
  • 9

1 Answers1

1

Ah, we did it! And it was relatively easy (well, once you know how)...

We had correctly surmised that masquerading on the "internal" zone was not to be globally enabled but it was to be limited to packets originating from the LAN that are routed towards the public IP.

This implies not indiscriminately enabling it with --add-masquerade for the whole zone but using masquerade INSIDE a specific rich rule, in the following form:

firewall-cmd --zone=internal --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 destination address=192.168.1.10 masquerade'

For a while we were fooled by the fact that we insisted on using the public IP "1.2.3.4" as "destination address" instead of the internal one "192.168.1.10" in the rule; we didn't get that, once traveling through the "internal" zone, packets targeting port 22 of "1.2.3.4" are already converted by the rich rule into the LAN address of the SSH box. Moreover, this syntax does NOT allow specifying a port.

The final status for the "internal" zone is as follows:

internal (active)
target: default
icmp-block-inversion: no
interfaces: XXXXXX
sources:
services: dns
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
      rule family="ipv4" destination address="1.2.3.4" forward-port port="22" protocol="tcp" to-port="22" to-addr="192.168.1.10"
      rule family="ipv4" source address="192.168.1.0/24" destination address="192.168.1.10" masquerade

which:

  • correctly reroutes SSH access from the internet to the SSH box - of course this also requires in the "external" zone a forward rule for port 22 towards the same port on the "internal" one;
  • lets LAN machines indifferently SSH into the box with its public or LAN name;
  • does not mask the addresses of malicious SSH attempts from the internet to the box so that Fail2Ban can perform its job.

Cheers!

Francesco
  • 45
  • 9