As a network adminstrator, I often have to set up network gear for remote sites before shipping it.

I have found it convenient to use a linux workstation with two network cards, setting the secondary NIC to an IP address in the same subnet as the equipment I'm setting up will use in the remote site.

company network--(eth0)-- fedora --(eth1)--- config network

I've enabled routing through the workstation, and can add routes to the new subnet pointing at the linux workstation's primary NIC and can ping through the workstation to the network gear I'm setting up, but tcp connections don't get through without shutting down firewalld.

I've looked in the gui and searched around for how to add a rule allowing any traffic destined to the configuration network NIC's device name, but all the entries I find want to NAT/Masquerade the inside network to the outside, and I don't want to do that - I occasionally need to allow access to the config network to co-workers at other sites, so masquerading would not be useful

Also, the IP addresses of the config network are usually different for each device or set of devices I'm setting up, which is why I was hoping to find a way to set the rule by interface name vs. IP addresses.

Firewalld's Rich Rules has a Destination field, but it only seems to take address/mask, not interface.

Any ideas? I'm guessing I'm going to be stuck reverting to iptables vs. firewalld, and advice on switching Fedora 29 from firewalld to iptables and iptables command(s) to accomplish this rule would be welcome as well.


A compromise is mentioned at https://www.lisenet.com/2016/firewalld-rich-and-direct-rules-setup-rhel-7-server-as-a-router/

It looks like it involves using "direct" rules, to add a raw iptables rule into the table generated by firewalld.

You ask to allow forwarding in either direction. If I read correctly, it should be possible like this:

firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -i eth1 -o eth2  -j ACCEPT
firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -i eth2 -o eth1  -j ACCEPT

Without knowing further details, I would not recommend this policy. It means "company network" can probably scan your config network for boxes which have hardcoded default passwords. Not a personal criticism; just a note for anyone else reading this.

One consideration might be to limit the forwarding to SSH, HTTPS and HTTP ports. In case there are any "password recovery" or "debugging" mechanisms on ports that you're not thinking about :-).

  • Specifying FORWARD rules properly seems to be not possible in any other than the described way here. – sjas Aug 6 at 18:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.