RE: [cobalt-users] ICMP replies RaQ issues..

["Brian Watters" <brwatters@xxxxxxxxxxxxxxxxxxxx>]

Give us a call .. We are nationwide DSL provider .. 866-TBSINET .. Not a
plug but offer Biz class DSL and T-1 connectivity with IP space.

Brian

-----Original Message-----
From: cobalt-users-admin@xxxxxxxxxxxxxxx
[mailto:cobalt-users-admin@xxxxxxxxxxxxxxx] On Behalf Of E.B. Dreger
Sent: Thursday, April 11, 2002 10:38 PM
To: cobalt-users@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-users] ICMP replies RaQ issues..


> Date: Fri, 12 Apr 2002 06:36:54 +0200
> From: Benedict <j@xxxxxxxxxxx>

> I'm only writing down what someone from Cisco wrote me about the 827 
> router.

Eek.  I hope that nobody at Cisco wrote that ICMP ran over TCP. Not
saying they didn't... just that that would be very scary.


> > Second, running a RaQ over DSL and masquerading is going through a 
> > lot of pain for no real gain.  Why?  If you must use DSL, why not 
> > get the proper IP space, or at least bridge if you can only get one 
> > IP address.
> 
> That makes no sense either, it has never been a lot of pain for me, 
> furthermore, you have to realize how many companies don't have the 
> capitalist view you have, let alone can cough up the money for

Capitalist view?  How so?  And what has that to do with anything?


> "the proper IP-space". I maintain Qubes for people on a cable modem,

I can't speak for your area, but there are DSL providers (and I presume
cable) that have reasonable rates on IP space.  It might be a pain to
get them to understand what you need, but it's there... at least in some
areas.

If a /16 were free, and IP space were plentiful, you'd most likely use
it.  If a /29 were $1,000,000 per month, I'd use a single IP.  Somewhere
in between is the breakeven point... it's different for each person.


> RaQs for people using a dial-up, almost. It always works fine.
>  
> > Third, I doubt it's the wrong MTU being answered.  My suspicion is 
> > that ICMP type 3 is getting blocked, which breaks path MTU 
> > discovery.
> 
> Blocked by whom or what?

See below, toward end...


> > Path MTU discovery works by a machine sending out a packet with the 
> > DF (don't fragment) bit set... if it's larger than the MTU somewhere

> > along the line, you receive an ICMP unreachable with code 4, 
> > fragmentation needed but DF set.  Try it a few times, and whallah! 
> > the MTU is learned.
> 
> I've read this a thousand times already, it's everywhere on the net, 
> it doesn't help me one bit with the current problem.

Okay, cool.  Sorry to repost it, then.  Actually, it helps by giving a
clue where to look.

When did this begin?  When does it manifest itself?  i.e., what are the
patterns?


> > Your RaQ automagically handles this behind the scenes.  It's part of

> > the IP stack, and has _nothing_ to do with Apache.
> 
> Well, port 80 is the only one pointing to the machine,
> so the replies are going over that port as well,
> that's why I write "ICMP on port 80", hence Apache.

ICMP is a protocol separate from TCP.  ICMP does not travel over TCP.
(Thinking out loud:  Maybe Cisco bases port forwarding on TCP intercept.
Proxying a TCP session like that could yield the behavior that you
describe...)


> > Now the big question:  Where is ICMP going awry?  If ipchains 
> > doesn't have an erroneous rule to block all ICMP (well, at least 
> > type 3), then it's your router giving you grief.
> 
> OK, so how do I solve that?

Do you have any ICMP-related firewall rules, be they on RaQ or on
router?

>From or to your RaQ:

Does ping respond?  Can you run a Windows traceroute?  How about a Unix
traceroute?  What does tcpdump show?

If no ICMP-related firewall rules, then it might be time to send some
handcrafted packets to another system... variable size, DF set, and
watch what tcpdump does.


--
Eddy

Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots. Do NOT
send mail to <blacklist@xxxxxxxxx>, or you are likely to be blocked.

_______________________________________________
cobalt-users mailing list
cobalt-users@xxxxxxxxxxxxxxx
To Subscribe or Unsubscribe, please go to:
http://list.cobalt.com/mailman/listinfo/cobalt-users
---
[This E-mail scanned for viruses by Security Scan Operations Center]