netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* netfilter pecularities
@ 2011-03-25  9:03 cc
  0 siblings, 0 replies; 6+ messages in thread
From: cc @ 2011-03-25  9:03 UTC (permalink / raw)
  To: netfilter

Hi,

I have a netfilter-based firewall running and recently its behaviour
has been very puzzling (to the point of suspicious).  However, this
can also be attributed to user-error.

Please correct me if I'm wrong here.

I have a filter that forwards (via NAT prerouting) SMTP packets
to my e-mail server behind the firewall.  Here are the
following rules:

$IPT -t nat -A PREROUTING -p tcp -i $INET_IF -d $INET_IP \
           --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP
$IPT -t nat -A PREROUTING -p tcp -i $DMZ_IF -d $INET_IP \
           --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP

$IPT -t nat -A PREROUTING -p tcp -i $DMZ_IF -d $INET_IP \
            -s $LAN_NET --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP

These rules are the only one that has anything to do with
SMTP port forwarding and it doesn't include SNAT as it's
obvious from the rules.  If you can bear with me for a bit.

Now theoretically speaking, if I comment out the above lines,
NONE of the SMTP traffic will be going anywhere, am I correct?

My setup is this.  It's a 2.4.x based netfilter firewall.
(distribution is Slackware).

Now here's where I need a bit of clarification and/or
explanation.  What happens is the following.

If I comment out the aforementioned rules,  the SMTP traffic
still finds its way to the DMZ_EM machine.  (I'm a bit stumped here.)

If I reset the firewall by flushing the rules, the SMTP traffic
still finds its way to the DMZ_EM machine.  

When I run iptables, is it supposed to 'insmod' ip_tables, etc
to the modules list?  Even if it's compiled into the kernel?

Any clarifications appreciated.  

Ed




^ permalink raw reply	[flat|nested] 6+ messages in thread

* netfilter pecularities
@ 2011-03-25  9:05 cc
  2011-03-25 10:31 ` Pandu Poluan
  2011-03-25 18:02 ` Andrew Beverley
  0 siblings, 2 replies; 6+ messages in thread
From: cc @ 2011-03-25  9:05 UTC (permalink / raw)
  To: netfilter

Hi,

I have a netfilter-based firewall running and recently its behaviour
has been very puzzling (to the point of suspicious).  However, this
can also be attributed to user-error.

Please correct me if I'm wrong here.

I have a filter that forwards (via NAT prerouting) SMTP packets
to my e-mail server behind the firewall.  Here are the
following rules:

$IPT -t nat -A PREROUTING -p tcp -i $INET_IF -d $INET_IP \
           --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP
$IPT -t nat -A PREROUTING -p tcp -i $DMZ_IF -d $INET_IP \
           --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP

$IPT -t nat -A PREROUTING -p tcp -i $DMZ_IF -d $INET_IP \
            -s $LAN_NET --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP

These rules are the only one that has anything to do with
SMTP port forwarding and it doesn't include SNAT as it's
obvious from the rules.  If you can bear with me for a bit.

Now theoretically speaking, if I comment out the above lines,
NONE of the SMTP traffic will be going anywhere, am I correct?

My setup is this.  It's a 2.4.x based netfilter firewall.
(distribution is Slackware).

Now here's where I need a bit of clarification and/or
explanation.  What happens is the following.

If I comment out the aforementioned rules,  the SMTP traffic
still finds its way to the DMZ_EM machine.  (I'm a bit stumped here.)

If I reset the firewall by flushing the rules, the SMTP traffic
still finds its way to the DMZ_EM machine.  

When I run iptables, is it supposed to 'insmod' ip_tables, etc
to the modules list?  Even if it's compiled into the kernel?

Any clarifications appreciated.  

Ed




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: netfilter pecularities
  2011-03-25  9:05 cc
@ 2011-03-25 10:31 ` Pandu Poluan
  2011-03-25 10:37   ` Jan Engelhardt
  2011-03-25 18:02 ` Andrew Beverley
  1 sibling, 1 reply; 6+ messages in thread
From: Pandu Poluan @ 2011-03-25 10:31 UTC (permalink / raw)
  To: cc; +Cc: netfilter

On Fri, Mar 25, 2011 at 16:05, cc <cc@kdtc.net> wrote:
> Hi,
>
> I have a netfilter-based firewall running and recently its behaviour
> has been very puzzling (to the point of suspicious).  However, this
> can also be attributed to user-error.
>
> Please correct me if I'm wrong here.
>
> I have a filter that forwards (via NAT prerouting) SMTP packets
> to my e-mail server behind the firewall.  Here are the
> following rules:
>
> $IPT -t nat -A PREROUTING -p tcp -i $INET_IF -d $INET_IP \
>           --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP
> $IPT -t nat -A PREROUTING -p tcp -i $DMZ_IF -d $INET_IP \
>           --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP
>
> $IPT -t nat -A PREROUTING -p tcp -i $DMZ_IF -d $INET_IP \
>            -s $LAN_NET --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP
>
> These rules are the only one that has anything to do with
> SMTP port forwarding and it doesn't include SNAT as it's
> obvious from the rules.  If you can bear with me for a bit.
>
> Now theoretically speaking, if I comment out the above lines,
> NONE of the SMTP traffic will be going anywhere, am I correct?
>

SMTP traffic from LAN to DMZ should not be affected.

> My setup is this.  It's a 2.4.x based netfilter firewall.
> (distribution is Slackware).
>
> Now here's where I need a bit of clarification and/or
> explanation.  What happens is the following.
>
> If I comment out the aforementioned rules,  the SMTP traffic
> still finds its way to the DMZ_EM machine.  (I'm a bit stumped here.)
>
> If I reset the firewall by flushing the rules, the SMTP traffic
> still finds its way to the DMZ_EM machine.
>

From INET or from LAN?

> When I run iptables, is it supposed to 'insmod' ip_tables, etc
> to the modules list?  Even if it's compiled into the kernel?
>

I don't think so. IMO if the modules are compiled into the kernel,
iptables will not load them.

But I'm not a developer, though. I *could* be wrong.

> Any clarifications appreciated.
>
> Ed
>

Rgds,
--
Pandu E Poluan
~ IT Optimizer ~
Visit my Blog: http://pepoluan.posterous.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: netfilter pecularities
  2011-03-25 10:31 ` Pandu Poluan
@ 2011-03-25 10:37   ` Jan Engelhardt
  2011-03-25 16:33     ` Pandu Poluan
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Engelhardt @ 2011-03-25 10:37 UTC (permalink / raw)
  To: Pandu Poluan; +Cc: cc, netfilter


On Friday 2011-03-25 11:31, Pandu Poluan wrote:
>
>> When I run iptables, is it supposed to 'insmod' ip_tables, etc
>> to the modules list?  Even if it's compiled into the kernel?
>>
>
>I don't think so. IMO if the modules are compiled into the kernel,
>iptables will not load them.
>
>But I'm not a developer, though. I *could* be wrong.

If the module is compiled in, the functionality is already available,
thus trying to use the functionality does not fail and iptables
won't attempt to modprobe.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: netfilter pecularities
  2011-03-25 10:37   ` Jan Engelhardt
@ 2011-03-25 16:33     ` Pandu Poluan
  0 siblings, 0 replies; 6+ messages in thread
From: Pandu Poluan @ 2011-03-25 16:33 UTC (permalink / raw)
  To: Jan Engelhardt, cc, netfilter

Ahh, so that's how exactly iptables decided to modprobe or not.

Thanks for the explanation Jan :)

Rgds,


On 2011-03-25, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Friday 2011-03-25 11:31, Pandu Poluan wrote:
>>
>>> When I run iptables, is it supposed to 'insmod' ip_tables, etc
>>> to the modules list?  Even if it's compiled into the kernel?
>>>
>>
>>I don't think so. IMO if the modules are compiled into the kernel,
>>iptables will not load them.
>>
>>But I'm not a developer, though. I *could* be wrong.
>
> If the module is compiled in, the functionality is already available,
> thus trying to use the functionality does not fail and iptables
> won't attempt to modprobe.
>


-- 
--
Pandu E Poluan - IT Optimizer
My website: http://pandu.poluan.info/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: netfilter pecularities
  2011-03-25  9:05 cc
  2011-03-25 10:31 ` Pandu Poluan
@ 2011-03-25 18:02 ` Andrew Beverley
  1 sibling, 0 replies; 6+ messages in thread
From: Andrew Beverley @ 2011-03-25 18:02 UTC (permalink / raw)
  To: cc; +Cc: netfilter

On Fri, 2011-03-25 at 17:05 +0800, cc wrote:
> I have a filter that forwards (via NAT prerouting) SMTP packets
> to my e-mail server behind the firewall.  Here are the
> following rules:
> 
> $IPT -t nat -A PREROUTING -p tcp -i $INET_IF -d $INET_IP \
>            --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP
> $IPT -t nat -A PREROUTING -p tcp -i $DMZ_IF -d $INET_IP \
>            --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP
> 
> $IPT -t nat -A PREROUTING -p tcp -i $DMZ_IF -d $INET_IP \
>             -s $LAN_NET --dport $SMTP -j DNAT --to $DMZ_EM:$SMTP
> 
> These rules are the only one that has anything to do with
> SMTP port forwarding and it doesn't include SNAT as it's
> obvious from the rules.  If you can bear with me for a bit.
> 
> Now theoretically speaking, if I comment out the above lines,
> NONE of the SMTP traffic will be going anywhere, am I correct?

Well it depends if you've got any other routing set up. Are you sure
that the clients are using the firewall's IP address, and not the IP
address of DMZ_EM? If they are using the latter, and you have ip_forward
enabled, then the packets can be forwarded with no involvement of
iptables.

It would be worth changing the target of the above rules to LOG to see
if the packets are matching them.

Andy



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-03-25 18:02 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-25  9:03 netfilter pecularities cc
  -- strict thread matches above, loose matches on Subject: below --
2011-03-25  9:05 cc
2011-03-25 10:31 ` Pandu Poluan
2011-03-25 10:37   ` Jan Engelhardt
2011-03-25 16:33     ` Pandu Poluan
2011-03-25 18:02 ` Andrew Beverley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).