Port Forwarding Multiple IP

[s.d.]

I like to replace my Windows 2019 RRAS Router with CentOS8 Router.

I have 2 Network Cards

ens2p0 - for internal Network IP 192.168.1.1/255.255.255.0

ens3p0 - for external Network having 5 static IP from my Internet Provider
93.51.115.44-48 Netmask 255.255.255.248 / Gateway 93.51.115.43 / Also got 2 DNS Sever

Now i like to forward some Traffic to internal Server depending on the incoming IP Adress

93.51.115.44:80 -> 192.168.1.21:80
93.51.115.46:80 -> 192.168.1.100:80

i created 4 virtual network interface ens3p0.1-4 with separate Firewall zones (ip 44 = zone=external/IP 45 = zone=ext45 / IP 46 = zone=ext46 ...)
IP A lists all 5 Interfaces as expected and Firewall Zones are created

I added Port Forwarding in Firewall-cmd

firewall-cmd --permanent --zone=external --add-forward-port=port=80:proto=tcp:toaddr=192.168.1.21:toport=80
firewall-cmd --permanent --zone=ext46 --add-forward-port=port=80:proto=tcp:toaddr=192.168.1.100:toport=80

But Connection to 93.51.115.46:80 routes every time to 192.168.1.21:80
Second Zone / Rules are ignored.

Can anybody help me ?

May be its the same Problem listed here: viewtopic.php?t=62519

[TrevorH]

I think you will need to use iptables or nftables directly to do this. The post you linked to has no ability to look at the source ip address in the forwarding parameters. On el8, iptables is just a front-end for nftables but if you are more familiar with iptables than with nftables then it may be easier to use it. Not everything works with the iptables emulation but I've not found anything that doesn'y (yet).

[jlehtone]

Look at the:

Code: Select all

nft list ruleset

(I know tracing packet through that "thing" ain't easy.)

Is there anything that could explain why packets go as they do?
For example, does "in via ens3p0" grab packets to its zone even though there is later "in via ens3p0.1"?

If so, then "IP aliases" is not an answer and you can as well put all the addresses to the ens3p0 directly.
Then disable&mask firewalld.service, craft ruleset that works, and load it with nftables.service (or iptables.service, if still using that syntax).

[jlehtone]

On second thought,

For FirewallD "a zone" is all the clients that have access to same set of services.
E.g. if everyone in the WAN should have access to all five HTTP services, then they are in same zone.

Furthermore, a client can be in only one zone. (Which you saw.)

Not that it makes any difference, because zone's port forwarding does not act based on destination address:

Code: Select all

--add-forward-port=port=portid[-portid]:proto=protocol[:toport=portid[-portid]][:toaddr=address[/mask]]

There is no "[:originallytoaddr=address]" in that.


The port-forward feature of FirewallD thus cannot do the job. The next offer from FirewallD is rich language.
See man firewalld.richlanguage

General rule structure

Code: Select all

           rule
             [source]
             [destination]
             service|port|protocol|icmp-block|icmp-type|masquerade|forward-port|source-port
             [log]
             [audit]
             [accept|reject|drop|mark]

Rich rules should then look like:

Code: Select all

rule family="ipv4" destination address="93.51.115.44" forward-port protocol="tcp" port="80" to-addr="192.168.1.21" to-port="80"
rule family="ipv4" destination address="93.51.115.46" forward-port protocol="tcp" port="80" to-addr="192.168.1.100" to-port="80"

I do know that the --add-forward-port does add multiple actual rules:
* The DNAT in prerouting
* The allow in forward for packets that were dnatted
* Possibly something in mangle so that forward can match the dnatted packets
Does the forward-port in a rich rule go through the same motions? Honestly, if I ever knew/did test, I have forgotten.

The extra spice is that now FirewallD in EL8 (and EL9) does support creating rules for forwarding traffic from one zone to another with "policies".
Before, only the --add-forward-port and (deprecated) direct rules could do some of that.


Which is easier and better for long term: to make FirewallD "behave" or to create {nf,ip}tables rules?
I can't say, but iptables syntax is definitely not the long term option.

[TrevorH]

I can't say, but iptables syntax is definitely not the long term option.

It's still present and working in el9 so that depends on your definition of longterm

[s.d.]

ty I#ll try but i need some time to test it

[s.d.]

It runs on Cent OS9 now - tyvm