11:14 a.m.
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
11:31 a.m.
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(a)lists.fedorahosted.org
To unsubscribe send an email to firewalld-users-leave(a)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.fedora...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2:33 p.m.
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
3:29 p.m.
New subject: firewalld and forwarding incoming external traffic to an
internal host
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?
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"/>
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.
8 a.m.
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
12:41 p.m.
New subject: firewalld and forwarding incoming external traffic to an
internal host
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:
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
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(a)lists.fedorahosted.org
To unsubscribe send an email to firewalld-users-leave(a)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.fedora...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
10:55 a.m.
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
1:51 p.m.
New subject: firewalld and forwarding incoming external traffic to an
internal host
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?
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
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.
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! :)
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.
9:41 a.m.
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
12:18 p.m.
New subject: firewalld and forwarding incoming external traffic to an
internal host
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:
https://firewalld.org/documentation/concepts.html
12:31 p.m.
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:
https://firewalld.org/documentation/concepts.html
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
104
days inactive
111
days old
firewalld-users@lists.fedorahosted.org
10 comments
4 participants
participants (4)
-
Andrei Borzenkov -
Bastard Operator from Hell -
Django [Bastard Operator from Hell]
-
Eric Garver