SuSEfirewall2: strange problem with router/firewall running OpenSuSE 13.1

English Network/Internet
1

After running SuSEfirewall2 on a brain old SuSE 9.2 machine for many years I thought I’ll give it a try for my new firewall using OpenSuSE 13.1 on a freshly installed VM with two network interfaces:

ens32 - 192.168.1.4 = internal
ens34 - 195.58.174.124 = directly connected to the internet

The firewall machine itself is running ssh which should be reachable for everyone.

On the internal network for testing two machines are running:

192.168.1.24 - apache2 on 80+443; this Apache should be reachable (port forward) for everyone
192.168.1.133 - Windows client, only for surfing, no servers

My SuSEfirewall2-settings:

FW_DEV_EXT=“ens34”
FW_DEV_INT=“ens32”
FW_ROUTE=“yes”
FW_MASQUERADE=“yes”
FW_MASQ_DEV=“ens34”
FW_MASQ_NETS=“192.168.1.0/24”
FW_SERVICES_EXT_TCP=“80 443 ssh”
FW_SERVICES_INT_TCP=“80 443 ssh”
FW_TRUSTED_NETS=“192.168.1.0/24” (also tried “”)
FW_FORWARD_MASQ=“0.0.0.0/0,192.168.1.24,tcp,80,80,195.58.174.124”
FW_ALLOW_FW_SOURCEQUENCH=“yes” (also tried no)
All logging to YES

What’s working:

  • I can reach ssh no matter from where (inside, outside) and which IP (192.168.1.24, 195.58.174.124…) I’m using
  • I can reach the web server when using the external IP 195.58.174.124 from an external machine
  • I can reach every external IP/name from the internal machine

But only one thing does NOT work:

  • if I try to reach the external IP 195.58.174.124 from an INTERNAL machine I get:
    telnet 195.58.174.124 80
    Trying 195.58.174.124…
    telnet: connect to address 195.58.174.124: Connection refused

and the firewall log only shows:

kernel: [23611.147397] SFW2-INint-ACC-ALL IN=ens32 OUT= MAC=00:…:00 SRC=192.168.1.24 DST=195.58.174.124 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=18534 DF PROTO=TCP SPT=33135 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0996B4E50000000001030307)

I don’t like the “OUT=” but am not sure if that is that the problem…

I tried to vary lots of the SuSEfirewall2-settings, change the generated iptables-statements (I must confess I’m not a iptables-guru) and so - nothing, although already spending lots of hours.

Anyone any ideas? Thanks a lot!!!

Markus

PS: nmap from an internal machine shows (shortened):

nmap 195.58.174.124
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh

nmap 192.168.1.4
Not shown: 989 closed ports
PORT STATE SERVICE
22/tcp open ssh

From an external machine:

nmap 195.58.174.124
(The 1660 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp closed https - of course, no masq rule until now

2

Post your iptables-save command output, please:

Code:

/sbin/iptables-save

and also iptables -nvL for some current runtime info:

Code:

/sbin/iptables -nvL

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

3

Hi,

thank you for your reply. The output is too large for the forum software but I put it on the web server of the test installation :-):

http://195.58.174.124/iptablessave.txt
http://195.58.174.124/iptablesnvl.txt

4

Is Apache httpd configured to listen on the internal address?

Code:

sudo /usr/sbin/ss -planeto | grep 80
grep -iR listen /etc/apache2/*

Actually, looking at this a bit more, I’m guessing the problem is that you
have Apache httpd configured to listen ONLY on the Internal IP address,
right? I see you are using some prerouting to forward from the external
address TCP 80 to the internal address TCP 80. Why wouldn’t this work?
Because your prerouting rule is only working on the external interface,
and your traffic from your internal box is probably not hitting that
external interface.

But, you ask, how could the data get to the box with the external IP
address if not via the external interface?

Well, Linux is really smart, and it knows that data destined for one its
interfaces, even if it shows up on another interface (which seems to be
likely in your case if this box is used as a router or something, meaning
all traffic goes through it). As a result, a firewall rule that
explicitly has restrictions on an interface will not match the traffic you
specified, even though the machine gets that traffic and handles it
properly otherwise.

Likely simple solution: Configure Apache httpd to listen on all
interfaces, not just the internal one.

Another option: Configure iptables to NOT do its IP redirection with any
bearing on interfaces.

I’d go with the httpd fix first, personally.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

5

Again, thank you for your help - but that wasn’t really the point:

  • no, the web server (192.168.1.24) listens to all addresses (for testing…)
  • but that reminded me that on the local firewall there’s also an apache running but bound to the internal IP; to be sure I changed it to listen only to 8080 instead of 80 - but no changes. :frowning:

Regarding:

Which rule(s) must I change (I’m not the great iptables expert as mentioned before… (:slight_smile: - this one?

iptables -A PREROUTING -j DNAT -t nat -p tcp -s 0/0 -d 195.58.174.124 --dport 80 --to-destination 192.168.1.24:80 -i ens34

I tried it without “-i ens34”, no I get timeouts when accessing port 80 (instead of immediate “Connection refused”).

Thank you!

Markus

PS: what I’m also irritated: the SAME configuration of SuSEfirewall2 (with different IPs of course) has been work real fine on the old SuSE 9.2 for many years…

6

On 02/17/2014 07:36 AM, mschwaig wrote:
>
> Again, thank you for your help - but that wasn’t really the point:
>
> * no, the web server (192.168.1.24) listens to all addresses (for
> testing…)
> * but that reminded me that on the local firewall there’s also an apache
> running but bound to the internal IP; to be sure I changed it to listen
> only to 8080 instead of 80 - but no changes. :frowning:
>
> Regarding:
>
> ab;2625322 Wrote:
>>
>> Another option: Configure iptables to NOT do its IP redirection with any
>> bearing on interfaces.
>
> Which rule(s) must I change (I’m not the great iptables expert as
> mentioned before… (:slight_smile: - this one?
>
>
> Code:
> --------------------
> iptables -A PREROUTING -j DNAT -t nat -p tcp -s 0/0 -d 195.58.174.124 --dport 80 --to-destination 192.168.1.24:80 -i ens34
> --------------------

Did you delete the previous rule first?

I’d probably do this whole thing by removing the entry you have for
FW_FORWARD_MASQ since if Apache is listening on all addresses and your
virtual hosts (if applicable) do not care, then it should all work since
you already allow TCP 80 to connect and Apache listens on both interfaces.

Wait, no, I think I just found a problem. From your original post:

ens32 - 192.168.1.4 = internal
ens34 - 195.58.174.124 = directly connected to the internet

also from your original post:

FW_FORWARD_MASQ=“0.0.0.0/0,192.168.1.24,tcp,80,80,195.58.174.124”

You have different IPs in there… 1.24 instead of 1.4.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

7

The web server is on a different machine!!! From the original post:

Firewall:
ens32 - 192.168.1.4 = internal
ens34 - 195.58.174.124 = directly connected to the internet

On the internal network for testing two machines are running:
192.168.1.24 - apache2 on 80+443; this Apache should be reachable (port forward) for everyone
192.168.1.133 - Windows client, only for surfing, no servers

Markus

8

Oh good.

In that case, perhaps try to clear out the FW_MASQ_DEV line since that
seems like the place from which the iptables line is being built with a
specific device. If you do this and restart the firewall
(/sbin/rcSuSEfirewall2 restart) then maybe that will help. If not, post
the same output as before and let’s see what else looks amiss.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

9

Is that problem solved?

Christian

10

No, not really - changed the firewall to PFSense.