[lug] Weird mail/firewall problem

[rm at fabula.de]

On Tue, Feb 12, 2002 at 09:42:37PM -0700, D. Stimits wrote:
> Chip Atkinson wrote:
> > 
> > Interesting.  Very interesting indeed.  I did have the value of
> > ip_always_defrag set to 0.  Why does it have that value I wonder?
> > Wouldn't you aways want your packets to be defragmented?
> 
> Only if you are the final destination, or can guarantee that the
> defragmented size will not exceed your internal network MTU. In which
> case it would simply refragment it.

Hmm, that's by itself wouldn't be a big problem. Defragmenttion _can_ be
used for certain DOS attackssince the kernel needs to keep the state of
forwarded packets (i.e. collect all fragments and reasemble them):
 
> > 
> > I suspect that the only reason that you would want to not defragment would
> > be if every machine was on a lan and the packet size was the same between
> > machines.
> 
> If it is on an internal lan then likely it can handle putting it back
> together and not fragmenting it internally. Your MTU default of 1500
> works quite well on a lan, but if you were retransmitting or routing or
> doing something along the Internet over a 56k modem, that'd probably be
> a problem.
> 
> FYI, if you try to send at greater than the route MTU and have checked
> the do not fragment flag, you'll lose all your packets. Perhaps the
> email program is flagging packets as "do not fragment", then using a
> value larger than the route can handle. 


I don't think an application can set 'do-not-fragment' ;-) This is up
to the kernel. And, no, you wouldn't loose all packets, the kernel would
receive ICMP messages about to large packets (see my recent posting) and
reduce the packet size. This is exactly the scenario in which ICMP _is_
helpfull.
 
 
> Just for kicks, maybe get your
> failed email test on an interface, then use ifconfig to set to something
> small on the interface itself, say 296 (power of 2 plus 40 assuming tcp
> header), and see if it then gets through. Or maybe some other error
> occurs.

That's a good diagnosis technique, indeed. Hmm, just to throw it in: 
you can also use 'tracepath':

|  www:/home/ralf# tracepath www.zeit.de/80
|  1?: [LOCALHOST]      pmtu 1500
|  1?: 212.18.192.129   
|  2?: 212.18.192.22    
|  3?: 212.88.129.142   
|  4?: 213.248.68.101   
|  5?: 193.45.9.81      
|  6?: 213.248.68.90    
|  7?: 80.81.192.190    asymm  8 
|  8?: 212.38.193.205   
|  9?: 212.38.192.189   asymm  7 
| 10?: 212.38.221.33    asymm  6 
| 11?: 212.38.221.102   asymm  8 
| 12?: 194.64.3.101     asymm  9 
| 13?: 194.64.3.45      asymm  8 
| 14?: 194.163.251.75   asymm  9 
| 15:  194.163.254.175  asymm 10  23ms reached
|      Resume: pmtu 1500 hops 15 back 10 
| 

Same test from my firewall (attached to a DSL line):

| barrique:/home/moep# tracepath www.zeit.de/80
|  1?: [LOCALHOST]      pmtu 1492
|  1?: 217.5.98.41      asymm  5 
|  2?: 217.237.153.42   
|  3?: 62.154.18.46     asymm  8 
|  4?: 194.64.3.30      asymm  8 
|  5?: 195.180.3.209    asymm  8 
|  6?: 194.163.251.75   asymm  8 
|  7:  194.163.254.175  asymm  8 162ms reached
|      Resume: pmtu 1492 hops 7 back 8 
|  

another debuging tool would be 'hping'.

  Ralf

> D. Stimits, stimits at idcomm.com

> 
> PS: I'm no network guru, I expect someone should or could make arguments
> to what I said.
> 
> > 
> > Any thoughts on that?
> > 
> > BTW, it looks like your suggestion worked perfectly.  I don't see the
> > denial messages any more.
> > 
> > Chip
> > 
> >  On Tue, 12 Feb 2002, Kevin Fenzi wrote:
> > 
> > > >>>>> "Chip" == Chip Atkinson <chip at rmpg.org> writes:
> > >
> > > Chip> ... snip...
> > >
> > > Chip> In my messages file I'm seeing entries like this:
> > >
> > > Chip> Feb 12 19:05:28 poodle kernel: Packet log: input DENY ppp0
> > > Chip> PROTO=6 24.254.60.38:65535 63.173.117.115:65535 L=492 S=0x00
> > > Chip> I=7422 F=0x2042 T=245 (#12)
> > >
> > > Chip> ... snipp...
> > >
> > > Chip> Huh?  It seems that the email timeouts are related to these
> > > Chip> denied packets.  The weird thing is that the port is 65535, not
> > > Chip> 25.
> > >
> > > Chip> I see these denial messages scrolling by almost as fast as the
> > > Chip> messages in the maillog.
> > >
> > > Chip> I'm a bit puzzled and don't want to open up myself
> > > Chip> unnecessarily, but it slmost seems that I'm blocking mail
> > > Chip> throughput.
> > >
> > > The trick here is that port 65535 doesn't exist... it's just ipchains
> > > way of telling you that it denied a Fragmented packet...
> > >
> > > I seem to remember ipchains having some problems with fragmented
> > > packets from some places. Don't recall why...
> > >
> > > You can "fix" it with:
> > >
> > > echo 1 > /proc/sys/net/ipv4/ip_always_defrag
> > >
> > > which will make it always defrag the packets and should make it work.
> > >
> > > Chip> Thanks in advance.
> > > Chip> Chip
> > >
> > > kevin
> > >
> > 
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug