How to set up NAT?

[Mark Sobell]

Using iptables I set up NAT as follows.
How would I do the same under firewalld?
Thanks!

Mark

# iptables -A FORWARD -i eth0 -o eth1 -m state --state
ESTABLISHED,RELATED -j ACCEPT
# iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
# iptables -A FORWARD -j LOG
# iptables -t NAT -A POSTROUTING -o eth0 -j MASQUERADE

[Thomas Woerner]

On 06/20/2013 05:08 AM, Mark Sobell wrote:
> Using iptables I set up NAT as follows.
> How would I do the same under firewalld?
> Thanks!
>          Mark

firewalld is using a zone model. With the model you can define different 
sets of firewall rules, which you can be bound to interfaces or 
connections using ifcfg files or the NetworkManager configuration.

For interfaces that are not handled by NetworkManager, you can set the 
zone either within an ifcfg file with ZONE=<zone name> or you can use 
the firewall command line tool firewall-cmd [--permanent] --zone=<zone 
name> --add-interface=<interface>. Without the permanent option this 
change is valid only until the machine is restarted or the firewalld 
service is reloaded or restarted.

You can also bind sources to a zone: --add-source=<source>[/<mask>]

For connections handled by NetworkManager, use the connection editor and 
change the zone in the general tag according to your needs. If an 
interface is bound to a zone within firewalld and NM uses this interface 
to establish a connection it will be bound to the zone from the NM 
configuration.
> # iptables -A FORWARD -i eth0 -o eth1 -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> # iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
> # iptables -A FORWARD -j LOG

We have fixed global rules for the conntrack match:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
These rules are the first rules in the INPUT and FORWARD chain. A 
limitation of these to input or output interfaces within a zone is not 
supported right now.

You can turn on logging with the rich language, but this is only usable 
for INPUT with the current version of the rich language.

We can do a lot more with firewalld compared to what e have been able to 
do with system-config-firewall/lokkit in the past, but there are still a 
lot of things, that we can add. Like for example the things you need.

But we have a way to at least add a lot of additional stuff with the 
direct interface/option of firewalld. With this you can add rules, that 
are not possible with firewalld itself right now. But with a limitation 
that will be solved with the next version of firewalld: Permanent direct 
rules. This is already worked on and should be finished soon.

Knowledge of the ip*tables syntax is needed to add rules with the 
firewalld direct interface:

firewall-cmd --direct --add-rule {ipv4|ipv6|eb} table chain priority args

args are normal ip*tables arguments without table and chain. The 
priority is used to order rules. Priority 0 means add rule on top of the 
chain, with a higher priority the rule will be added further down. Rules 
with the same priority are on the same level and the order of these 
rules is not fixed and may change. If you want to make sure that a rule 
will be added after another one, use a low priority for the first and a 
higher for the following.

The limitation with -i eth0 -o eth1 in the state match will be still 
there though.
> # iptables -t NAT -A POSTROUTING -o eth0 -j MASQUERADE

Bind eth0 for example to the external zone using the ifcfg file or with 
the NM configuration for the conneciton using this interface. In the 
external zone masquerading is enabled as a default.

The result will look like this in the NAT table:

-A POSTROUTING -j POSTROUTING_direct
-A POSTROUTING -j POSTROUTING_ZONES
-A POSTROUTING_ZONES -o eth0 -g POST_ZONE_external
-A POST_ZONE_external -j POST_ZONE_external_log
-A POST_ZONE_external -j POST_ZONE_external_deny
-A POST_ZONE_external -j POST_ZONE_external_allow
-A POST_ZONE_external_allow -j MASQUERADE

firewalld creates a list of chains to be able to sort rules that are 
created using the normal options. Log rules are handled first, then deny 
and in the end allow rules.

With some firewall configurations the transitions to firewalld is not 
easly possible without adaptions. I am also working on a merge script, 
that tries to convert ip*tables and ebtables rules for firewalld using 
the direct interface. But there are some limitations.

Thomas