I thought I had this figured out. I've got a box with two interfaces. One is "public" (not really, but for now it is), and the other is on a private net (172.16.4.0/24). All is OK, but if I try to setup nat through iptables, it doesn't work (yet). I'm trying to get a browser path (port 80) to translate. I can telnet to the object (server) machine's port 80 (it connects, but I don't do much else, a browser DOES work). I try to do a telnet to 'localhost' with port 80 and it doesn't translate. For reference my iptables save gets me:

>>>>>
[root@box1 ~]# iptables-save
# Generated by iptables-save v1.4.21 on Fri Sep 6 18:06:50 2019
*filter
:INPUT ACCEPT [37676:7078060]
:FORWARD ACCEPT [14:2180]
:OUTPUT ACCEPT [3363:465365]
COMMIT
# Completed on Fri Sep 6 18:06:50 2019
# Generated by iptables-save v1.4.21 on Fri Sep 6 18:06:50 2019
*nat
:PREROUTING ACCEPT [7814:1278912]
:INPUT ACCEPT [7066:1207801]
:OUTPUT ACCEPT [104:7746]
:POSTROUTING ACCEPT [13:716]
-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.16.4.101:80
-A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.4.101:443
-A POSTROUTING -o eno1 -j MASQUERADE
COMMIT
# Completed on Fri Sep 6 18:06:50 2019
<<<<<

According to the documentation I read, this should be enough.

Actually I'm running on CentOS, but Fedora ought to be close enough.

Thanks.

whatever Linux (or even BSD) you're running on, that's fine. don't worry about what's close. anyone who doesn't know what's close, you don't want their answers, anyway. just tell us what you are running, the version, and how you configure it and/or start it.

i recommend writing a script to do all the setup for each project. but that may require you to learn it if you don't already know.

While Fedora is in the RHEL ecosystem; CentOS isn't "bleeding edge" like Fedora is, so there are some differences between the two.

And shouldn't you be using SSH instead of telnet?

I believe the OP is using telnet to test if forwarding port 80 traffic is working. Your assuming that

en01 is your WAN interface. Post your private interface.

You also need to configure IP packet forwarding (see /etc/sysctl.conf)

echo 1 > /proc/sys/net/ipv4/ip_forward

To really test your NAT configuration you need to configure your WAN interface and connect that to your home network instead of using localhost.

In addition to the iptables rules posted you also need a rule to forward traffic from your LAN back to the WAN interface. This will forward all traffic but you can limit it to just 80 and 443 after you see that it is working.

iptables --append FORWARD --in-interface LAN-interface -j ACCEPT

I've moved your thread to CentOS.

Some notes:

Yes, I was using telnet to port 80 to see if it worked. It is an easy way to do it.
Fedora/CentOS: As delivered, CentOS has a whole bunch of firewall stuff configured with its 'firewalld' program. I turned it off to make the process easier for (at least me!) to understand.
IP Packet forward is turned on:
>>>>>
[root@box1 ~]# cat /proc/sys/net/ipv4/ip_forward
1
<<<<<
I added to iptables APPEND command. No joy.
My dump of IPTables now reads:
>>>>>
[root@box1 ~]# iptables-save
# Generated by iptables-save v1.4.21 on Mon Sep 9 09:17:45 2019
*filter
:INPUT ACCEPT [5003:842941]
:FORWARD ACCEPT [7:420]
:OUTPUT ACCEPT [476:44526]
-A FORWARD -i ens1f0 -j ACCEPT
COMMIT
# Completed on Mon Sep 9 09:17:45 2019
# Generated by iptables-save v1.4.21 on Mon Sep 9 09:17:45 2019
*nat
:PREROUTING ACCEPT [479593:77403072]
:INPUT ACCEPT [414940:71870244]
:OUTPUT ACCEPT [4476:362328]
:POSTROUTING ACCEPT [14:1440]
-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.16.4.101:80
-A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.4.101:443
-A POSTROUTING -o eno1 -j MASQUERADE
COMMIT
# Completed on Mon Sep 9 09:17:45 2019
<<<<<

Yes, I tried to access port 80 from another machine (not through localhost), and it times out.

For the curious: 'eno1' is the "wan" interface, and 'ens1f0' it the "lan" interface.

Any more ideas...

Thanks.

More trials and tribulations.

I did get it functional. The problem was in the object ("lan" machine) that had a different "default" route. It seems that the NAT box ("box1" in the examples above) had another "default" route. For some reason (I don't know right now) when a connection comes in over an interface, it will take the highest priority route (in this case a default route via another machine) instead of going back on the interface it came over.

outside --> box1 (nat) --> object. Return path
object --> other machine --> outside (which has no connectivity back to the "outside" machine) No Joy.

The solution was to change the line on the object machine (ifcfg-eth0)
DEFROUTE=yes
to:
DEFROUTE=no

And joy returns to the universe, both interfaces are functional, and NAT is functional.

Of course this raises the question of WHY doesn't the incoming packet from the xyz interface go back (by default) through the same interface. I'll leave that for another day, and I have a workable solution