Date: Wed, 26 Sep 2001 09:22:10 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Flemming Jacobsen <fj@batmule.dk> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, freebsd-bugs@FreeBSD.ORG Subject: Re: misc/30255: [PATCH] Packets reinjected by natd but denied by ipfw generates annoying errors Message-ID: <20010926092210.A20611@sunbay.com> In-Reply-To: <200109251856.f8PIukg93964@prefect.unknown.dk>; from fj@batmule.dk on Tue, Sep 25, 2001 at 08:56:45PM %2B0200 References: <32094.1001439610@critter> <200109251856.f8PIukg93964@prefect.unknown.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 25, 2001 at 08:56:45PM +0200, Flemming Jacobsen wrote:
[...]
> My position is that the "natd[pid]: failed to write packet back
> (Permission denied)" message is utterly useless. Because:
> + It doesn't tell anything about what packet.
>
Unless you run natd(8) in verbose mode.
> + The FW author told ipfw to deny the packet, thus it stands
> to reason that all "interesting" denys would be logged by
> ipfw anyway.
>
It is usually caused by a default rule 65535 which is "deny ip
from any to any", and missing rules to allow for inbound traffic,
resulting in many questions on -questions asking why natd(8) is
not working. A good example is PR kern/30775.
> + It confuses people becauses it's not obvious why it is
> generated. To the general user it could be a resource problem
> or a configuration problem which caused unintended dropping
> of packets. I've gotten questions about this in the Danish
> BSD community a number of times, always followed by a "how do
> I turn it off" when I explain the reason.
> I think I've seen questions on freebsd-security as well.
>
: -verbose | -v
: Do not call daemon(3) on startup. Instead, stay attached to
: the controlling terminal and display all packet alterations
: to the standard output. This option should only be used for
: debugging purposes.
> As to the "misconfigured FW" argument, I can only say that I
> disagree.
> Writing FW rulesets is errorprone, and being able to write the
> rules in a way that follows your "view" of the net makes it
> easier to avoid mistakes.
> The FW for my personal DSL line is an example of this.
> I've got a /28 routed to the net connected to the Ethernet
> interface of the DSL router. Some of these addresses belong to
> jails on the FW, while others are NATed to IPs on the inside or
> DMZ interface.
> In order to group the rules per interface (that makes sense for
> me) I divert to natd early, and then use skipto's to the
> appropriate rule group. (Almost) all rules will use internal IPs
> which fits my wiew of the net.
> If I had to wait till after all denys before nat'ing I would
> end up having to duplicate many rules as I would have one for
> internal-internal traffic and one for external-internal traffic,
> plus keeping track of which natd to divert to where would be a
> nightmare.
>
May I have a look at your rules with comments? Perhaps in private.
> Another example is a FW at work with 5 interfaces some with
> RFC1918 IPs and some which use live IPs. If I didn't NAT
> early (to get the IPs in the packets to match the adresses of the
> boxes), I don't think I would be able to write a ruleset which
> would be able to work, because none of the segments trust the
> others completely.
>
And you use a single natd(8) process to service all 5 interfaces?
Again, I would like to see an example with comments, and an
example when this causes a EACCES from firewall which is
unavoidable.
I do have an example of a real firewall setup which I developed
a year ago, which I can post for demonstration purposes. This
firewall provides both "external" and "internal" policies.
Meanwhile, I'm going to commit the following patch. With it,
you can program your syslog.conf(5) to not log warning from
natd(8).
Index: natd.c
===================================================================
RCS file: /home/ncvs/src/sbin/natd/natd.c,v
retrieving revision 1.35
diff -u -p -r1.35 natd.c
--- natd.c 2001/06/21 12:32:36 1.35
+++ natd.c 2001/09/26 06:23:15
@@ -81,6 +81,7 @@ static void HandleRoutingInfo (int fd);
static void Usage (void);
static char* FormatPacket (struct ip*);
static void PrintPacket (struct ip*);
+static void Syslog(int, const char *);
static void SyslogPacket (struct ip*, int priority, const char *label);
static void SetAliasAddressFromIfName (const char *ifName);
static void InitiateShutdown (int);
@@ -813,14 +814,20 @@ SetAliasAddressFromIfName(const char *if
void Quit (const char* msg)
{
- Warn (msg);
+ Syslog (LOG_ERR, msg);
exit (1);
}
void Warn (const char* msg)
{
+ Syslog (LOG_WARNING, msg);
+}
+
+
+void Syslog (int level, const char* msg)
+{
if (background)
- syslog (LOG_ALERT, "%s (%m)", msg);
+ syslog (level, "%s (%m)", msg);
else
warn ("%s", msg);
}
Chees,
--
Ruslan Ermilov Oracle Developer/DBA,
ru@sunbay.com Sunbay Software AG,
ru@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010926092210.A20611>