Dear All,
I have a 9 stream with 2 nic, one connecting to lan, and other one connecting to wan, i did the following setup, but after the 9 stream itself can not access internet as well as the rest of computer, any help would be appreicated
# nmcli c mod ens192 connection.zone internal
# nmcli c mod ens224 connection.zone external
[root@CentOSHome ~]# firewall-cmd --get-active-zones
external
interfaces: ens224
internal
interfaces: ens192
# firewall-cmd --zone=external --add-masquerade --permanent
# firewall-cmd --zone=internal --add-masquerade --permanent
# firewall-cmd --reload
# firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 0 -o ens224 -j MASQUERADE
# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i ens192 -o ens224 -j ACCEPT
# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i ens224 -o ens192 -m state --state RELATED,ESTABLISHED -j ACCEPT
# firewall-cmd --reload
keith
9-Stream with 2 NIC act as NAT can not access internet
Re: 9-Stream with 2 NIC act as NAT can not access internet
First of all, there is no point to sNAT to both directions.
Let say that LAN member X sends packet to forums.centos.org.
The X has private IP address that cannot be shown on internet and it has to first forward the packet to router that is connected other subnet(s).
The router (CentOSHome) receives packet and masquerades it with router's public IP address.
forums.centos.org receives packet from CentOSHome and sends reply to CentOSHome.
So far all is well.
Now you want to masquerade this traffic, like it would come from LAN address of CentOSHome.
The X did send a packet to forums.centos.org but does not receive replies. Although, the CentOSHome does send unexpected packets ...
Not only did you add more than enough masquerade-rules to zones, you do add one more as direct rule. That is plenty of masquerade.
Furthermore, did you even check whether the external zone might enable masquerade by default? IIRC, it does.
There is more fun: no more iptables. The kernel in both RHEL 8 and RHEL 9 (and hence Stream 9) has nftables. Firewalld in RHEL 9 does not even bother to imitate iptables builtin chains any more. If you want to see the current ruleset, then you run:
And then some: the direct rules was a workaround as firewalld did lack support for many things.
One of those things was rules for forwarding traffic between zones.
The current version should support "policy objects". There might even be something by default, when you have internal and external zones.
If not, then read the part of firewall-cmd documentation that does describe the policy objects. (I haven't, opted to use lean and mean config with nftables.service instead.)
All that said at most all the masquerade, and not really even that, could explain why the machine cannot reach anything.
I would reset firewall to defaults. (The user-made customizations are under /etc/firewalld/*/)
See what the ruleset has with default internal and external zones.
Let say that LAN member X sends packet to forums.centos.org.
The X has private IP address that cannot be shown on internet and it has to first forward the packet to router that is connected other subnet(s).
The router (CentOSHome) receives packet and masquerades it with router's public IP address.
forums.centos.org receives packet from CentOSHome and sends reply to CentOSHome.
So far all is well.
Now you want to masquerade this traffic, like it would come from LAN address of CentOSHome.
The X did send a packet to forums.centos.org but does not receive replies. Although, the CentOSHome does send unexpected packets ...
Not only did you add more than enough masquerade-rules to zones, you do add one more as direct rule. That is plenty of masquerade.
Furthermore, did you even check whether the external zone might enable masquerade by default? IIRC, it does.
There is more fun: no more iptables. The kernel in both RHEL 8 and RHEL 9 (and hence Stream 9) has nftables. Firewalld in RHEL 9 does not even bother to imitate iptables builtin chains any more. If you want to see the current ruleset, then you run:
Code: Select all
nft list ruleset
One of those things was rules for forwarding traffic between zones.
The current version should support "policy objects". There might even be something by default, when you have internal and external zones.
If not, then read the part of firewall-cmd documentation that does describe the policy objects. (I haven't, opted to use lean and mean config with nftables.service instead.)
All that said at most all the masquerade, and not really even that, could explain why the machine cannot reach anything.
I would reset firewall to defaults. (The user-made customizations are under /etc/firewalld/*/)
See what the ruleset has with default internal and external zones.
Re: 9-Stream with 2 NIC act as NAT can not access internet
so which mean below rule is not needed since it is sNAT, and i found one issue, if i dont spilt the zone for the 2 nic for external and internal, the internet work for client computer in the lan, and the masquerade has enabled by default in external zone, may i know what is the workaround ?
firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i ens192 -o ens224 -j ACCEPT
keith
firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i ens192 -o ens224 -j ACCEPT
keith
Re: 9-Stream with 2 NIC act as NAT can not access internet
I did test, starting from firewalld defaults. The only thing that I did change was:
According to nft list ruleset a rule was added by the latter command:
In other words, the external zone does NAT by default. Naturally, firewall-cmd would have told that:
Note also forward: yes. The default kernel setting is to not forward anything. This zone enables routing too.
Traffic is routed through the machine and outgoing traffic to external does get the sNAT treatment.
What else do we need? Filter rules. What do we have? Again, from nft list ruleset:
Do note the first rule (handle 158): ct state { established, related } accept
That is the nftables way to say: -m state --state RELATED,ESTABLISHED -j ACCEPT
Therefore, replies are allowed to all directions.
The only thing missing is a policy that ingress from internal zone, egress to external zone is allowed. The (-i in -o out -j ACCEPT).
See man firewalld.policies, man firewall-cmd and https://access.redhat.com/documentation ... -firewalld
Following those instructions I did:
They did add (among other things):
If we ignore all the fancy chains, the rule is iifname { "ens1" } oifname { "ens2" } accept just as one could expect.
This was the "FirewallD Way" to set up "NAT router" (tested on AlmaLinux 9).
As said, none of this should affect how this host accesses anyone.
Code: Select all
# nmcli c mod ens1 connection.zone internal
# nmcli c mod ens2 connection.zone external
Code: Select all
chain nat_POST_external_allow {
meta nfproto ipv4 oifname != "lo" masquerade
}
Code: Select all
# firewall-cmd --info-zone external
external (active)
target: default
icmp-block-inversion: no
interfaces: ens2
sources:
services: ssh
ports:
protocols:
forward: yes
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Traffic is routed through the machine and outgoing traffic to external does get the sNAT treatment.
What else do we need? Filter rules. What do we have? Again, from nft list ruleset:
Code: Select all
chain filter_FORWARD { # handle 144
type filter hook forward priority filter + 10; policy accept;
ct state { established, related } accept # handle 158
ct status dnat accept # handle 159
iifname "lo" accept # handle 160
ip6 daddr { ::/96, ::ffff:0.0.0.0/96, 2002::/24, 2002:a00::/24, 2002:7f00::/24, 2002:a9fe::/32, 2002:ac10::/28, 2002:c0a8::/32, 2002:e000::/19 } reject with icmpv6 type addr-unreachable # handle 181
jump filter_FORWARD_ZONES # handle 163
ct state { invalid } drop # handle 166
reject with icmpx type admin-prohibited # handle 167
}
That is the nftables way to say: -m state --state RELATED,ESTABLISHED -j ACCEPT
Therefore, replies are allowed to all directions.
The only thing missing is a policy that ingress from internal zone, egress to external zone is allowed. The (-i in -o out -j ACCEPT).
See man firewalld.policies, man firewall-cmd and https://access.redhat.com/documentation ... -firewalld
Following those instructions I did:
Code: Select all
# firewall-cmd --permanent --new-policy myOutputPolicy
# firewall-cmd --permanent --policy myOutputPolicy --set-target ACCEPT
# firewall-cmd --permanent --policy myOutputPolicy --add-egress-zone external
# firewall-cmd --permanent --policy myOutputPolicy --add-ingress-zone internal
# firewall-cmd --reload
Code: Select all
chain filter_FORWARD_POLICIES_pre {
iifname { "ens1" } oifname { "ens2" } jump filter_FWD_policy_myOutputPolicy
}
chain filter_FWD_policy_myOutputPolicy {
jump filter_FWD_policy_myOutputPolicy_pre
jump filter_FWD_policy_myOutputPolicy_log
jump filter_FWD_policy_myOutputPolicy_deny
jump filter_FWD_policy_myOutputPolicy_allow
jump filter_FWD_policy_myOutputPolicy_post
accept
}
This was the "FirewallD Way" to set up "NAT router" (tested on AlmaLinux 9).
As said, none of this should affect how this host accesses anyone.
Re: 9-Stream with 2 NIC act as NAT can not access internet
its work perfectly after i ran below command, thanks for your great help
# firewall-cmd --permanent --new-policy myOutputPolicy
# firewall-cmd --permanent --policy myOutputPolicy --set-target ACCEPT
# firewall-cmd --permanent --policy myOutputPolicy --add-egress-zone external
# firewall-cmd --permanent --policy myOutputPolicy --add-ingress-zone internal
# firewall-cmd --reload
keith
# firewall-cmd --permanent --new-policy myOutputPolicy
# firewall-cmd --permanent --policy myOutputPolicy --set-target ACCEPT
# firewall-cmd --permanent --policy myOutputPolicy --add-egress-zone external
# firewall-cmd --permanent --policy myOutputPolicy --add-ingress-zone internal
# firewall-cmd --reload
keith