I may have had a problem similar to this.  We had PIX's installed and
when we migrated to Nokia boxes we started having MTU problems with
NetBIOS traffic.  The problem for us was that the PIX has a default
command that doesn't show up on a wr term that changes the TCP Maximum
Segment Size to 1380 (without you knowing it)

<snip from cisco>
sysopt connection tcpmss 1380

Set the TCP maximum segment size to 1380 bytes. This is recommended for
data over the encrypted VPN channel. This value is set by default but
does not display in the default configuration. It does not need to be
specified in a configuration.
</end snip>

In our case we were blocking ICMP packet too big error messages, thus
creating a Path MTU black hole.  However the PIX was fixing this without
us knowing it.

If this is similar to your problem then the best thing is to ensure
that the ICMP error messages are not being blocked, as a quick
alternative you may insert a route-map that sets the DF bit to 0
(clearing it).

For us, this seemed like a Nokia issue, but turned out to be our own
problem, with the PIX hiding the symptoms.

Mitchell


--
http://www.attackprevention.com/
http://www.securestandard.com/



>>> [EMAIL PROTECTED] 12/08/03 05:43AM >>>
We have been suffering an issue to do with Checkpoint, Cisco GRE
tunnels
and MTU size for a number of months now, and I thought it might be
worth
posting a description of our problem on this list in case someone is
able
to help.  We feel that we have exhausted most avenues of trying to
troubleshoot this issue.

What we are trying to do is route Internet traffic for remote branch
office
sites via our central office's Internet connection.  As an example, we
have
a 2Mb AT&T Internet connection in our Paris office, connected to a
15Mb
AT&T Internet connection in London.  We run a Cisco GRE tunnel between
a
3640-VPN/MP router in Paris and a 7206VXR/G1 router in London.  In
London,
we also have a Nokia IP530 appliance running a fresh install of Check
Point
NG:AI, connected to a 10Mb PSINet Internet connection.

The Cisco GRE tunnel has a MTU size of 1420 set at both ends for it's
tunnel interfaces.  This is the highest we can use based on the
encryption/encapsulation chosen in order to facilitate protocols such
as
OSPF from working over the link.  All other interfaces along the way
(router ethernets and Nokia interfaces) are set the default 1500.

The problem is that users in the Paris branch office are unable to
view
_some_ websites.  Examples of ones that don't work are www.yahoo.fr
and
www.adp.fr.  The majority work fine, including www.cisco.com and
www.google.com.

When running a tcpdump on the IP530 in London (on the external
interface),
during a session from Paris to one of the offending websites, the
following
is logged:

16:36:21.025051 O 154.38.47.5 > 194.3.182.10: icmp: 154.38.47.5
unreachable
- need to frag (mtu 1420)
16:36:27.586541 I 194.3.182.10.80 > 154.38.47.5.41571: . 1:1461(1460)
ack
249 win 63992 (DF)
16:36:27.588356 O 154.38.47.5 > 194.3.182.10: icmp: 154.38.47.5
unreachable
- need to frag (mtu 1420)
16:36:40.711277 I 194.3.182.10.80 > 154.38.47.5.41571: . 1:1461(1460)
ack
249 win 63992 (DF)
16:36:40.713043 O 154.38.47.5 > 194.3.182.10: icmp: 154.38.47.5
unreachable
- need to frag (mtu 1420)

We have also noticed that the packet size of traffic received from
offending sites seems to be 1514 bytes.  For sites that work, i.e.
cisco.com, it seems to be 1486 bytes.

We have tried lots of things on the GRE tunnel configuration on our
Cisco
routers, including settings to ignore the Don't Fragment (DF) bit, and
to
force different MTU sizes.  A long-running Cisco TAC case has not
suggested
any way around our problem.

Can anyone explain the cause of this problem, and suggest anything that
can
be done on our Nokia/Check Point configuration to prevent this
occurring?
Out of interest, when we route the Internet traffic past the Nokia
IP530
firewall and onto an Internet connection at another downstream site,
which
uses a Cisco PIX firewall instead, the remote Paris users ARE able to
browse the offending websites successfully.  This indicates that it
must be
something to do with the Nokia/Check Point installation.

Any comments or suggestions would be greatly received.

Thanks,
Marcel




NOTICE:
The contents of this email and any attachments to it may contain privileged and 
confidential information from BDO Seidman, LLP.  This information is only for the 
viewing or use of the intended recipient.  If you are not the intended recipient, you 
are hereby notified that any disclosure, copying, distribution or use of, or the 
taking of any action in reliance upon, the information contained in this e-mail, or 
any of the attachments to this e-mail, is strictly prohibited and that this e-mail and 
all of the attachments to this e-mail, if any, must be immediately returned to BDO 
Seidman, LLP or destroyed and, in either case, this e-mail and all attachments to this 
e-mail must be immediately deleted from your computer without making any copies 
thereof.  If you have received this e-mail in error, please notify BDO Seidman, LLP by 
e-mail immediately.

=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to [EMAIL PROTECTED]
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
[EMAIL PROTECTED]
=================================================

Reply via email to