Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Anders Fugmann <afu@fugmann.dhs.org>
To: mike-netfilter@tiedyenetworks.com
Cc: netfilter@lists.netfilter.org
Subject: Re: BUG(?) - SNAT causes networking to stop.
Date: Thu, 31 Oct 2002 23:35:03 +0100	[thread overview]
Message-ID: <3DC1B017.1060700@fugmann.dhs.org> (raw)
In-Reply-To: Pine.LNX.4.44.0210311202110.21650-100000@robotron.office.tiedyenetworks.com

mike-netfilter@tiedyenetworks.com wrote:
> Howdy folks,
> 
> 	I've got a router I am experamenting with SNAT on.  I've hit a 
> situation where local ping processes are forced to stop transmitting (get 
By local ping process, I guess you mean processes which are started on 
the firewall itself.
> caught in a loop on sendmsg() ) until the box receives packets from some 
> external source (ping it from another machine on the network for example), 
> and then it wakes right up without missing a beat. Experamentally, I've 
> had ping waiting for several minutes this way. Typically it's able to fire 
> off say 10 packets (and get replies) before it starts hanging. Using 
> larger packets - say, 3000 bytes, results in only being able to fire off 3 
> before stopping. I'm running tcpdump to verify that it's not emitting 
> packets and strace to verify it's stuck looping on sendmsg(). Very weird.
Can you internet connection really handle packets this big? How are you 
connected to the internet? What happens if you use a smaller packet size 
(e.g. 64 byte)
> 
> 	I think it's netfilter related because I can reset netfilter to 
> zero rules (allow everything) and the problem goes away. Then I can run my 
> netfilter script and the problem returns. The rule set I'm working 
> with provides snat for the 8 /24 networks that will connect to this 
> router, and provides each network with it's own seperate 'outgoing 
> ip address' (for accounting and management conveience). Here's my nat 
> table after my script sets it up:
> 
> 
> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
>    86  4936 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0          
> 
> Chain POSTROUTING (policy ACCEPT 39 packets, 28092 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
>     0     0 SNAT       all  --  *      eth0    192.168.1.0/24       0.0.0.0/0          to:a.b.c.1 
>     0     0 SNAT       all  --  *      eth0    192.168.2.0/24       0.0.0.0/0          to:a.b.c.2 
>     0     0 SNAT       all  --  *      eth0    192.168.3.0/24       0.0.0.0/0          to:a.b.c.3 
>     0     0 SNAT       all  --  *      eth0    192.168.4.0/24       0.0.0.0/0          to:a.b.c.4 
>     1    84 SNAT       all  --  *      eth0    192.168.5.0/24       0.0.0.0/0          to:a.b.c.5 
>     0     0 SNAT       all  --  *      eth0    192.168.6.0/24       0.0.0.0/0          to:a.b.c.6 
>     0     0 SNAT       all  --  *      eth0    192.168.7.0/24       0.0.0.0/0          to:a.b.c.7 
>     0     0 SNAT       all  --  *      eth0    192.168.8.0/24       0.0.0.0/0          to:a.b.c.8 
> 
> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
>    39 28092 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0          
> 
> Chain logndrop (0 references)
>  pkts bytes target     prot opt in     out     source               destination         
>     0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 
>     0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0          

No packets generated on the machine itself would ever hit any of the 
SNAT rules, so I guess that the SNAT rules are not the problem, but 
maybe some rules in the INPUT or OUTPUT chains in the filter table.
could you post how these rules are inserted (stating the actual iptables 
commands.)


Regards
Anders Fugmann

--
Author of FIAIF
FIAIF is an intelligent Firewall
http://fiaif.fugmann.dhs.org



  reply	other threads:[~2002-10-31 22:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-31 20:04 BUG(?) - SNAT causes networking to stop mike-netfilter
2002-10-31 22:35 ` Anders Fugmann [this message]
2002-10-31 22:37 ` Darrell Dieringer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DC1B017.1060700@fugmann.dhs.org \
    --to=afu@fugmann.dhs.org \
    --cc=mike-netfilter@tiedyenetworks.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox