Strange behaviour with SSL pages on Wired Country

[Tony Paterson]

Hi,

I think this falls into the category of technical ;-)

We have recently got a Wired Country connection with ICONZ - 2MB flat rate account ($160 a month)

Among othe things we are running an internal knowledgebase web application, and Microsoft Outlook Web Access. Whenever either of these do a non-trivial POST of data the browser just hangs. Typically this will be a form on a web page where you have TEXTAREA and INPUT tags - such as composing an email message in Outlook Web Access. I have only tested this behaviour with IE, but if it doesn't work in IE then it's no go - and before you ask I do use FireFox as my default browser.

We have both the Wired Country connection and a full rate Xtra JetStream account here in Auckland - both with static IPs. Connected to the Wired Country connection is a D-Link router which in turn has NAT through to our SSL web server.

This is how it pans out

- Laptop connected to the WAN side of D-Link everything works
- Connecting from our JetStream connection it fails
- Connecting from home Maxnet JetStarter it WORKS
- Dialup to Xtra it WORKS
- JetStream full rate in Wellington it fails
- Unknown connection type in Sydney it fails
- Unknown connection type in Melbourne it fails


So it seems rather strange that it works only on some types of connections. Anyone seem anything vaguely like this or got any ideas.

Cheers

Yours Tony P

[Dan Langille]

Post by Tony Paterson
Among othe things we are running an internal knowledgebase web
application, and Microsoft Outlook Web Access. Whenever either of these
do a non-trivial POST of data the browser just hangs. Typically this
will be a form on a web page where you have TEXTAREA and INPUT tags -
such as composing an email message in Outlook Web Access. I have only
tested this behaviour with IE, but if it doesn't work in IE then it's no
go - and before you ask I do use FireFox as my default browser.

Anything on the web server logs? Does the data ever get to the web
server?

[Craig Whitmore]

Post by Tony Paterson
I think this falls into the category of technical ;-)
We have recently got a Wired Country connection with ICONZ - 2MB flat rate
account ($160 a month)
We have both the Wired Country connection and a full rate Xtra JetStream
account here in Auckland - both with static IPs. Connected to the Wired
Country connection is a D-Link router which in turn has NAT through to our
SSL web server.

Most likely to do with MTU and fragmentation (and someone blocking off ICMP
to/from the server)

Are you blocking off all ICMP from/to the server?

Thanks
Craig

[Tony Paterson]

If you wait long enough the browser comes back with "Cannot find server or DNS Error"

I will email Dan the log off-list.

Thanks

Tony P


-----Original Message-----
From: Dan Langille [mailto:***@langille.org]
Sent: Wednesday, 8 September 2004 1:50 p.m.
To: Tony Paterson
Cc: Mailing List ADSL (E-mail)
Subject: Re: Strange behaviour with SSL pages on Wired Country

Post by Tony Paterson
Among othe things we are running an internal knowledgebase web
application, and Microsoft Outlook Web Access. Whenever either of these
do a non-trivial POST of data the browser just hangs. Typically this
will be a form on a web page where you have TEXTAREA and INPUT tags -
such as composing an email message in Outlook Web Access. I have only
tested this behaviour with IE, but if it doesn't work in IE then it's no
go - and before you ask I do use FireFox as my default browser.

Anything on the web server logs? Does the data ever get to the web
server?

[Brian Gibbons]

Post by Tony Paterson
- Laptop connected to the WAN side of D-Link everything works
- Connecting from our JetStream connection it fails
- Connecting from home Maxnet JetStarter it WORKS
- JetStream full rate in Wellington it fails

As Craig says this is most likely and MTU issue (with Wired Country?).

You can prove this quickly by dropping the MTU on your Web server's network
card to something like 1400, if that fixes it forget it (we have been here
before).


Cheers

BG

[LEE Tet Yoon]

Post by Brian Gibbons

Post by Tony Paterson
- Laptop connected to the WAN side of D-Link everything works
- Connecting from our JetStream connection it fails
- Connecting from home Maxnet JetStarter it WORKS
- JetStream full rate in Wellington it fails

As Craig says this is most likely and MTU issue (with Wired Country?).
You can prove this quickly by dropping the MTU on your Web server's network
card to something like 1400, if that fixes it forget it (we have been here
before).

Most Wired Country ISPs use PPPoE for authentication. I'm pretty sure the max MTU
for PPPoE is lower then 1500 due to the PPP overhead or some such. A quick search
reveals it's probably 1480 altho a more thorough search is probably in order.

Hope this helps...

P.S. Tony, it's technical, doesn't really appear to be ADSL related but I'll let that slide...

[LEE Tet Yoon]

Post by LEE Tet Yoon
Most Wired Country ISPs use PPPoE for authentication. I'm pretty sure the max MTU
for PPPoE is lower then 1500 due to the PPP overhead or some such. A quick search
reveals it's probably 1480 altho a more thorough search is probably in order.
Hope this helps...

Should add there are ways to try to test the real max MTU. Easiest is probably
to ping and change the packet size and also tell it not to fragment. You have
to subtract a certain amount from the packet (28 I think but check) due to
overhead... I think Microsoft has instructions for Windows but it's quite easy
once you have the general idea.

[Stephen Judd]

We didn't hear back from Tony whether indiscriminate ICMP blocking was
the problem (although I bet it was).

Here's something I picked up on another list today, from the very clever

http://www.wand.net.nz/scamper/
given an IP address, scamper will do a traceroute towards it to
establish
the forward path and an address at the end of the network that will
terminate probes. then it will try ICMP based PMTUD starting with the
interface's MTU size.
If it does not get a response, it tries smaller packet sizes until it
has
inferred the largest packet that will get some response from the path.
Then it does a TTL limited search to infer the hop[s] possibly
responsible for not sending an ICMP Fragmentation Required message.
It
marks the mtu annotations for the hop[s] with an asterisk.
traceroute from 199.109.33.1 to XXX
1 199.109.33.254 0.744 ms [mtu: 4470]
2 XXX 14.041 ms [mtu: 4470]
3 XXX 26.454 ms [mtu: 4470]
4 XXX 22.627 ms [mtu: 4470]
5 XXX 35.079 ms [mtu: 4470]
6 XXX 38.690 ms [mtu: 4470]
7 XXX 47.683 ms [mtu: 4470]
8 XXX 59.337 ms [mtu: 4470]
9 XXX 63.797 ms [mtu: 4470]
10 XXX 61.082 ms [*mtu: 1514]
11 XXX 60.909 ms [mtu: 1500]
12 XXX 61.541 ms [mtu: 1500]
Note that the path between hop 9 and 10 probably has a L2 disagreement
on
the media's MTU size as the hop will happily generate other ICMP
types.
./scamper -4mi <IP addresses> is the basic usage of scamper for this
purpose.

--
Stephen Judd
***@vital.org.nz
http://vital.org.nz

[Philip D'Ath]

I don't know what kind of device you are using, but if it is a Cisco
device, add the following line on the Ethernet0 interface.

ip tcp adjust-mss 1452

This causes the router to intercept all the TCP syn packets, and reset
the MSS from 1500 to 1452, which gets around the problem of some https
sites with block ICMP destination unreachable messages, and hence
preventing MTU path discovery.

You could also use a utility like DrTCP (free download), and change your
machines Ethernet MTU to 1452 to resolve the issue.


If you have a Cisco device, you can find lots of info on our WWW site
at:
http://www.ifm.net.nz/cookbooks/

-----Original Message-----
From: owner-***@unixathome.org [mailto:owner-***@unixathome.org] On
Behalf Of LEE Tet Yoon
Sent: Wednesday, 8 September 2004 7:28 p.m.
To: ***@lists.unixathome.org
Subject: Re: Strange behaviour with SSL pages on Wired Country

Post by LEE Tet Yoon
Most Wired Country ISPs use PPPoE for authentication. I'm pretty sure
the max MTU for PPPoE is lower then 1500 due to the PPP overhead or
some such. A quick search reveals it's probably 1480 altho a more

thorough search is probably in order.

Post by LEE Tet Yoon
Hope this helps...

Should add there are ways to try to test the real max MTU. Easiest is
probably to ping and change the packet size and also tell it not to
fragment. You have to subtract a certain amount from the packet (28 I
think but check) due to overhead... I think Microsoft has instructions
for Windows but it's quite easy once you have the general idea.
--
This message is part of the NZ ADSL mailing list.
see http://unixathome.org/adsl/ for archives, FAQ,
and various documents.
To unsubscribe: send mail to ***@lists.unixathome.org
with "unsubscribe adsl" in the body of the message

[Tony Paterson]

Stephen,

As far as I know it is not ICMP blocking as I have not intentionally blocked this and I have checked and it doesn't seem to be blocked. Also you can ping the router www.salestechglobal.com

This is still a big problem for me with Wired Country and I will be posting on this shortly.

Thanks for your help

-----Original Message-----
From: owner-***@unixathome.org [mailto:owner-***@unixathome.org]On
Behalf Of Stephen Judd
Sent: Monday, 13 September 2004 8:19 p.m.
To: ***@lists.unixathome.org
Subject: Re: Strange behaviour with SSL pages on Wired Country


We didn't hear back from Tony whether indiscriminate ICMP blocking was
the problem (although I bet it was).

Here's something I picked up on another list today, from the very clever

http://www.wand.net.nz/scamper/
given an IP address, scamper will do a traceroute towards it to
establish
the forward path and an address at the end of the network that will
terminate probes. then it will try ICMP based PMTUD starting with the
interface's MTU size.
If it does not get a response, it tries smaller packet sizes until it
has
inferred the largest packet that will get some response from the path.
Then it does a TTL limited search to infer the hop[s] possibly
responsible for not sending an ICMP Fragmentation Required message.
It
marks the mtu annotations for the hop[s] with an asterisk.
traceroute from 199.109.33.1 to XXX
1 199.109.33.254 0.744 ms [mtu: 4470]
2 XXX 14.041 ms [mtu: 4470]
3 XXX 26.454 ms [mtu: 4470]
4 XXX 22.627 ms [mtu: 4470]
5 XXX 35.079 ms [mtu: 4470]
6 XXX 38.690 ms [mtu: 4470]
7 XXX 47.683 ms [mtu: 4470]
8 XXX 59.337 ms [mtu: 4470]
9 XXX 63.797 ms [mtu: 4470]
10 XXX 61.082 ms [*mtu: 1514]
11 XXX 60.909 ms [mtu: 1500]
12 XXX 61.541 ms [mtu: 1500]
Note that the path between hop 9 and 10 probably has a L2 disagreement
on
the media's MTU size as the hop will happily generate other ICMP
types.
./scamper -4mi <IP addresses> is the basic usage of scamper for this
purpose.

--
Stephen Judd
***@vital.org.nz
http://vital.org.nz
--
This message is part of the NZ ADSL mailing list.
see http://unixathome.org/adsl/ for archives, FAQ,
and various documents.
To unsubscribe: send mail to ***@lists.unixathome.org
with "unsubscribe adsl" in the body of the message