HI!
My environment:
### Internet ### | | V +-----------+ | | | FWA | | | +-----------+ | --EDMZ--+------------------ [laptop] | 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 ###
Outgoing traffic from intranet, IDMZ, web or mail to internet, works fine either with IPv4 or IPv6 addresses.
With the help of firewalld rules, I can reach the SSH daemon on the host FWB.
ON my host "FWB" I put those two rich-rules: # firewall-cmd --zone=edmz --list-all | grep 41022
rule family="ipv4" forward-port port="41022" protocol="tcp" to-port="22" to-addr="192.168.0.210" rule family="ipv6" forward-port port="41022" protocol="tcp" to-port="22" to-addr="fd00::192:168:0:210"
I can reach the host FWB from the Internet without any problems with the help of:
# ssh -p 41022 2003:a:b:c0:1920:168:0:210
If I now define the following rich rule on my host FWB, I can also reach the host FWC. # firewall-cmd --zone=edmz --list-all | grep 41122
rule family="ipv4" forward-port port="41122" protocol="tcp" to-port="22" to-addr="10.0.0.110" rule family="ipv6" forward-port port="41122" protocol="tcp" to-port="22" to-addr="2003:a:b:c1:10::110"
I can reach SSH daemon on FWC from the internet with: # ssh -p 41122 2003:a:b:c0:1920:168:0:210
For testing purposes, I then installed FWC postfix on the host, which responds to both IPv4 and IPv6 on port 25. I can therefore reach the SMTP daemon listening on port 25 on the host from the host FWB.
root@vml000210:~# telnet 10.0.0.110 25 root@vml000210:~# telnet 2003:a:b:c1:10::110 25
So far so good.
On my host FWB I put these two "forward-ports" rules: # firewall-cmd --zone=edmz --list-all | grep port=25 port=25:proto=tcp:toport=:toaddr=10.0.0.110 port=25:proto=tcp:toport=:toaddr=2003:a:b:c1:10::110
From the Internet, I can now access port 25 at address 2003:a:b:c0:1920:168:0:210 and, thanks to the port-forward rule, end up at the SMTP daemon on the host FWC.
Basically, I'm fine with firewalld and its command syntax, and the routing for IPv4 and IPv6 on the two hosts FWB and FWC should work so far, in my opinion.
But what I actually have in mind is the following scenario:
Traffic from the Internet on port 22, i.e. the SSH daemon, is only permitted on the host FWB (2003:a:b:c0:1920:168:0:210) with the address. The SSH daemon on the host FWC (2003:a:b:c1:10::110) is not directly accessible from the Internet.
Both tasks have now been solved satisfactorily.
!!!***BUT***!!!:
Traffic from the Internet (::/64) may directly reach the SMTP daemon on the host FWC (2003:a:b:c1:10::110), but ONLY if the destination port is 25. To do this, the traffic must of course be allowed through on the host FWB (2003:a:b:c0:1920:168:0:210), but only if the destination port is 25 and the destination address is 2003:a:b:c1:10::110! Other traffic from the Internet which has 2003:a:b:c1:10::110 as the destination address - regardless of which destination port is selected - must be blocked by the firewalld on the host FWB (2003:a:b:c0:1920:168:0:210)!
So I need a firewall rule on the host FWB according to the following scheme:
On FBW (2003:a:b:c0:1920:168:0:210) accept SMTP traffic on port 25 from all senders on the Internet, but only for the destination address 2003:a:b:c1:10::110 and route this traffic on to the host FWC which holds the address 2003:a:b:c1:10::110.
Something like that: # firewall-cmd --zone=edmz \ --add-rich-rule='rule family="ipv6" \ source address="::/0" \ destination address="2003:a:b:c1:10::110" \ service name="smtp" accept'
Well, unfortunately it doesn't work like that or something is still missing or I've taken a completely wrong turn, who knows? :/
Actually, it shouldn't be accept but forward in my naive attempt, but that immediately blows up in my face with the following error message: # firewall-cmd --zone=edmz \ --add-rich-rule='rule family="ipv6" \ source address="::/0" \ destination address="2003:a:b:c1:10::110" \ service name="smtp" forward'
Error: INVALID_RULE: unknown element forward
I currently have absolutely no idea what else I could try to solve my problem!
Maybe someone has enough expertise and patience to explain and show me ;) I am grateful for any advice and would like to take this opportunity to say thank you very much!
Best regards Django
On 18.01.2024 20:14, Django [Bastard Operator from Hell] wrote:
HI!
My environment:
### Internet ### | | V +-----------+ | | | FWA | | | +-----------+ | --EDMZ--+------------------ [laptop] | 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 ###
Outgoing traffic from intranet, IDMZ, web or mail to internet, works fine either with IPv4 or IPv6 addresses.
With the help of firewalld rules, I can reach the SSH daemon on the host FWB.
ON my host "FWB" I put those two rich-rules: # firewall-cmd --zone=edmz --list-all | grep 41022
rule family="ipv4" forward-port port="41022" protocol="tcp" to-port="22" to-addr="192.168.0.210" rule family="ipv6" forward-port port="41022" protocol="tcp" to-port="22" to-addr="fd00::192:168:0:210"
I can reach the host FWB from the Internet without any problems with the help of:
# ssh -p 41022 2003:a:b:c0:1920:168:0:210
If I now define the following rich rule on my host FWB, I can also reach the host FWC. # firewall-cmd --zone=edmz --list-all | grep 41122
rule family="ipv4" forward-port port="41122" protocol="tcp" to-port="22" to-addr="10.0.0.110" rule family="ipv6" forward-port port="41122" protocol="tcp" to-port="22" to-addr="2003:a:b:c1:10::110"
I can reach SSH daemon on FWC from the internet with: # ssh -p 41122 2003:a:b:c0:1920:168:0:210
For testing purposes, I then installed FWC postfix on the host, which responds to both IPv4 and IPv6 on port 25. I can therefore reach the SMTP daemon listening on port 25 on the host from the host FWB.
root@vml000210:~# telnet 10.0.0.110 25 root@vml000210:~# telnet 2003:a:b:c1:10::110 25
So far so good.
On my host FWB I put these two "forward-ports" rules: # firewall-cmd --zone=edmz --list-all | grep port=25 port=25:proto=tcp:toport=:toaddr=10.0.0.110 port=25:proto=tcp:toport=:toaddr=2003:a:b:c1:10::110
From the Internet, I can now access port 25 at address 2003:a:b:c0:1920:168:0:210 and, thanks to the port-forward rule, end up at the SMTP daemon on the host FWC.
Basically, I'm fine with firewalld and its command syntax, and the routing for IPv4 and IPv6 on the two hosts FWB and FWC should work so far, in my opinion.
But what I actually have in mind is the following scenario:
Traffic from the Internet on port 22, i.e. the SSH daemon, is only permitted on the host FWB (2003:a:b:c0:1920:168:0:210) with the address. The SSH daemon on the host FWC (2003:a:b:c1:10::110) is not directly accessible from the Internet.
Both tasks have now been solved satisfactorily.
!!!***BUT***!!!:
Traffic from the Internet (::/64) may directly reach the SMTP daemon on the host FWC (2003:a:b:c1:10::110), but ONLY if the destination port is 25. To do this, the traffic must of course be allowed through on the host FWB (2003:a:b:c0:1920:168:0:210), but only if the destination port is 25 and the destination address is 2003:a:b:c1:10::110! Other traffic from the Internet which has 2003:a:b:c1:10::110 as the destination address - regardless of which destination port is selected - must be blocked by the firewalld on the host FWB (2003:a:b:c0:1920:168:0:210)!
So I need a firewall rule on the host FWB according to the following scheme:
On FBW (2003:a:b:c0:1920:168:0:210) accept SMTP traffic on port 25 from all senders on the Internet, but only for the destination address 2003:a:b:c1:10::110 and route this traffic on to the host FWC which holds the address 2003:a:b:c1:10::110.
Something like that: # firewall-cmd --zone=edmz \ --add-rich-rule='rule family="ipv6" \ source address="::/0" \ destination address="2003:a:b:c1:10::110" \ service name="smtp" accept'
Well, unfortunately it doesn't work like that or something is still missing or I've taken a completely wrong turn, who knows? :/
Zones are by definition for local (destination is local host, INPUT chain) packets. You need to define policy between two zones, ingress zone edmz and egress zone whatever is assigned to the interface connected to FWC and use your rule there. Policies are for forwarded packets.
Actually, it shouldn't be accept but forward in my naive attempt, but that immediately blows up in my face with the following error message: # firewall-cmd --zone=edmz \ --add-rich-rule='rule family="ipv6" \ source address="::/0" \ destination address="2003:a:b:c1:10::110" \ service name="smtp" forward'
Error: INVALID_RULE: unknown element forward
I currently have absolutely no idea what else I could try to solve my problem!
Maybe someone has enough expertise and patience to explain and show me ;) I am grateful for any advice and would like to take this opportunity to say thank you very much!
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
Hello Andrej,
On 18.01.24 um 18:31 Andrei Borzenkov wrote:
Zones are by definition for local (destination is local host, INPUT chain) packets. You need to define policy between two zones, ingress zone edmz and egress zone whatever is assigned to the interface connected to FWC and use your rule there. Policies are for forwarded packets.
OK, if I have understood the concept of policies correctly, then I will summarize it:
I've already one policy called NAT_idmz_to_edmz:
root@vml000210:~# cat /etc/firewalld/policies/NAT_idmz_to_edmz.xml <?xml version="1.0" encoding="utf-8"?> <policy target="ACCEPT"> <ingress-zone name="idmz"/> <egress-zone name="edmz"/> </policy>
This now means the following: Input-channel is the ingress-zone with name idmz. Output-channel is egress-zone with name edmz. Policy-target means, that all traffic is allow from zone idmz to zone edmz.
Have I understood that correctly, or am I completely wrong?
If I have understood this correctly, it should work now, right? 1) I create a new zone with the name smtp-access 2) In the zone, I allow for IPv6 from everywhere → source address="::/0" to the destination address 2003:a:b:c1:10::110 traffic for the SMTP service
root@vml000210:~# cat /etc/firewalld/zones/smtp-access.xml <?xml version="1.0" encoding="utf-8"?> <zone> <rule family="ipv6"> <source address="::/0"/> <destination address="2003:a:b:c1:10::110"/> <service name="smtp"/> <accept/> </rule> </zone>
I then define a new policy with the name SMTPT_edmz_to_idmz and define smtp-access as the inbound zone and idmz as the outbound zone:
root@vml000210:~# cat /etc/firewalld/policies/SMTPT_edmz_to_idmz.xml <?xml version="1.0" encoding="utf-8"?> <policy target="CONTINUE"> <ingress-zone name="smtp-access"/> <egress-zone name="idmz"/> </policy>
Is that really the case? So I think something is still wrong! Why I mean that, now after a reload of the firewalld on the host FWB (vml000210) ...
root@vml000210:~# firewall-cmd --reload
success
... nothing happens! :(
It is still not possible to access port 25 of host FWC (vml000110) from outside via host FWB (vml000210).
So either I'm stupid or old or a combination of both, so hard to understand ...
Or how the hell do I define a policy between the zone smtp-in as input and the destination zone idmz, where only traffic from the source ::/0 to the destination 2003:a:b:c1:10::110 on port 25 is allowed.
ttyl Django
On Thu, Jan 18, 2024 at 09:33:30PM +0100, Django [Bastard Operator from Hell] wrote:
Hello Andrej,
On 18.01.24 um 18:31 Andrei Borzenkov wrote:
Zones are by definition for local (destination is local host, INPUT chain) packets. You need to define policy between two zones, ingress zone edmz and egress zone whatever is assigned to the interface connected to FWC and use your rule there. Policies are for forwarded packets.
OK, if I have understood the concept of policies correctly, then I will summarize it:
I've already one policy called NAT_idmz_to_edmz:
root@vml000210:~# cat /etc/firewalld/policies/NAT_idmz_to_edmz.xml
<?xml version="1.0" encoding="utf-8"?>
<policy target="ACCEPT"> <ingress-zone name="idmz"/> <egress-zone name="edmz"/> </policy>
This now means the following: Input-channel is the ingress-zone with name idmz. Output-channel is egress-zone with name edmz. Policy-target means, that all traffic is allow from zone idmz to zone edmz.
Have I understood that correctly, or am I completely wrong?
That's correct.
If I have understood this correctly, it should work now, right?
- I create a new zone with the name smtp-access
- In the zone, I allow for IPv6 from everywhere → source address="::/0" to
the destination address 2003:a:b:c1:10::110 traffic for the SMTP service
root@vml000210:~# cat /etc/firewalld/zones/smtp-access.xml
<?xml version="1.0" encoding="utf-8"?>
<zone> <rule family="ipv6"> <source address="::/0"/>
This rich rule further filters traffic assigned to the zone. So saying "all IPv6" here doesn't make sense as right now you have no interface/source. The zone doesn't get any traffic assigned to it!
A "source" inside a rich rule refers to a source address match, e.g. you want to enable something for a single IP address.
A "source" in a zone means assign traffic with that source address/CIDR to the zone, e.g. a subnet (10.10.10.0/24).
<destination address="2003:a:b:c1:10::110"/> <service name="smtp"/> <accept/></rule> </zone>
This zone does not have an interface or source binding [*]. Meaning no traffic will be assigned to it. You need to do --zone smtp-access --add-interface or --zone smtp-access --add-source.
[*]: That is, unless you're using NetworkManager and did the assignment there.
I then define a new policy with the name SMTPT_edmz_to_idmz and define smtp-access as the inbound zone and idmz as the outbound zone:
root@vml000210:~# cat /etc/firewalld/policies/SMTPT_edmz_to_idmz.xml
<?xml version="1.0" encoding="utf-8"?>
<policy target="CONTINUE"> <ingress-zone name="smtp-access"/> <egress-zone name="idmz"/> </policy>
Is that really the case? So I think something is still wrong! Why I mean that, now after a reload of the firewalld on the host FWB (vml000210) ...
root@vml000210:~# firewall-cmd --reload
success
... nothing happens! :(
It is still not possible to access port 25 of host FWC (vml000110) from outside via host FWB (vml000210).
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.
Please include interfaces and subnet addressing in your description. You can obfuscate them.
...
Or how the hell do I define a policy between the zone smtp-in as input and the destination zone idmz, where only traffic from the source ::/0 to the destination 2003:a:b:c1:10::110 on port 25 is allowed.
Your policy is correct. I think where it's failing is that these zones and policies are not active because you haven't done --add-interface or --add-source.
I also think you missed a key point about zones. Traffic ingresses one and only one zone. Traffic egresses one and only one zone.
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:
1) 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.
2) 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 # 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
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.
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
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
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 # 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.
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.
# 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" \ 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?
... 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
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
HI Eric,
Thanx a lot for your help!
Now, I think it works as designed!
O.K., what have I done?
1) activate logging: # firewall-cmd --set-log-denied=all
2) monitor syslog: (Best in a second terminator section or shell window) # journalctl -f
3) create firewall zones: # firewall-cmd --permanent --new-zone=edmz # firewall-cmd --permanent --new-zone=idmz # firewall-cmd --reload
4) assign network interfaces to the zones: # firewall-cmd --permanent --zone=edmz --add-interface=eth0 # firewall-cmd --permanent --zone=idmz --add-interface=eth1 # firewall-cmd --reload
5) activate masquerading for zone edmz: # firewall-cmd --permanent --zone=edmz --add-masquerade # firewall-cmd --reload
6) additionally set up NAT for the traffic IDMZ → EDMZ: # firewall-cmd --permanent --new-policy idmz-2-edmz # firewall-cmd --permanent --policy idmz-2-edmz \ --add-ingress-zone idmz # firewall-cmd --permanent --policy idmz-2-edmz \ --add-egress-zone edmz # firewall-cmd --permanent --policy idmz-2-edmz \ --set-target ACCEPT # firewall-cmd --reload
7) activate SSH for the zone idmz: # firewall-cmd --permanent --zone=idmz --add-service=ssh # firewall-cmd --reload
8) activate SSH for the edmz zone for access from the EDMZ (192.168.0.0/24 and 2003:a:b:c0::/64) itself: # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv4" source address="192.168.0.0/24" \ service name="ssh" accept' # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv6" source address="2003:a:b:c0::/64" \ service name="ssh" accept' # firewall-cmd --reload
9) allow SSH from the Internet only via port 41022: # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv4" forward-port port=41022 to-port=22 \ protocol=tcp' # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv6" forward-port port=41022 to-port=22 \ protocol=tcp' # firewall-cmd --reload
10) forward port 25 of the firewall host to a host in the IDMZ. # firewall-cmd --permanent --zone=edmz \ --add-forward-port=port=25:proto=tcp:toaddr=10.0.0.110 # firewall-cmd --permanent --zone=edmz \ --add-forward-port=25:proto=tcp:toaddr=2003:a:b:c1:10::110 # firewall-cmd --reload
11) forward MX ports 25, 465 and 587 to target_MX host: # firewall-cmd --permanent --new-policy edmz-2-idmz # firewall-cmd --permanent --policy edmz-2-idmz \ --add-ingress-zone edmz # firewall-cmd --permanent --policy edmz-2-idmz \ --add-egress-zone idmz # firewall-cmd --permanent --policy edmz-2-idmz \ --set-target REJECT # firewall-cmd --permanent --policy edmz-2-idmz \ --add-rich-rule='rule family="ipv6" \ destination address="2003:a:b:c1:10::110" \ service name="smtp" accept' # firewall-cmd --permanent --policy edmz-2-idmz \ --add-rich-rule='rule family="ipv6" \ destination address="2003:a:b:c1:10::110" \ port port=465 protocol=tcp accept' # firewall-cmd --permanent --policy edmz-2-idmz \ --add-rich-rule='rule family="ipv6" \ destination address="2003:a:b:c1:10::110" \ port port=587 protocol=tcp accept' # firewall-cmd --reload Proceed accordingly for other services and service hosts ...
Do you still see a need for optimization? Or do you have any suggestions for improvement? If so, let us know! I always want to learn more! :)
cul8r, Django
On Sat, Jan 20, 2024 at 05:55:44PM +0100, Django [Bastard Operator from Hell] wrote:
HI Eric,
Thanx a lot for your help!
Now, I think it works as designed!
O.K., what have I done?
- activate logging:
# firewall-cmd --set-log-denied=all
monitor syslog: (Best in a second terminator section or shell window) # journalctl -f
create firewall zones: # firewall-cmd --permanent --new-zone=edmz # firewall-cmd --permanent --new-zone=idmz # firewall-cmd --reload
assign network interfaces to the zones: # firewall-cmd --permanent --zone=edmz --add-interface=eth0 # firewall-cmd --permanent --zone=idmz --add-interface=eth1 # firewall-cmd --reload
activate masquerading for zone edmz: # firewall-cmd --permanent --zone=edmz --add-masquerade # firewall-cmd --reload
additionally set up NAT for the traffic IDMZ → EDMZ: # firewall-cmd --permanent --new-policy idmz-2-edmz # firewall-cmd --permanent --policy idmz-2-edmz \ --add-ingress-zone idmz # firewall-cmd --permanent --policy idmz-2-edmz \ --add-egress-zone edmz # firewall-cmd --permanent --policy idmz-2-edmz \ --set-target ACCEPT # firewall-cmd --reload
You could move the masquerade from above edmz zone to this policy. IMO, it's more correct. Adding it to the zone means it will masquerade all traffic egressing zone edmz regardless of where it originates, e.g. idmz, public, internal, etc. Using this policy means only traffic from idmz will be masqueraded.
activate SSH for the zone idmz: # firewall-cmd --permanent --zone=idmz --add-service=ssh # firewall-cmd --reload
activate SSH for the edmz zone for access from the EDMZ (192.168.0.0/24 and 2003:a:b:c0::/64) itself: # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv4" source address="192.168.0.0/24" \ service name="ssh" accept' # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv6" source address="2003:a:b:c0::/64" \ service name="ssh" accept' # firewall-cmd --reload
allow SSH from the Internet only via port 41022: # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv4" forward-port port=41022 to-port=22 \ protocol=tcp' # firewall-cmd --permanent --zone=edmz --add-rich-rule='rule \ family="ipv6" forward-port port=41022 to-port=22 \ protocol=tcp' # firewall-cmd --reload
forward port 25 of the firewall host to a host in the IDMZ. # firewall-cmd --permanent --zone=edmz \ --add-forward-port=port=25:proto=tcp:toaddr=10.0.0.110 # firewall-cmd --permanent --zone=edmz \ --add-forward-port=25:proto=tcp:toaddr=2003:a:b:c1:10::110 # firewall-cmd --reload
forward MX ports 25, 465 and 587 to target_MX host: # firewall-cmd --permanent --new-policy edmz-2-idmz # firewall-cmd --permanent --policy edmz-2-idmz \ --add-ingress-zone edmz # firewall-cmd --permanent --policy edmz-2-idmz \ --add-egress-zone idmz # firewall-cmd --permanent --policy edmz-2-idmz \ --set-target REJECT # firewall-cmd --permanent --policy edmz-2-idmz \ --add-rich-rule='rule family="ipv6" \ destination address="2003:a:b:c1:10::110" \ service name="smtp" accept' # firewall-cmd --permanent --policy edmz-2-idmz \ --add-rich-rule='rule family="ipv6" \ destination address="2003:a:b:c1:10::110" \ port port=465 protocol=tcp accept' # firewall-cmd --permanent --policy edmz-2-idmz \ --add-rich-rule='rule family="ipv6" \ destination address="2003:a:b:c1:10::110" \ port port=587 protocol=tcp accept' # firewall-cmd --reload Proceed accordingly for other services and service hosts ...
Do you still see a need for optimization? Or do you have any suggestions for improvement? If so, let us know! I always want to learn more! :)
This looks good to me based on how I understand your topology. That being said, every network is a snowflake. :)
I'm glad you got it sorted out.
Eric.
HI Eric!
Am 22.01.24 um 20:51 schrieb Eric Garver:
You could move the masquerade from above edmz zone to this policy. IMO, it's more correct. Adding it to the zone means it will masquerade all traffic egressing zone edmz regardless of where it originates, e.g. idmz, public, internal, etc. Using this policy means only traffic from idmz will be masqueraded.
Yes, I'm afraid I have to agree with you, it's probably better to move the masquerading instruction to the policy idmz-2-edmz.
This looks good to me based on how I understand your topology. That being said, every network is a snowflake. :)
I'm glad you got it sorted out.
I managed it, but without your valuable tips it would have taken me a long time!
Best regards Django
On Thu, Jan 18, 2024 at 06:14:05PM +0100, Django [Bastard Operator from Hell] wrote:
HI!
My environment:
### Internet ### | | V +-----------+ | | | FWA | | | +-----------+ | --EDMZ--+------------------ [laptop] | 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 ###
Outgoing traffic from intranet, IDMZ, web or mail to internet, works fine either with IPv4 or IPv6 addresses.
With the help of firewalld rules, I can reach the SSH daemon on the host FWB.
ON my host "FWB" I put those two rich-rules: # firewall-cmd --zone=edmz --list-all | grep 41022
rule family="ipv4" forward-port port="41022" protocol="tcp" to-port="22" to-addr="192.168.0.210" rule family="ipv6" forward-port port="41022" protocol="tcp" to-port="22" to-addr="fd00::192:168:0:210"
I can reach the host FWB from the Internet without any problems with the help of:
# ssh -p 41022 2003:a:b:c0:1920:168:0:210
If I now define the following rich rule on my host FWB, I can also reach the host FWC. # firewall-cmd --zone=edmz --list-all | grep 41122
rule family="ipv4" forward-port port="41122" protocol="tcp" to-port="22" to-addr="10.0.0.110" rule family="ipv6" forward-port port="41122" protocol="tcp" to-port="22" to-addr="2003:a:b:c1:10::110"
I can reach SSH daemon on FWC from the internet with: # ssh -p 41122 2003:a:b:c0:1920:168:0:210
For testing purposes, I then installed FWC postfix on the host, which responds to both IPv4 and IPv6 on port 25. I can therefore reach the SMTP daemon listening on port 25 on the host from the host FWB.
root@vml000210:~# telnet 10.0.0.110 25 root@vml000210:~# telnet 2003:a:b:c1:10::110 25
So far so good.
On my host FWB I put these two "forward-ports" rules: # firewall-cmd --zone=edmz --list-all | grep port=25 port=25:proto=tcp:toport=:toaddr=10.0.0.110 port=25:proto=tcp:toport=:toaddr=2003:a:b:c1:10::110
From the Internet, I can now access port 25 at address 2003:a:b:c0:1920:168:0:210 and, thanks to the port-forward rule, end up at the SMTP daemon on the host FWC.
Basically, I'm fine with firewalld and its command syntax, and the routing for IPv4 and IPv6 on the two hosts FWB and FWC should work so far, in my opinion.
But what I actually have in mind is the following scenario:
Traffic from the Internet on port 22, i.e. the SSH daemon, is only permitted on the host FWB (2003:a:b:c0:1920:168:0:210) with the address. The SSH daemon on the host FWC (2003:a:b:c1:10::110) is not directly accessible from the Internet.
Both tasks have now been solved satisfactorily.
!!!***BUT***!!!:
Traffic from the Internet (::/64) may directly reach the SMTP daemon on the host FWC (2003:a:b:c1:10::110), but ONLY if the destination port is 25. To do this, the traffic must of course be allowed through on the host FWB (2003:a:b:c0:1920:168:0:210), but only if the destination port is 25 and the destination address is 2003:a:b:c1:10::110! Other traffic from the Internet which has 2003:a:b:c1:10::110 as the destination address - regardless of which destination port is selected - must be blocked by the firewalld on the host FWB (2003:a:b:c0:1920:168:0:210)!
So I need a firewall rule on the host FWB according to the following scheme:
On FBW (2003:a:b:c0:1920:168:0:210) accept SMTP traffic on port 25 from all senders on the Internet, but only for the destination address 2003:a:b:c1:10::110 and route this traffic on to the host FWC which holds the address 2003:a:b:c1:10::110.
Something like that: # firewall-cmd --zone=edmz \ --add-rich-rule='rule family="ipv6" \ source address="::/0" \ destination address="2003:a:b:c1:10::110" \ service name="smtp" accept'
Well, unfortunately it doesn't work like that or something is still missing or I've taken a completely wrong turn, who knows? :/
Actually, it shouldn't be accept but forward in my naive attempt, but that immediately blows up in my face with the following error message: # firewall-cmd --zone=edmz \ --add-rich-rule='rule family="ipv6" \ source address="::/0" \ destination address="2003:a:b:c1:10::110" \ service name="smtp" forward'
Error: INVALID_RULE: unknown element forward
I currently have absolutely no idea what else I could try to solve my problem!
Maybe someone has enough expertise and patience to explain and show me ;) I am grateful for any advice and would like to take this opportunity to say thank you very much!
As was said by someone else, you need to use a policy to manipulate forwarded traffic. Please read the concepts page here:
HI Eric,
On 18th January 2024 on 19:18 wrote Eric Garver:
As was said by someone else, you need to use a policy to manipulate forwarded traffic. Please read the concepts page here:
O.K. Thanks first of all for the valuable tip and link. I will have another look at it and try to solve my problem. If there are any more questions, I will certainly get in touch again, see you then ...
ttyl Django
firewalld-users@lists.fedorahosted.org
-
Andrei Borzenkov -
Bastard Operator from Hell -
Django [Bastard Operator from Hell]
-
Eric Garver