SuSEfirewall2 port redirecting

English Network/Internet
1

Greetings, folks!

It’s about a month i’m having a great sex with inherited server, based on openSUSE 10.3
No, no, don’t envy, just join!

Here is the story:

Internet
|
|
Firewall(here it is!) — mail,www server (192.168.2.15)
|
|
LAN (192.168.1.0/24)

So, i’m having a server (gateway, proxy, firewall, call it whatever you like), three network interfaces in it, connected to Internet (fixed IP), DMZ (mail and web server there), and internal Local Area Network.
The problem is following:
I can’t get access to the mail and web from internal network! Requests from Internet are perfectly redirecting to DMZ, but from LAN i can reach mail or web only by specifying internal IP-address of DMZ-server!

After three weeks of probing different ways, now i have no idea, what can be wrong with firewall settings. Please help me, if you can, and show me the right way!

FW_DEV_EXT=“any eth1”
FW_DEV_INT=“eth0”
FW_DEV_DMZ=“eth2”
FW_ROUTE=“yes”
FW_MASQUERADE=“yes”
FW_MASQ_DEV=“zone:ext”

giving LAN access to Internet mail

FW_MASQ_NETS=“192.168.1.0/24,0/0,udp,domain 192.168.1.0/24,0/0,tcp,domain 192.168.1.0/24,0/0,tcp,pop3 192.168.1.0/24,0/0,tcp,smtp 192.168.1.0/24,0/0,icmp 192.168.2.15,0/0,udp,domain 192.168.2.15,0/0,tcp,domain 192.168.2.15,0/0,icmp”
FW_NOMASQ_NETS=""
FW_PROTECT_FROM_INT=“no”
FW_SERVICES_EXT_TCP=“ssh”
FW_SERVICES_DMZ_TCP=“domain”
FW_SERVICES_DMZ_UDP=“domain”
FW_SERVICES_INT_TCP=“3128 domain ssh”
FW_SERVICES_INT_UDP=“domain”
FW_SERVICES_DROP_EXT=""
FW_SERVICES_REJECT_EXT=“0/0,tcp,113”
FW_SERVICES_ACCEPT_EXT=“0/0,tcp,ssh”

LAN access to DNS and proxy on gateway

FW_TRUSTED_NETS=“192.168.1.0/24,udp,domain 192.168.1.0/24,tcp,domain 192.168.1.0/24,tcp,ssh 192.168.1.0/24,tcp,3128”
FW_ALLOW_INCOMING_HIGHPORTS_TCP=“no”
FW_ALLOW_INCOMING_HIGHPORTS_UDP=“no”

here is the problem! forwarding isn’t working!

FW_FORWARD=“192.168.1.0/24,192.168.2.15,tcp,993 192.168.1.0/24,192.168.2.15,tcp,80 192.168.1.0/24,192.168.2.15,tcp,443 $EXT_IP,192.168.2.15,tcp,993”
FW_FORWARD_REJECT=""
FW_FORWARD_DROP=""

External requests from Internet are working great (first four rules)

FW_FORWARD_MASQ=“0/0,192.168.2.15,tcp,993 0/0,192.168.2.15,tcp,25 0/0,192.168.2.15,tcp,80 0/0,192.168.2.15,tcp,443 192.168.1.0/24,192.168.2.15,tcp,993 192.168.1.0/24,192.168.2.15,tcp,80 192.168.1.0/24,192.168.2.15,tcp,443 $EXT_IP,192.168.2.15,tcp,993”
FW_REDIRECT=""

According to tcpdump, it looks like requests from 192.168.1.0/24 are addressed to $EXT_IP, and Gateway-server are trying to serve’em. But there is no web or mail daemons running on it! So… “Connection refused”!

2

IIRC, firewalls are usually used to protect your LAN from the WAN, so computers on the LAN itself are probably not firewalled at all. Besides, you say you can reach the DMZ by IP number, which probably rules out firewall problems. What I would concentrate on is detecting/disabling any additional software firewalls that may be running on your servers/clients and that you forgot to disable, and particularly a potential name resolution misconfiguration. What service/daemon are you using on your server for resolving names, and are the corresponding client daemons running and configured properly on your client machines?
But then again, I’m just a hobbyist in these things…:slight_smile:

3

It’s not THAT simple unfortunately…
Disabling all other firewalls was my first step.
Name resolution is working fine both in LAN and on mail-server.
I’ll repeat once again:
Surfing to and getting mail from server in DMZ are working from outside world (over Internet).
Mail from outside is delivering to mail-server by smtp.
Internet access through proxy on gateway is works too.
Browsing to 192.168.2.15 from LAN is working. Not working browsing to DOMAIN from LAN. DOMAIN (external name of web-server) is resolving as firewall’s external ip, but request isn’t redirecting to web-server, as it happening when it comes from Internet.
Any ideas?

4

noone can help?

5

Based on what you’re describing,
I believe you need to configure what is called a “split DNS”

You’re describing a problem I’ve seen intermittently with different devices, when resolution to an internal (or DMZ) resource for everyone (both internal and external) points to the external interface then external traffic works fine but internal traffic has to kind of “wrap back” (sorry, I can’t think of a better description). Internal traffic often can’t originate from the LAN zone, point to the external interface of the multi-homed bastion, then reverse course to the DMZ or internal resource.

The solution then is if your traffic originates in the LAN, the path of your packets should travel directly to the resource and not touch the external firewall.

Look up “split DNS” - In a nutshell, it means simply that you configure both your internal DNS and your public DNS to be authoritative for the same public domain but with a different set of records. Naturally, at the moment you don’t have any problems with traffic which originates from the WAN so your public records can be left alone but your internal DNS will contain the LAN IP addresses of your DMZ or LAN resources (not the public address(es)).

Not trying to be confusing, but you can also think of this as intentionally “poisoning” your domain records to direct traffic properly.:wink:

6

Thanx, pal!

It was really brilliant idea to make DNS-Server to response to LAN that DOMAIN have an INT_IP!

What have i made:

  1. added to named.conf

zone “DOMAIN” in {
allow-transfer { localnets; };
file “master/DOMAIN”;
type master;
};
zone “2.168.192.in-addr.arpa” in {
allow-transfer { localnets; };
file “master/2.168.192.zone”;
type master;
};

  1. created at /var/named/master files
    DOMAIN:
    $TTL 2D
    @ IN SOA server.DOMAIN. root.DOMAIN. (
    2008120711 ; serial
    3H ; refresh
    1H ; retry
    1W ; expiry
    1D ) ; minimum
    IN NS localhost.

DOMAIN. IN A 192.168.2.15

  •           IN CNAME        DOMAIN.

2.168.192.zone:
$TTL 2D
@ IN SOA server.DOMAIN. root.DOMAIN. (
2008120701 ; serial
3H ; refresh
1H ; retry
1W ; expiry
1D ) ; minimum
IN NS localhost.

15 IN PTR DOMAIN.

  1. restarted named
    Now everything is working perfectly!