Hello gurus! I am running an OpenSuSE 15.3 system and using it as a gateway between the internet and my internal network of computers. This is a SOHO system which I administer myself. Internal security is not something I have to worry about since my wife and I are the only users. I have set up this gateway computer, which I call Quasar, with one internet facing NIC card, and one internal network facing NIC (192.168.10.100). On the internet facing NIC I used Yast2 to configure it with one "main" public IP address and 4 additional public IP addresses. Each of these external IP addresses I want to route to/from different systems on my internal network. So for example the following table shows what I want (with actual public IP addresses obscured) - IP address 200.xxx.xxx.10 <--------- routed to/from --------> 192.168.10.100 (this is for quasar, the gateway computer itself with the interface name simply eth0) IP address 200.xxx.xxx.11 <--------- routed to/from --------> 192.168.10.51 (this is for bigbang and the interface name is eth0:bigbangExt) IP address 200.xxx.xxx.12 <--------- routed to/from --------> 192.168.10.21 (this is for nova and the interface name is eth0:novaExt) IP address 200.xxx.xxx.13 <--------- routed to/from --------> 192.168.10.31 (this is for darkstar and the interface name is eth0:darkstarEx) etc. I have been trying to set these routes up with firewalld, but so far no joy getting it to work. Examples to the 2 main approaches I have tried are shown below. First, I configured a sejparate zone for each of the external IP address, so for example for the computer I call bigbang, I configured a zone called bigbangExt and assigned the interface eth0:bigbangExt to it. I then configured the IP Port Forwarding data such that there is an entry for each port I wanted to configure and forward to bigbang. The xml file for this configuration is shown here - quasar:/etc/firewalld/zones # cat bigbangExt.xml <?xml version="1.0" encoding="utf-8"?> <zone> <service name="apache2"/> <service name="apache2-ssl"/> <service name="http"/> <service name="https"/> <service name="smtp"/> <service name="smtps"/> <service name="smtp-submission"/> <service name="imap"/> <service name="imaps"/> <service name="pop3"/> <service name="pop3s"/> <protocol value="icmp"/> <protocol value="tcp"/> <protocol value="udp"/> <masquerade/> <forward-port port="9000-9001" protocol="tcp" to-port="9000-9001" to-addr="192.168.10.51"/> <forward-port port="465" protocol="tcp" to-port="465" to-addr="192.168.10.51"/> <forward-port port="587" protocol="tcp" to-port="587" to-addr="192.168.10.51"/> <forward-port port="25" protocol="tcp" to-port="25" to-addr="192.168.10.51"/> <forward-port port="110" protocol="tcp" to-port="110" to-addr="192.168.10.51"/> <forward-port port="995" protocol="tcp" to-port="995" to-addr="192.168.10.51"/> <forward-port port="993" protocol="tcp" to-port="993" to-addr="192.168.10.51"/> <forward-port port="10000" protocol="tcp" to-port="10000" to-addr="192.168.10.51"/> <forward-port port="80" protocol="tcp" to-port="80" to-addr="192.168.10.51"/> <forward-port port="143" protocol="tcp" to-port="143" to-addr="192.168.10.51"/> <interface name="eth0:bigbangExt"/> </zone> SURPRISINGLY to me at least, this did not work. For example, if I bring up a web browser and connect directly to the internal IP address 192.168.10.51 I will get the appropriate web page displayed. But if I connect to the external public IP address 200.xxx.xxx.11 it's no joy! So, for my second attempt, I tried using Direct Configuration in firewalld. Since I cannot do a copy/paste from firewalld, I will just show the configuration file - direct.xml, when set up just to do routing for bigbang - quasar:/etc/firewalld # cat direct.xml <?xml version="1.0" encoding="utf-8"?> <direct> <rule ipv="ipv4" table="nat" chain="PREROUTING" priority="0">-d 200.xxx.xxx.11 -i eth0:bigbangExt -j DNAT --to-destination 192.168.10.51</rule> <rule ipv="ipv4" table="nat" chain="POSTROUTING" priority="0">-s 192.168.10.51 -j SNAT --to-source 200.xxx.xxx.11</rule> <rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-s 192.168.10.51/32 -j ACCEPT</rule> <rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-d 192.168.10.51/32 -j ACCEPT</rule> </direct> However, again no joy! I am not getting routing from the external interface/IP addresses as I want/expect. I looked through the log files and iptables listings and I could not see anything obviously wrong, but then again my ability to grok iptables lists is somewhat limited. (I am by no means an expert on iptables!) I have reached the end of my ability to debug and figure out what I am doing wrong, so need some help from firewalld and iptables gurus to help me get over this hump. As always, many thanks in advance for any and all forms of assistance! MarcC -- *"The Truth is out there" - Spooky* -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed. My public key for sending encrypted email to me can be found at - https://keys.openpgp.org/search?q=marc@domesweetdome.us.com or just ask me for it and I will send it to you as an attachment. If you don't understand, no worries, just ignore it and/or ask me to explain it further./)
On Tue, Nov 15, 2022 at 12:15 AM Marc Chamberlin <marc@marcchamberlin.com> wrote:
Hello gurus! I am running an OpenSuSE 15.3 system and using it as a gateway between the internet and my internal network of computers. This is a SOHO system which I administer myself. Internal security is not something I have to worry about since my wife and I are the only users.
I have set up this gateway computer, which I call Quasar, with one internet facing NIC card, and one internal network facing NIC (192.168.10.100). On the internet facing NIC I used Yast2 to configure it with one "main" public IP address and 4 additional public IP addresses. Each of these external IP addresses I want to route to/from different systems on my internal network. So for example the following table shows what I want (with actual public IP addresses obscured) -
IP address 200.xxx.xxx.10 <--------- routed to/from --------> 192.168.10.100 (this is for quasar, the gateway computer itself with the interface name simply eth0)
IP address 200.xxx.xxx.11 <--------- routed to/from --------> 192.168.10.51 (this is for bigbang and the interface name is eth0:bigbangExt)
IP address 200.xxx.xxx.12 <--------- routed to/from --------> 192.168.10.21 (this is for nova and the interface name is eth0:novaExt)
IP address 200.xxx.xxx.13 <--------- routed to/from --------> 192.168.10.31 (this is for darkstar and the interface name is eth0:darkstarEx)
Do you actually have *interfaces* with names eth0:bigbangExt or are those just additional IP aliases on the same interface? Show output of ip l ip a
etc.
I have been trying to set these routes up with firewalld, but so far no joy getting it to work. Examples to the 2 main approaches I have tried are shown below.
First, I configured a sejparate zone for each of the external IP address, so for example for the computer I call bigbang, I configured a zone called bigbangExt and assigned the interface eth0:bigbangExt to it. I then configured the IP Port Forwarding data such that there is an entry for each port I wanted to configure and forward to bigbang. The xml file for this configuration is shown here -
quasar:/etc/firewalld/zones # cat bigbangExt.xml <?xml version="1.0" encoding="utf-8"?> <zone> <service name="apache2"/> <service name="apache2-ssl"/> <service name="http"/> <service name="https"/> <service name="smtp"/> <service name="smtps"/> <service name="smtp-submission"/> <service name="imap"/> <service name="imaps"/> <service name="pop3"/> <service name="pop3s"/> <protocol value="icmp"/> <protocol value="tcp"/> <protocol value="udp"/> <masquerade/> <forward-port port="9000-9001" protocol="tcp" to-port="9000-9001" to-addr="192.168.10.51"/> <forward-port port="465" protocol="tcp" to-port="465" to-addr="192.168.10.51"/> <forward-port port="587" protocol="tcp" to-port="587" to-addr="192.168.10.51"/> <forward-port port="25" protocol="tcp" to-port="25" to-addr="192.168.10.51"/> <forward-port port="110" protocol="tcp" to-port="110" to-addr="192.168.10.51"/> <forward-port port="995" protocol="tcp" to-port="995" to-addr="192.168.10.51"/> <forward-port port="993" protocol="tcp" to-port="993" to-addr="192.168.10.51"/> <forward-port port="10000" protocol="tcp" to-port="10000" to-addr="192.168.10.51"/> <forward-port port="80" protocol="tcp" to-port="80" to-addr="192.168.10.51"/> <forward-port port="143" protocol="tcp" to-port="143" to-addr="192.168.10.51"/> <interface name="eth0:bigbangExt"/>
Show firewall-cmd --list-all-zones firewall-cmd --list-all-policies
</zone>
SURPRISINGLY to me at least, this did not work. For example, if I bring up a web browser and connect directly to the internal IP address 192.168.10.51 I will get the appropriate web page displayed. But if I connect to the external public IP address 200.xxx.xxx.11 it's no joy!
From where do you try to connect? Do you try to connect from a system on the internal network (192.168.10.0/24)?
So, for my second attempt, I tried using Direct Configuration in firewalld. Since I cannot do a copy/paste from firewalld, I will just show the configuration file - direct.xml, when set up just to do routing for bigbang -
quasar:/etc/firewalld # cat direct.xml <?xml version="1.0" encoding="utf-8"?> <direct> <rule ipv="ipv4" table="nat" chain="PREROUTING" priority="0">-d 200.xxx.xxx.11 -i eth0:bigbangExt -j DNAT --to-destination 192.168.10.51</rule>
Same question - does this *interface* actually exist?
<rule ipv="ipv4" table="nat" chain="POSTROUTING" priority="0">-s 192.168.10.51 -j SNAT --to-source 200.xxx.xxx.11</rule> <rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-s 192.168.10.51/32 -j ACCEPT</rule> <rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-d 192.168.10.51/32 -j ACCEPT</rule> </direct>
However, again no joy! I am not getting routing from the external interface/IP addresses as I want/expect.
How did you check it?
Thanks Andrei for taking a look at my problem and asking further questions. I much appreciate your taking the time to do so. I will insert my answers to your questions/inquires within your responses so as to preserve context... On 11/15/22 00:02, Andrei Borzenkov wrote:
On Tue, Nov 15, 2022 at 12:15 AM Marc Chamberlin <marc@marcchamberlin.com> wrote:
Hello gurus! I am running an OpenSuSE 15.3 system and using it as a gateway between the internet and my internal network of computers. This is a SOHO system which I administer myself. Internal security is not something I have to worry about since my wife and I are the only users.
I have set up this gateway computer, which I call Quasar, with one internet facing NIC card, and one internal network facing NIC (192.168.10.100). On the internet facing NIC I used Yast2 to configure it with one "main" public IP address and 4 additional public IP addresses. Each of these external IP addresses I want to route to/from different systems on my internal network. So for example the following table shows what I want (with actual public IP addresses obscured) -
IP address 200.xxx.xxx.10 <--------- routed to/from --------> 192.168.10.100 (this is for quasar, the gateway computer itself with the interface name simply eth0)
IP address 200.xxx.xxx.11 <--------- routed to/from --------> 192.168.10.51 (this is for bigbang and the interface name is eth0:bigbangExt)
IP address 200.xxx.xxx.12 <--------- routed to/from --------> 192.168.10.21 (this is for nova and the interface name is eth0:novaExt)
IP address 200.xxx.xxx.13 <--------- routed to/from --------> 192.168.10.31 (this is for darkstar and the interface name is eth0:darkstarEx)
Do you actually have *interfaces* with names eth0:bigbangExt or are those just additional IP aliases on the same interface? They are additional IP aliases on the same interface.
Show output of
ip l quasar:/etc # ip l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: p3p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:13:3b:2f:d4:66 brd ff:ff:ff:ff:ff:ff altname enp10s0 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 98:90:96:e4:28:bd brd ff:ff:ff:ff:ff:ff altname enp0s25 4: p3p2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether 00:13:3b:2f:d4:67 brd ff:ff:ff:ff:ff:ff altname enp11s0
ip a OK but just being cautious I will obscure the public facing IP addresses..... quasar:/etc # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: p3p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:13:3b:2f:d4:66 brd ff:ff:ff:ff:ff:ff altname enp10s0 inet 192.168.10.100/24 brd 192.168.10.255 scope global p3p1 valid_lft forever preferred_lft forever 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 98:90:96:e4:28:bd brd ff:ff:ff:ff:ff:ff altname enp0s25 inet 200.xxx.xxx.10/29 brd 200.xxx.xxx.23 scope global eth0 valid_lft forever preferred_lft forever inet 200.xxx.xxx.11/29 brd 200.xxx.xxx.23 scope global secondary eth0:bigbangExt valid_lft forever preferred_lft forever inet 200.xxx.xxx.12/29 brd 200.xxx.xxx.23 scope global secondary eth0:novaIOTExt valid_lft forever preferred_lft forever inet 200.xxx.xxx.13/29 brd 200.xxx.xxx.23 scope global secondary eth0:darkstarEx valid_lft forever preferred_lft forever
4: p3p2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:13:3b:2f:d4:67 brd ff:ff:ff:ff:ff:ff altname enp11s0
etc.
I have been trying to set these routes up with firewalld, but so far no joy getting it to work. Examples to the 2 main approaches I have tried are shown below.
First, I configured a sejparate zone for each of the external IP address, so for example for the computer I call bigbang, I configured a zone called bigbangExt and assigned the interface eth0:bigbangExt to it. I then configured the IP Port Forwarding data such that there is an entry for each port I wanted to configure and forward to bigbang. The xml file for this configuration is shown here -
quasar:/etc/firewalld/zones # cat bigbangExt.xml <?xml version="1.0" encoding="utf-8"?> <zone> <service name="apache2"/> <service name="apache2-ssl"/> <service name="http"/> <service name="https"/> <service name="smtp"/> <service name="smtps"/> <service name="smtp-submission"/> <service name="imap"/> <service name="imaps"/> <service name="pop3"/> <service name="pop3s"/> <protocol value="icmp"/> <protocol value="tcp"/> <protocol value="udp"/> <masquerade/> <forward-port port="9000-9001" protocol="tcp" to-port="9000-9001" to-addr="192.168.10.51"/> <forward-port port="465" protocol="tcp" to-port="465" to-addr="192.168.10.51"/> <forward-port port="587" protocol="tcp" to-port="587" to-addr="192.168.10.51"/> <forward-port port="25" protocol="tcp" to-port="25" to-addr="192.168.10.51"/> <forward-port port="110" protocol="tcp" to-port="110" to-addr="192.168.10.51"/> <forward-port port="995" protocol="tcp" to-port="995" to-addr="192.168.10.51"/> <forward-port port="993" protocol="tcp" to-port="993" to-addr="192.168.10.51"/> <forward-port port="10000" protocol="tcp" to-port="10000" to-addr="192.168.10.51"/> <forward-port port="80" protocol="tcp" to-port="80" to-addr="192.168.10.51"/> <forward-port port="143" protocol="tcp" to-port="143" to-addr="192.168.10.51"/> <interface name="eth0:bigbangExt"/> Show
firewall-cmd --list-all-zones quasar:/etc # firewall-cmd --list-all-zones bigbangExt (active) target: default icmp-block-inversion: no interfaces: eth0:bigbangExt sources: services: apache2 apache2-ssl http https imap imaps pop3 pop3s smtp smtp-submission smtps ports: protocols: icmp tcp udp forward: no masquerade: yes forward-ports: port=9000-9001:proto=tcp:toport=9000-9001:toaddr=192.168.10.51 port=465:proto=tcp:toport=465:toaddr=192.168.10.51 port=587:proto=tcp:toport=587:toaddr=192.168.10.51 port=25:proto=tcp:toport=25:toaddr=192.168.10.51 port=110:proto=tcp:toport=110:toaddr=192.168.10.51 port=995:proto=tcp:toport=995:toaddr=192.168.10.51 port=993:proto=tcp:toport=993:toaddr=192.168.10.51 port=10000:proto=tcp:toport=10000:toaddr=192.168.10.51 port=80:proto=tcp:toport=80:toaddr=192.168.10.51 port=143:proto=tcp:toport=143:toaddr=192.168.10.51 source-ports: icmp-blocks: rich rules:
block target: %%REJECT%% icmp-block-inversion: no interfaces: sources: services: tigervnc vnc-server ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: darkstarEx (active) target: default icmp-block-inversion: no interfaces: darkstarEx sources: services: bacula-client imap imaps pop3 pop3s smtp smtp-submission smtps ports: protocols: icmp tcp udp forward: no masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules: dmz target: default icmp-block-inversion: no interfaces: sources: services: ssh ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: docker (active) target: ACCEPT icmp-block-inversion: no interfaces: docker0 sources: services: ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: drop (active) target: DROP icmp-block-inversion: no interfaces: eth1 eth2 sources: services: vnc-server ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: external (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: apache2 apache2-ssl dns dns-over-tls http https imap imaps pop3 pop3s smtp smtp-submission smtps ports: 622/tcp 953/tcp 3052/tcp 5500-5504/tcp 8080-8089/tcp 9050/tcp 1000-1100/tcp 953/udp 5500-5504/udp 10000/tcp 10143/tcp 10995/tcp 10587/tcp 10110/tcp 10465/tcp 10025/tcp 10993/tcp protocols: forward: no masquerade: yes forward-ports: port=8087:proto=tcp:toport=80:toaddr=192.168.10.50 port=995:proto=tcp:toport=10995:toaddr= port=587:proto=tcp:toport=10587:toaddr= port=110:proto=tcp:toport=10110:toaddr= port=465:proto=tcp:toport=10465:toaddr= port=25:proto=tcp:toport=10025:toaddr= port=143:proto=tcp:toport=10143:toaddr=200.xxx.xxx.10 port=993:proto=tcp:toport=10993:toaddr=200.xxx.xxx.10 source-ports: 10143/tcp icmp-blocks: rich rules: home target: default icmp-block-inversion: no interfaces: sources: services: samba-client ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: internal (active) target: default icmp-block-inversion: no interfaces: p3p1 p3p2 tun0 sources: services: apache2 apache2-ssl bacula-client dhcp dhcpv6-client dns dns-over-tls http https imap imaps ipp mdns mysql nfs ntp privoxy samba samba-client slp smtp smtp-submission smtps telnet ports: 622/tcp 1111/tcp 1935/tcp 3310/tcp 4555/tcp 8006-8007/tcp 901/tcp 9050/tcp 1111/udp 1935/udp 3389/udp 4555/udp 111/udp 138/udp 137/udp 139/udp 1194/udp 67/udp 138/tcp 137/tcp 139/tcp 119/tcp 111/tcp 8080-8087/tcp 10143/tcp 10000/tcp 10993/tcp 10995/tcp 10587/tcp 10110/tcp 10465/tcp 10025/tcp protocols: forward: no masquerade: no forward-ports: port=8087:proto=tcp:toport=80:toaddr=192.168.10.50 port=143:proto=tcp:toport=10143:toaddr= port=993:proto=tcp:toport=10993:toaddr= port=995:proto=tcp:toport=10995:toaddr= port=587:proto=tcp:toport=10587:toaddr= port=110:proto=tcp:toport=10110:toaddr= port=465:proto=tcp:toport=10465:toaddr= port=25:proto=tcp:toport=10025:toaddr= source-ports: 10143/tcp icmp-blocks: rich rules: novaIOTExt (active) target: default icmp-block-inversion: no interfaces: novaIOTExt sources: services: apache2 apache2-ssl http https imap imaps pop3 pop3s smtp smtp-submission smtps ports: protocols: forward: no masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules: public target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: trusted (active) target: ACCEPT icmp-block-inversion: no interfaces: lo sources: services: apache2 apache2-ssl bacula-client dhcp dns http https imap imaps samba samba-client smtp smtps ports: 10143/tcp 10025/tcp 10465/tcp 10110/tcp 10587/tcp 10995/tcp 10993/tcp 10000/tcp protocols: forward: no masquerade: no forward-ports: port=143:proto=tcp:toport=10143:toaddr= port=993:proto=tcp:toport=10993:toaddr= port=995:proto=tcp:toport=10995:toaddr= port=587:proto=tcp:toport=10587:toaddr= port=110:proto=tcp:toport=10110:toaddr= source-ports: 10143/tcp icmp-blocks: rich rules: work target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client ssh ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
firewall-cmd --list-all-policies quasar:/etc # firewall-cmd --list-all-policies allow-host-ipv6 (active) priority: -15000 target: CONTINUE ingress-zones: ANY egress-zones: HOST services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv6" icmp-type name="neighbour-advertisement" accept rule family="ipv6" icmp-type name="neighbour-solicitation" accept rule family="ipv6" icmp-type name="router-advertisement" accept rule family="ipv6" icmp-type name="redirect" accept
</zone>
SURPRISINGLY to me at least, this did not work. For example, if I bring up a web browser and connect directly to the internal IP address 192.168.10.51 I will get the appropriate web page displayed. But if I connect to the external public IP address 200.xxx.xxx.11 it's no joy!
From where do you try to connect? Do you try to connect from a system on the internal network (192.168.10.0/24)? Yes.
So, for my second attempt, I tried using Direct Configuration in firewalld. Since I cannot do a copy/paste from firewalld, I will just show the configuration file - direct.xml, when set up just to do routing for bigbang -
quasar:/etc/firewalld # cat direct.xml <?xml version="1.0" encoding="utf-8"?> <direct> <rule ipv="ipv4" table="nat" chain="PREROUTING" priority="0">-d 200.xxx.xxx.11 -i eth0:bigbangExt -j DNAT --to-destination 192.168.10.51</rule> Same question - does this *interface* actually exist? I think you are asking me if this is an alias for a single interface (NIC) with a single Ethernet CAT-5 connector. Yes, so no this *interface* does not actually exist.
<rule ipv="ipv4" table="nat" chain="POSTROUTING" priority="0">-s 192.168.10.51 -j SNAT --to-source 200.xxx.xxx.11</rule> <rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-s 192.168.10.51/32 -j ACCEPT</rule> <rule ipv="ipv4" table="filter" chain="FORWARD" priority="0">-d 192.168.10.51/32 -j ACCEPT</rule> </direct>
However, again no joy! I am not getting routing from the external interface/IP addresses as I want/expect. How did you check it? I mainly tested it by using the direct numeric IP addresses in a web browser to see if I could reach the Apache web server running on the targeted system (Bigbang in this case) so as not to require a DNS lookup. If I use the internal IP address of Bigbang it works, but if I use the external public IP address that I want routed to bigbang, it fails.
-- *"The Truth is out there" - Spooky* *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed and the OpenPGP electronic signature is added as an attachment. If you know how, you can use my public key to prove this email indeed came from me and has not been modified in transit. My public key, which can be used for sending encrypted email to me also, can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand all this geek speak, no worries, just ignore this explanation and ignore the OpenPGP signature key attached to this email (it will look like gibberish if you open it) and/or ask me to explain it further if you like./)
On 15.11.2022 22:11, Marc Chamberlin wrote:
SURPRISINGLY to me at least, this did not work. For example, if I bring up a web browser and connect directly to the internal IP address 192.168.10.51 I will get the appropriate web page displayed. But if I connect to the external public IP address 200.xxx.xxx.11 it's no joy!
From where do you try to connect? Do you try to connect from a system on the internal network (192.168.10.0/24)? Yes.
That won't work. It is impossible to access external address redirected into internal network from this internal network (OK, it is possible but it requires extra NAT rules for return packets). To test your port forwarding you must use external system. https://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-10.html I cannot tell whether IP aliases should work with firewalld right now.
On 15.11.2022 22:11, Marc Chamberlin wrote:
SURPRISINGLY to me at least, this did not work. For example, if I bring up a web browser and connect directly to the internal IP address 192.168.10.51 I will get the appropriate web page displayed. But if I connect to the external public IP address 200.xxx.xxx.11 it's no joy!
From where do you try to connect? Do you try to connect from a system on the internal network (192.168.10.0/24)? Yes.
That won't work. It is impossible to access external address redirected into internal network from this internal network (OK, it is possible but it requires extra NAT rules for return packets).
To test your port forwarding you must use external system.
https://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-10.html OK, I both had a friend try to reach my internal web server on the computer I call bigbang, and I tried to reach it via my smart phone with
On 11/15/22 11:22, Andrei Borzenkov wrote: the WiFi turned off. This forces the browser on my phone to try and reach my web server from an external location via the external IP address that I am trying to designate and route to the web server. No Joy!
I cannot tell whether IP aliases should work with firewalld right now.
Hmm I hope so! Thanks Andrie for your continued help... Marc... -- *"The Truth is out there" - Spooky* *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed and the OpenPGP electronic signature is added as an attachment. If you know how, you can use my public key to prove this email indeed came from me and has not been modified in transit. My public key, which can be used for sending encrypted email to me also, can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand all this geek speak, no worries, just ignore this explanation and ignore the OpenPGP signature key attached to this email (it will look like gibberish if you open it) and/or ask me to explain it further if you like./)
On Tue, Nov 15, 2022 at 10:11 PM Marc Chamberlin <marc@marcchamberlin.com> wrote:
Thanks Andrei for taking a look at my problem and asking further questions. I much appreciate your taking the time to do so. I will insert my answers to your questions/inquires within your responses so as to preserve context...
On 11/15/22 00:02, Andrei Borzenkov wrote:
On Tue, Nov 15, 2022 at 12:15 AM Marc Chamberlin <marc@marcchamberlin.com> wrote:
Hello gurus! I am running an OpenSuSE 15.3 system and using it as a gateway between the internet and my internal network of computers. This is a SOHO system which I administer myself. Internal security is not something I have to worry about since my wife and I are the only users.
I have set up this gateway computer, which I call Quasar, with one internet facing NIC card, and one internal network facing NIC (192.168.10.100). On the internet facing NIC I used Yast2 to configure it with one "main" public IP address and 4 additional public IP addresses. Each of these external IP addresses I want to route to/from different systems on my internal network. So for example the following table shows what I want (with actual public IP addresses obscured) -
IP address 200.xxx.xxx.10 <--------- routed to/from --------> 192.168.10.100 (this is for quasar, the gateway computer itself with the interface name simply eth0)
IP address 200.xxx.xxx.11 <--------- routed to/from --------> 192.168.10.51 (this is for bigbang and the interface name is eth0:bigbangExt)
IP address 200.xxx.xxx.12 <--------- routed to/from --------> 192.168.10.21 (this is for nova and the interface name is eth0:novaExt)
IP address 200.xxx.xxx.13 <--------- routed to/from --------> 192.168.10.31 (this is for darkstar and the interface name is eth0:darkstarEx)
Do you actually have *interfaces* with names eth0:bigbangExt or are those just additional IP aliases on the same interface? They are additional IP aliases on the same interface.
...
2: p3p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:13:3b:2f:d4:66 brd ff:ff:ff:ff:ff:ff altname enp10s0 inet 192.168.10.100/24 brd 192.168.10.255 scope global p3p1 valid_lft forever preferred_lft forever 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 98:90:96:e4:28:bd brd ff:ff:ff:ff:ff:ff altname enp0s25 inet 200.xxx.xxx.10/29 brd 200.xxx.xxx.23 scope global eth0 valid_lft forever preferred_lft forever inet 200.xxx.xxx.11/29 brd 200.xxx.xxx.23 scope global secondary eth0:bigbangExt valid_lft forever preferred_lft forever inet 200.xxx.xxx.12/29 brd 200.xxx.xxx.23 scope global secondary eth0:novaIOTExt valid_lft forever preferred_lft forever inet 200.xxx.xxx.13/29 brd 200.xxx.xxx.23 scope global secondary eth0:darkstarEx valid_lft forever preferred_lft forever
So you have two interfaces p3p1 and eth0, eth0 being your external interface. Additional addresses are not interfaces and you cannot use them where interfaces are expected. The names you see are just labels on these additional addresses. ...
firewall-cmd --list-all-zones quasar:/etc # firewall-cmd --list-all-zones bigbangExt (active) target: default icmp-block-inversion: no interfaces: eth0:bigbangExt sources: services: apache2 apache2-ssl http https imap imaps pop3 pop3s smtp smtp-submission smtps ports: protocols: icmp tcp udp forward: no masquerade: yes forward-ports: port=9000-9001:proto=tcp:toport=9000-9001:toaddr=192.168.10.51 port=465:proto=tcp:toport=465:toaddr=192.168.10.51 port=587:proto=tcp:toport=587:toaddr=192.168.10.51 port=25:proto=tcp:toport=25:toaddr=192.168.10.51 port=110:proto=tcp:toport=110:toaddr=192.168.10.51 port=995:proto=tcp:toport=995:toaddr=192.168.10.51 port=993:proto=tcp:toport=993:toaddr=192.168.10.51 port=10000:proto=tcp:toport=10000:toaddr=192.168.10.51 port=80:proto=tcp:toport=80:toaddr=192.168.10.51 port=143:proto=tcp:toport=143:toaddr=192.168.10.51 source-ports: icmp-blocks: rich rules:
Your zone is considered "active" because it has interface definition, but as there is no real interface that matches this zone, so no packet will ever use these rules. ...
drop (active) target: DROP icmp-block-inversion: no interfaces: eth1 eth2
Not relevant to your question, but you do not have interfaces eth1 and eth2 so this is just confusing. ...
external (active) target: default icmp-block-inversion: no interfaces: eth0
And this is the zone used for packets coming in via interface eth0 (*any* address).
sources: services: apache2 apache2-ssl dns dns-over-tls http https imap imaps pop3 pop3s smtp smtp-submission smtps ports: 622/tcp 953/tcp 3052/tcp 5500-5504/tcp 8080-8089/tcp 9050/tcp 1000-1100/tcp 953/udp 5500-5504/udp 10000/tcp 10143/tcp 10995/tcp 10587/tcp 10110/tcp 10465/tcp 10025/tcp 10993/tcp protocols: forward: no masquerade: yes forward-ports: port=8087:proto=tcp:toport=80:toaddr=192.168.10.50 port=995:proto=tcp:toport=10995:toaddr= port=587:proto=tcp:toport=10587:toaddr= port=110:proto=tcp:toport=10110:toaddr= port=465:proto=tcp:toport=10465:toaddr= port=25:proto=tcp:toport=10025:toaddr= port=143:proto=tcp:toport=10143:toaddr=200.xxx.xxx.10 port=993:proto=tcp:toport=10993:toaddr=200.xxx.xxx.10 source-ports: 10143/tcp icmp-blocks: rich rules:
...
internal (active) target: default icmp-block-inversion: no interfaces: p3p1 p3p2 tun0
This zone is used for packets coming in via your interfaces p3p1, p3p2, i.e. from your internal systems.
sources: services: apache2 apache2-ssl bacula-client dhcp dhcpv6-client dns dns-over-tls http https imap imaps ipp mdns mysql nfs ntp privoxy samba samba-client slp smtp smtp-submission smtps telnet ports: 622/tcp 1111/tcp 1935/tcp 3310/tcp 4555/tcp 8006-8007/tcp 901/tcp 9050/tcp 1111/udp 1935/udp 3389/udp 4555/udp 111/udp 138/udp 137/udp 139/udp 1194/udp 67/udp 138/tcp 137/tcp 139/tcp 119/tcp 111/tcp 8080-8087/tcp 10143/tcp 10000/tcp 10993/tcp 10995/tcp 10587/tcp 10110/tcp 10465/tcp 10025/tcp protocols: forward: no masquerade: no forward-ports: port=8087:proto=tcp:toport=80:toaddr=192.168.10.50
Are you sure you really want this? It means that when some *internal* system makes a request to port 8087 with *any* destination address, it will be redirected to the 192.168.10.50. Apart from the fact that it will not work (for the same reason explained in another mail) I suspect that is not what you want. At least it is not what you described.
port=143:proto=tcp:toport=10143:toaddr=
Ditto. It means that if some *internal* system makes a request to e.g. imap.gmail.com (ignore plain text for now) it will be redirected to port 10143 on imap.gmail.com. Do you think it will work?
port=993:proto=tcp:toport=10993:toaddr= port=995:proto=tcp:toport=10995:toaddr= port=587:proto=tcp:toport=10587:toaddr= port=110:proto=tcp:toport=10110:toaddr= port=465:proto=tcp:toport=10465:toaddr= port=25:proto=tcp:toport=10025:toaddr= source-ports: 10143/tcp
I am not sure what it really does. In the worst case it assigns every packet with source port 10143 to the zone "internal" which probably again is not what you want.
icmp-blocks: rich rules:
...
trusted (active) target: ACCEPT icmp-block-inversion: no interfaces: lo sources: services: apache2 apache2-ssl bacula-client dhcp dns http https imap imaps samba samba-client smtp smtps ports: 10143/tcp 10025/tcp 10465/tcp 10110/tcp 10587/tcp 10995/tcp 10993/tcp 10000/tcp protocols: forward: no masquerade: no forward-ports: port=143:proto=tcp:toport=10143:toaddr= port=993:proto=tcp:toport=10993:toaddr= port=995:proto=tcp:toport=10995:toaddr= port=587:proto=tcp:toport=10587:toaddr= port=110:proto=tcp:toport=10110:toaddr= source-ports: 10143/tcp icmp-blocks: rich rules:
Again I do not know whether this is what you really want or just leftover from some experiments. ...
firewall-cmd --list-all-policies quasar:/etc # firewall-cmd --list-all-policies allow-host-ipv6 (active) priority: -15000 target: CONTINUE ingress-zones: ANY egress-zones: HOST services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv6" icmp-type name="neighbour-advertisement" accept rule family="ipv6" icmp-type name="neighbour-solicitation" accept rule family="ipv6" icmp-type name="router-advertisement" accept rule family="ipv6" icmp-type name="redirect" accept
Well ... by default firewalld blocks forwarding between interfaces in different zones. This could be yet another reason for failure. You need policies allowing traffic between external and internal interfaces (in both directions). Your question is not new and rich rules are probably the most simple solution. https://forums.centos.org/viewtopic.php?t=71334 See also another idea in the post linked in this thread.
Thanks Andrei for taking a look at my problem and asking further questions. I much appreciate your taking the time to do so. I will insert my answers to your questions/inquires within your responses so as to preserve context...
On 11/15/22 00:02, Andrei Borzenkov wrote:
On Tue, Nov 15, 2022 at 12:15 AM Marc Chamberlin <marc@marcchamberlin.com> wrote:
Hello gurus! I am running an OpenSuSE 15.3 system and using it as a gateway between the internet and my internal network of computers. This is a SOHO system which I administer myself. Internal security is not something I have to worry about since my wife and I are the only users.
I have set up this gateway computer, which I call Quasar, with one internet facing NIC card, and one internal network facing NIC (192.168.10.100). On the internet facing NIC I used Yast2 to configure it with one "main" public IP address and 4 additional public IP addresses. Each of these external IP addresses I want to route to/from different systems on my internal network. So for example the following table shows what I want (with actual public IP addresses obscured) -
IP address 200.xxx.xxx.10 <--------- routed to/from --------> 192.168.10.100 (this is for quasar, the gateway computer itself with the interface name simply eth0)
IP address 200.xxx.xxx.11 <--------- routed to/from --------> 192.168.10.51 (this is for bigbang and the interface name is eth0:bigbangExt)
IP address 200.xxx.xxx.12 <--------- routed to/from --------> 192.168.10.21 (this is for nova and the interface name is eth0:novaExt)
IP address 200.xxx.xxx.13 <--------- routed to/from --------> 192.168.10.31 (this is for darkstar and the interface name is eth0:darkstarEx)
Do you actually have *interfaces* with names eth0:bigbangExt or are those just additional IP aliases on the same interface? They are additional IP aliases on the same interface. ... 2: p3p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:13:3b:2f:d4:66 brd ff:ff:ff:ff:ff:ff altname enp10s0 inet 192.168.10.100/24 brd 192.168.10.255 scope global p3p1 valid_lft forever preferred_lft forever 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 98:90:96:e4:28:bd brd ff:ff:ff:ff:ff:ff altname enp0s25 inet 200.xxx.xxx.10/29 brd 200.xxx.xxx.23 scope global eth0 valid_lft forever preferred_lft forever inet 200.xxx.xxx.11/29 brd 200.xxx.xxx.23 scope global secondary eth0:bigbangExt valid_lft forever preferred_lft forever inet 200.xxx.xxx.12/29 brd 200.xxx.xxx.23 scope global secondary eth0:novaIOTExt valid_lft forever preferred_lft forever inet 200.xxx.xxx.13/29 brd 200.xxx.xxx.23 scope global secondary eth0:darkstarEx valid_lft forever preferred_lft forever
So you have two interfaces p3p1 and eth0, eth0 being your external interface. Additional addresses are not interfaces and you cannot use
On Tue, Nov 15, 2022 at 10:11 PM Marc Chamberlin <marc@marcchamberlin.com> wrote: them where interfaces are expected. The names you see are just labels on these additional addresses. This doesn't really make sense to me, what it seems you are telling me is that firewalld cannon handle additional addresses assigned to a NIC card. If so, then that leaves me with 3 possible options and firewalld is nearly useless. I can only set up iptable rules directly, I can
On 11/15/22 23:13, Andrei Borzenkov wrote: possibly use rich rules instead, or I can go buy a switch, 4 cat5 cables and a NIC with 4 actual cat5 connectors. Since I could use the exact same hardware configuration with SuSEFirewall2 and iptable rules, that I currently have, I will look into doing everything via iptable rules instead. Sigh!
...
firewall-cmd --list-all-zones quasar:/etc # firewall-cmd --list-all-zones bigbangExt (active) target: default icmp-block-inversion: no interfaces: eth0:bigbangExt sources: services: apache2 apache2-ssl http https imap imaps pop3 pop3s smtp smtp-submission smtps ports: protocols: icmp tcp udp forward: no masquerade: yes forward-ports: port=9000-9001:proto=tcp:toport=9000-9001:toaddr=192.168.10.51 port=465:proto=tcp:toport=465:toaddr=192.168.10.51 port=587:proto=tcp:toport=587:toaddr=192.168.10.51 port=25:proto=tcp:toport=25:toaddr=192.168.10.51 port=110:proto=tcp:toport=110:toaddr=192.168.10.51 port=995:proto=tcp:toport=995:toaddr=192.168.10.51 port=993:proto=tcp:toport=993:toaddr=192.168.10.51 port=10000:proto=tcp:toport=10000:toaddr=192.168.10.51 port=80:proto=tcp:toport=80:toaddr=192.168.10.51 port=143:proto=tcp:toport=143:toaddr=192.168.10.51 source-ports: icmp-blocks: rich rules:
Your zone is considered "active" because it has interface definition, but as there is no real interface that matches this zone, so no packet will ever use these rules.
See my comment above, this renders firewalld nearly useless for me.
...
drop (active) target: DROP icmp-block-inversion: no interfaces: eth1 eth2 Not relevant to your question, but you do not have interfaces eth1 and eth2 so this is just confusing. ...
external (active) target: default icmp-block-inversion: no interfaces: eth0 And this is the zone used for packets coming in via interface eth0 (*any* address).
sources: services: apache2 apache2-ssl dns dns-over-tls http https imap imaps pop3 pop3s smtp smtp-submission smtps ports: 622/tcp 953/tcp 3052/tcp 5500-5504/tcp 8080-8089/tcp 9050/tcp 1000-1100/tcp 953/udp 5500-5504/udp 10000/tcp 10143/tcp 10995/tcp 10587/tcp 10110/tcp 10465/tcp 10025/tcp 10993/tcp protocols: forward: no masquerade: yes forward-ports: port=8087:proto=tcp:toport=80:toaddr=192.168.10.50 port=995:proto=tcp:toport=10995:toaddr= port=587:proto=tcp:toport=10587:toaddr= port=110:proto=tcp:toport=10110:toaddr= port=465:proto=tcp:toport=10465:toaddr= port=25:proto=tcp:toport=10025:toaddr= port=143:proto=tcp:toport=10143:toaddr=200.xxx.xxx.10 port=993:proto=tcp:toport=10993:toaddr=200.xxx.xxx.10 source-ports: 10143/tcp icmp-blocks: rich rules:
internal (active) target: default icmp-block-inversion: no interfaces: p3p1 p3p2 tun0 This zone is used for packets coming in via your interfaces p3p1,
... p3p2, i.e. from your internal systems.
sources: services: apache2 apache2-ssl bacula-client dhcp dhcpv6-client dns dns-over-tls http https imap imaps ipp mdns mysql nfs ntp privoxy samba samba-client slp smtp smtp-submission smtps telnet ports: 622/tcp 1111/tcp 1935/tcp 3310/tcp 4555/tcp 8006-8007/tcp 901/tcp 9050/tcp 1111/udp 1935/udp 3389/udp 4555/udp 111/udp 138/udp 137/udp 139/udp 1194/udp 67/udp 138/tcp 137/tcp 139/tcp 119/tcp 111/tcp 8080-8087/tcp 10143/tcp 10000/tcp 10993/tcp 10995/tcp 10587/tcp 10110/tcp 10465/tcp 10025/tcp protocols: forward: no masquerade: no forward-ports: port=8087:proto=tcp:toport=80:toaddr=192.168.10.50
Are you sure you really want this? It means that when some *internal* system makes a request to port 8087 with *any* destination address, it will be redirected to the 192.168.10.50. Apart from the fact that it will not work (for the same reason explained in another mail) I suspect that is not what you want. At least it is not what you described. If what you are saying is true, then it means that the firewall-config GUI does not provide any means to separate traffic intended for the gateway system (quasar, 192.168.10.100) from traffic intended to be forwarded on to some internet destination. My take on these forward-port rules is that they were meant to only apply to traffic being sent to the gateway computer itself.
port=143:proto=tcp:toport=10143:toaddr=
Ditto. It means that if some *internal* system makes a request to e.g. imap.gmail.com (ignore plain text for now) it will be redirected to port 10143 on imap.gmail.com. Do you think it will work?
port=993:proto=tcp:toport=10993:toaddr= port=995:proto=tcp:toport=10995:toaddr= port=587:proto=tcp:toport=10587:toaddr= port=110:proto=tcp:toport=10110:toaddr= port=465:proto=tcp:toport=10465:toaddr= port=25:proto=tcp:toport=10025:toaddr= source-ports: 10143/tcp
I am not sure what it really does. In the worst case it assigns every packet with source port 10143 to the zone "internal" which probably again is not what you want. My intention is to have traffic sent to these "standard" ports on the gateway computer is to forward that traffic to a different port on the gateway computer itself. I am running things like a mail server on the gateway computer itself, but it is listening on a non-standard port.
icmp-blocks: rich rules:
...
trusted (active) target: ACCEPT icmp-block-inversion: no interfaces: lo sources: services: apache2 apache2-ssl bacula-client dhcp dns http https imap imaps samba samba-client smtp smtps ports: 10143/tcp 10025/tcp 10465/tcp 10110/tcp 10587/tcp 10995/tcp 10993/tcp 10000/tcp protocols: forward: no masquerade: no forward-ports: port=143:proto=tcp:toport=10143:toaddr= port=993:proto=tcp:toport=10993:toaddr= port=995:proto=tcp:toport=10995:toaddr= port=587:proto=tcp:toport=10587:toaddr= port=110:proto=tcp:toport=10110:toaddr= source-ports: 10143/tcp icmp-blocks: rich rules:
Again I do not know whether this is what you really want or just leftover from some experiments. ... firewall-config GUI has two tabs "ports" and "source ports" I don't grok what the difference/purpose is between these two so was doing some experimenting. This is leftover stuff and I removed the entries from "source-ports". See my comment above about forward-ports also to see/understand my intentions/confusion.
firewall-cmd --list-all-policies quasar:/etc # firewall-cmd --list-all-policies allow-host-ipv6 (active) priority: -15000 target: CONTINUE ingress-zones: ANY egress-zones: HOST services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv6" icmp-type name="neighbour-advertisement" accept rule family="ipv6" icmp-type name="neighbour-solicitation" accept rule family="ipv6" icmp-type name="router-advertisement" accept rule family="ipv6" icmp-type name="redirect" accept
Well ... by default firewalld blocks forwarding between interfaces in different zones. This could be yet another reason for failure. You need policies allowing traffic between external and internal interfaces (in both directions).
Your question is not new and rich rules are probably the most simple solution.
https://forums.centos.org/viewtopic.php?t=71334
See also another idea in the post linked in this thread. OK, I will go and see if I can grok/use this info, thanks for the
Yeah, I am not sure where this came from either but I got rid of it. pointers, and I will get back to here soon with my results... Marc... -- *"The Truth is out there" - Spooky* *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed and the OpenPGP electronic signature is added as an attachment. If you know how, you can use my public key to prove this email indeed came from me and has not been modified in transit. My public key, which can be used for sending encrypted email to me also, can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand all this geek speak, no worries, just ignore this explanation and ignore the OpenPGP signature key attached to this email (it will look like gibberish if you open it) and/or ask me to explain it further if you like./)
On Thu, Nov 17, 2022 at 12:53 AM Marc Chamberlin <marc@marcchamberlin.com> wrote: ...
So you have two interfaces p3p1 and eth0, eth0 being your external interface. Additional addresses are not interfaces and you cannot use them where interfaces are expected. The names you see are just labels on these additional addresses. This doesn't really make sense to me, what it seems you are telling me is that firewalld cannon handle additional addresses assigned to a NIC card. If so, then that leaves me with 3 possible options and firewalld
No. What I'm saying is that you cannot bind a firewalld zone to the specific IP address on the system. You make a common fallacy of substituting "what needs to be done" with "how I believe it should be done" and when "how" turns out to be impossible assuming that "what" is impossible either.
is nearly useless. I can only set up iptable rules directly, I can possibly use rich rules instead, or I can go buy a switch, 4 cat5 cables
And why are rich rules bad? This is native firewalld configuration that does what you need.
and a NIC with 4 actual cat5 connectors. Since I could use the exact same hardware configuration with SuSEFirewall2 and iptable rules, that I currently have, I will look into doing everything via iptable rules instead. Sigh!
Whatever works for you. But I really do not grok why it was acceptable to effectively write equivalent of rich rules with SuSEFirewall2 but it is not acceptable to do the same with firewalld. ...
See my comment above, this renders firewalld nearly useless for me.
Well, as every software (and hardware) firewall was designed with some use cases in mind. Except your use case seems to be supported, just slightly differently. ... ...
forward-ports: port=8087:proto=tcp:toport=80:toaddr=192.168.10.50
Are you sure you really want this? It means that when some *internal* system makes a request to port 8087 with *any* destination address, it will be redirected to the 192.168.10.50. Apart from the fact that it will not work (for the same reason explained in another mail) I suspect that is not what you want. At least it is not what you described. If what you are saying is true, then it means that the firewall-config GUI does not provide any means to separate traffic intended for the gateway system (quasar, 192.168.10.100) from traffic intended to be forwarded on to some internet destination. My take on these forward-port rules is that they were meant to only apply to traffic being sent to the gateway computer itself.
Use rich rules. "forward-ports" is intended for simple use cases when everything coming into this zone needs to be forwarded. Firewalld is designed to separate traffic between zones, not inside zones. It is *firewall*d, not a generic packet mangling engine. ...
source-ports: 10143/tcp
I am not sure what it really does. In the worst case it assigns every packet with source port 10143 to the zone "internal" which probably again is not what you want.
OK, checking generated rules, "source-port" allows any packet *from* the specified port while "port" allows any packet *to* the specified port.
My intention is to have traffic sent to these "standard" ports on the gateway computer is to forward that traffic to a different port on the gateway computer itself. I am running things like a mail server on the gateway computer itself, but it is listening on a non-standard port.
Well, as you see it is not related to either destination port or to port forwarding.
participants (2)
-
Andrei Borzenkov -
Marc Chamberlin