* BUG(?) - SNAT causes networking to stop.
@ 2002-10-31 20:04 mike-netfilter
2002-10-31 22:35 ` Anders Fugmann
2002-10-31 22:37 ` Darrell Dieringer
0 siblings, 2 replies; 3+ messages in thread
From: mike-netfilter @ 2002-10-31 20:04 UTC (permalink / raw)
To: netfilter
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
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.
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
I'm running 2.4.19 with iptables 1.2.7a. If it helps, I'm also
running with these modules loaded:
Module Size Used by
ipt_state 576 1
ipt_LOG 3376 2
iptable_nat 13936 1
ip_conntrack 13872 2 [ipt_state iptable_nat]
tulip 37360 4
e100 64560 4
pcnet32 13280 1
mii 1088 0 [pcnet32]
iptable_filter 1680 1 (autoclean)
ip_tables 10880 6 [ipt_state ipt_LOG iptable_nat iptable_filter]
Can anyone suggest the next thing to look at?
Thanks.
--
TieDye Networks - peace, love, and fast downloads!
Zoinks, scoob! Haunted flying saucers!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BUG(?) - SNAT causes networking to stop.
2002-10-31 20:04 BUG(?) - SNAT causes networking to stop mike-netfilter
@ 2002-10-31 22:35 ` Anders Fugmann
2002-10-31 22:37 ` Darrell Dieringer
1 sibling, 0 replies; 3+ messages in thread
From: Anders Fugmann @ 2002-10-31 22:35 UTC (permalink / raw)
To: mike-netfilter; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: BUG(?) - SNAT causes networking to stop.
2002-10-31 20:04 BUG(?) - SNAT causes networking to stop mike-netfilter
2002-10-31 22:35 ` Anders Fugmann
@ 2002-10-31 22:37 ` Darrell Dieringer
1 sibling, 0 replies; 3+ messages in thread
From: Darrell Dieringer @ 2002-10-31 22:37 UTC (permalink / raw)
To: mike-netfilter, netfilter
I had a goofy problem quite awhile ago that sounds a lot like yours -
I couldn't ping the router box from the LAN unless the router box was
already pinging the particular LAN box from which I was trying to ping
the router.
I didn't use strace, but tcpdump showed me that the packets were
indeed _not_ on the wire.
After banging my head for awhile, I tried a different (identical)
network card in the router for the LAN. The unusual ping problem was
gone immediately without a single change to the firewall rules.
It's worth a shot.
Darrell Dieringer - Madison, WI
> -----Original Message-----
>
> 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
> 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.
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-10-31 22:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-31 20:04 BUG(?) - SNAT causes networking to stop mike-netfilter
2002-10-31 22:35 ` Anders Fugmann
2002-10-31 22:37 ` Darrell Dieringer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox