On Fri, Jan 19, 2024 at 03:00:53PM +0100, Django [Bastard Operator from Hell] wrote:
HI Eric,
On 18.01.24 22:29 Eric Garver wrote:
So either I'm stupid or old or a combination of both, so hard to understand
Maybe it would help to start over. Start from scratch, describe your topology, then tell us what you'd like to do. From what I can glean your goals aren't too complex.
First of all, thank you for your patience and help!
I will gladly take up your suggestion and describe my surroundings again.
My network-topology loooks like:
### Internet ### | | V +-----------+ | | | FWA | | | +-----------+ | --EDMZ--+ | V +-----------+ | | 2003:a:b:c0:1920:168:0:210 | FWB | fe80::1921:68ff:fe00:210/64 | | fd00::192:168:0:210/64 +-----------+ | --IDMZ--+------------------ [web, mail ...] | V +-----------+ | | 2003:a:b:c1:10::110/64 | FWC | fe80::1:10:ff:fe00:110/64 | | fd00::1:10:0:0:110/64 +-----------+ | | V ### Intranet ###
So:
Let us now only consider the firewall named as FWB on the host vml000210. This host (vml000210) separates the EDMZ zone from the IDMZ zone. This host has two network interfaces, eth0 points in the direction of EDZ and eth1 points in the direction of IDMZ. The network interfaces on this host are configured using systemd-networkd.
Please include interfaces and subnet addressing in your description. You can obfuscate them.
Both IPv4 and IPv6 addresses are used on Host vml000210:
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:41:21:01 brd ff:ff:ff:ff:ff:ff altname enp1s0 inet 192.168.0.210/24 brd 192.168.0.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2003:a:b:c0:1920:168:0:210/64 scope global valid_lft forever preferred_lft forever inet6 fd00::192:168:0:210/64 scope global valid_lft forever preferred_lft forever inet6 fe80::1921:68ff:fe00:210/64 scope link valid_lft forever preferred_lft forever
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:41:21:02 brd ff:ff:ff:ff:ff:ff altname enp2s0 inet 10.0.0.210/24 brd 10.0.0.255 scope global eth1 valid_lft forever preferred_lft forever inet6 2003:a:b:c1:10::210/64 scope global valid_lft forever preferred_lft forever inet6 fd00::1:10:0:0:210/64 scope global valid_lft forever preferred_lft forever inet6 fe80::1:10:ff:fe00:210/64 scope link valid_lft forever preferred_lft forever
Let us now look in detail at the traffic directions allowed or to be blocked on the FWB firewall. The following IP traffic (IPv4 and IPv6) should be permitted:
- Traffic from outside (incoming from the EDMZ zone) on the network
interface eth0):
1.1) The host vml000210 should be reachable and respond via ICMP, in short it may be "pingable".
1.2) Basically all ports and services are to be blocked from the outside, only the following traffic is permitted:
1.2.1) Response packets to traffic reaching the host vml000210 on the network interface eth0 from the zone IDMZ must be accepted and forwarded to the network interface eth1, i.e. the zone IDMZ.
1.2.2) Traffic from outside on port 22 (Service SSH) is permitted and should be accepted.
1.2.3) Traffic from outside the ZONE EDMZ to hosts from the zone IDMZ is not allowed, but blocked.
1.2.4) Only external traffic from the EDMZ ZONE to the host vml000110 with the IPs (10.0.0.110 and 2003:a:b:c1:10::110) is permitted for the SMTP service on ports 25, 465 and 587 and is only forwarded from the EDMZ zone to the IDMZ ZONE to the host vml000110.
1.2.5) Traffic from outside the ZONE EDMZ is permitted to the host vml000120 with the IPs (10.0.0.120 and 2003:a:b:c1:10::120) for the IMAP/POP3 services on ports 110, 143, 993 and 995 and is therefore only passed through from the zone EDMZ to the ZONE IDMZ to the host vml000120.
1.2.6) On the other hand, attempts to reach the host vml000120 with the IPs (10.0.0.120 and 2003:a:b:c1:10::120) on SMTP port 25 from outside the ZONE EDMZ, for example, are not permitted and must therefore be blocked.
- Traffic from the IDMZ zone with the associated network interface eth1 is
only permitted for the following traffic:
2.1) ICMP
2.1.1) From the host vml000210 with the IPs (10.0.0.210 and 2003:a:b:c1:10::210) every host in the IDMZ zone and also every host outside the EDMZ zone, i.e. the Internet, may be pinged.
2.1.2) The two hosts vml000110 (0.0.0.110 and 2003:a:b:c1:10::110) and vml000120 (10.0.0.120 and 2003:a:b:c1:10::120) may also ping the host vml000210 (10.0.0.210 and 2003:a:b:c1:10::210) and any host on the Internet.
2.2) HTTP(S) traffic from any source/host from the IDMZ zone is allowed in the direction of the EDMZ zone, i.e. in the direction of the Internet.
2.3) SMTP
2.3.1) SMTP traffic from host vml000110 in the direction of the Internet on ports 25 and 465 is permitted
2.3.2) Any other SMTP traffic, e.g. from host vml000120 (10.0.0.120 and 2003:a:b:c1:10::120) in the direction of the EDMZ zone is not permitted and must therefore be blocked.
2.4) POP3/IMAP:
2.4.1) Only the host vml000210 (10.0.0.210 and 2003:a:b:c1:10::210) responds to traffic it receives from the EDMZ zone on ports 110, 143, 993 and 995.
2.4.2) If other hosts from the IDMZ zone, e.g. the host vml000110 (0.0.0.110 and 2003:a:b:c1:10::110), attempt to reach another POP3/IMAP server on the Internet on ports 10, 143, 993 and 995, this must be prevented and blocked.
O.K. so far, so good, I hope the topology is now a little clearer and you can see what I'm up to. Please let me know if anything is still unclear, I will of course be happy to answer any questions!
Now let's turn to what I've done so far.
Step I: First of all, I had the virtual machine vml000210 rebuilt so that I could start from scratch.
Step II: I installed the firwalld package using the package manager.
Step III: I created a zone for each of the two zones IDMZ and EDMZ: # firewall-cmd --permanent --new-zone=edmz # firewall-cmd --permanent --new-zone=idmz # firewall-cmd --reload
Step IV: In the firewalld configuration file /etc/firewalld/firewalld.conf I have set the option DefaultZone=edmz. # vim /etc/firewalld/firewalld.conf
... # default zone # The default zone used if an empty zone string is used. # Default: public DefaultZone=edmz ...
Step V: I then assigned the two zones to their respective interfaces. # firewall-cmd --permanent --zone=edmz --add-interface=eth0 # firewall-cmd --permanent --zone=idmz --add-interface=eth1 # firewall-cmd --permanent --zone=idmz --add-interface=lo
No need to configure "lo". Traffic is always accepted on "lo".
# firewall-cmd --reload
Step VI: I have now assigned the network 10.0.10.0/24 and 2003:a:b:c1:10::/64 to the idmz zone. # firewall-cmd --permanent --zone=idmz --add-source=10.0.10.0/24 # firewall-cmd --permanent --zone=idmz --add-source=2003:a:b:c1:10::/64 # firewall-cmd --reload
Isn't this redundant with assigning eth1 to idmz? Or perhaps 10.0.10.0/24 belongs to yet another interface?
I am not quite sure whether the two networks from the link-local scope (fd00...) and site-local scope (fe80...) should also be defined here for the sake of completeness.
No. They probably should not. ICMPv6 is enabled by default via policy allow-host-ipv6. This covers IPv6 bring up, ND, etc.
Step VII: I have assigned grids 10.0.0.0/24, 2003:a:b:c0::/64 and so whole internet ::/0 to the edmz zone.
# firewall-cmd --permanent --zone=edmz --add-source=10.0.0.0/24 # firewall-cmd --permanent --zone=edmz --add-source=2003:a:b:c0::/64 # firewall-cmd --permanent --zone=edmz --add-source=::/0 # firewall-cmd --reload
Again, this is redundant with assigning eth0 above.
I think in your setup, don't worry about addresses. Only deal with interfaces.
Step VIII: I have activated masquerading for the IPv4 TRaffic that the firewalld should forward from the idmz zone in the direction of edmz. # firewall-cmd --permanent --zone=edmz --add-masquerade # firewall-cmd --reload
Step IX: So that the SSH daemon can accept traffic from the idmz zone on port 25, I have allowed the ssh service in the idmz zone. # firewall-cmd --permanent --zone=idmz --add-service=ssh # firewall-cmd --reload
Step X (part one): So that the SSH daemon can accept traffic from the edmz zone on port 25, I have alsow allowed the ssh service in the edmz zone. # firewall-cmd --permanent --zone=edmz --add-service=ssh # firewall-cmd --reload
Step X (part two): Let us now define external access, i.e. from the edmz zone, a little more specifically. If an SSH client comes from the EDMZ network 192.168.0.0/24 or 2003:a:b:c0::/64, it reaches the SSH daemon directly on port 22 - service ssh. All others from external networks, on the other hand, cannot reach the SSH daemon on port 22, but only via the high port 41022.
First we remove Service ssh from zone edmz. # firewall-cmd --permanent --zone=edmz --remove-service=ssh # firewall-cmd --reload
Then we allow ssh traffic to our host from specific networks: # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv4" source address="192.168.0.0/24" \ destination address="192.168.0.210" \ service name="ssh" accept' # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv6" source address="2003:a:b:c0::/64" \ destination address="2003:a:b:c0:1920:168:0:210" \ service name="ssh" accept' # firewall-cmd --reload
This looks good. I'm not sure you need to specify the destination address though. I assume 192.168.0.210 is FWB's eth0 (edmz interface).
Then we use portforwarding for all other networks. # firewall-cmd --permanent --zone=edmz \ --add-forward-port=port=41022:proto=tcp:toport=22:toaddr=192.168.0.210
Assuming 192.168.0.210 is FWB, then this creates a local redirect for port 41022 to 22. toaddr is also not necessary if it's the local machine (FWB).
# firewall-cmd --permanent --zone=edmz \
--add-forward-port=port=41022:proto=tcp:toport=22:toaddr=2003:a:b:c0:1920:168:0:210 # firewall-cmd --reload
OK, up to this point it wasn't rocket science, I just transferred my 10-year-old IPv4 firwalld configuration to the new dual-stack host and adapted it for IPv6.
Step XI: What is still missing, for example, is the direct access from the edmz zone (the whole internet) to the host vml000110 (10.0.0.110 2003:a:b:c1:10::110) to the ports of the SMTP daemon 25, 587 and 465.
These will be forward ports since you have enabled masquerading above. I'm assuming that external nodes (edmz) won't have a route to 10.0.0.110.
Something like...
firewall-cmd --permanent --zone edmz --add-forward-port=port=25:proto=tcp:toport=25:toaddr=10.0.0.110
.. repeat for other ports and addresses.
If I have understood the concept of firewalld correctly, then there is no point in using a specific rich-rule in zone edmz fpr traffic forwarding to a host in zone idmz. Since rich rules in the zone only apply to the input ruleset, right? What I need here is a firewalld policy if I have understood you correctly.
Maybe? It depends on if 10.0.0.110 is routable from edmz. If yes, then the below policy will work. If no, then you need a forward port as I say above AND you would access them via FWB's edmz IP address.
# firewall-cmd --permanent --new-policy NAT_edmz_to_idmz # firewall-cmd --permanent --policy NAT_edmz_to_idmz \ --add-ingress-zone edmz # firewall-cmd --permanent --policy NAT_edmz_to_idmz \ --add-egress-zone idmz # firewall-cmd --permanent --policy NAT_edmz_to_idmz \ --set-target REJECT # firewall-cmd --permanent --policy NAT_edmz_to_idmz \ --add-rich-rule='rule family="ipv4" \ destination address="10.0.0.110" \ service name="smtp" accept' # firewall-cmd --permanent --policy NAT_edmz_to_idmz \ --add-rich-rule='rule family="ipv6" \ source address="::/0" \
Source is unnecessary here. Try removing this.
destination address="2003:a:b:c1:10::110" \ service name="smtp" accept'# firewall-cmd --reload
From the host vml000210 I can reach port 25 on the host vml000110 via IPv4 as well as IPv6:
root@vml000210:~# telnet 10.0.0.110 25 Trying 10.0.0.110... Connected to 10.0.0.110. Escape character is '^]'. 220 vml000110.localdomain ESMTP Postfix quit 221 2.0.0 Bye Connection closed by foreign host.
root@vml000210:~# telnet 2003:a:b:c1:10::110 25 Trying 2003:a:b:c1:10::110... Connected to 2003:a:b:c1:10::110. Escape character is '^]'. 220 vml000110.localdomain ESMTP Postfix quit 221 2.0.0 Bye Connection closed by foreign host.
However, if I now try to access the SMTP daemon on host vml000110 in zone idmz from a host in zone edmz (192.168.0.15 2002:a:b:c0:e9a6:bb03), I see the following:
django@nitropad:~$ telnet 192.168.0.210 25 Trying 192.168.0.210... Connected to 192.168.0.210. Escape character is '^]'. 220 vml000110.localdomain ESMTP Postfix quit 221 2.0.0 Bye Connection closed by foreign host.
Yeahh, I think it works! \o/
BUT: django@nitropad:~$ telnet 2003:a:b:c1:10::110 25 Trying 2003:a:b:c1:10::110... telnet: Unable to connect to remote host: Permission denied
;( It's milking the mice, I don't get it! Where is my (thinking) mistake?
O.K. Eric, now it's your turn! I hope you can now do a bit more with my information and tell me where the problem lies. Yes, PEBCAK is already clear, but where exactly?
I'm not sure. You can enable denied logging for clues.
firewall-cmd --set-log-denied
Then check "dmesg" output for drop reports.
... and BTW since my policy-rule doesn't work with SMTP port 25, I didn't need to define the other SMTP ports or the path to the POP3/IMAP server.
Best regards Django -- _______________________________________________ firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/firewalld-users@lists.fedorahos... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue