Total Access 908 Second Gen - Limited Access to HTTPS sites

[mark19]

Good Afternoon.

I'm setting up a Total Access 908 Second Gen on a new T1 line, and appear to have either overestimated my own ability, or overestimated the helpfulness of my provider- or perhaps, a bit a both.

I was expecting to receive information such as timing, encoding, DLCI #, etc. All I've received to date is my IP address, default gateway, and subnet mask, and even then I has to ask for this data.

However, ESF, B8ZS, and ANSI appear to work, and Frame Relay was able to auto detect as ansi Annex D. This circuit is entirely data, which made this part much simpler.

Detect PVC got me a DLCI, and I was able to configure that with my IP address. FRF.12 entries are all set to 0. I setup the firewall (for NAT) and a default gateway, and I'm able to access most sites. In fact, I'm posting from this connection now.

I am unable to access most HTTPS sites- https://www.malwarebytes.org/ and www.bankofamerica.com are two examples. I am able to access this site, and https://www.google.com, so it's not all https sites. I'm also unable to connect my machines to my VPN.

In my security dashboard, I see the following that appear to correlate with my attempts to access the problematic sites-

3	TCP: expected SYN, got ACK	455	Today 10:29:11 PM	Today 11:00:13 PM	6
150	Connection with no data	162	Today 10:29:43 PM	Today 11:00:08 PM	2
6	Post connection SYN attack	14	Today 10:42:34 PM	Today 10:42:56 PM	7
1	TCP: expected SYN	10	Today 10:29:08 PM	Today 10:58:56 PM	6
9	Invalid seq # with RST	8	Today 10:36:43 PM	Today 10:39:02 PM	6
2	TCP: expected SYN only	2	Today 10:34:54 PM	Today 10:35:10 PM	7

I suspect I've misconfigured one or more settings, and these sites just happen to hit on the conditions where that misconfiguration matters- perhaps the frame is large enough that... and here we are definitely into the part where I don't know enough to complete that thought.

I'm certainly attempting to follow up with my service provider- but given my experience so far, I'm hoping someone more knowledgeable than me might suggest a setting that may cause similar symptoms.

[mark19 · Accepted solution]

Update: I was eventually able to contact someone at my service provider. They suggested trying to access speedtest.net, which was the first http site I was unable to access. Once they hear this, they "changed something on their end" and "ran a bunch of tests". I wasn't able to get a technical description of what they changed- just "something to help you reach sites". If there's anyone out there who might suggest what it is they changed, I hate not knowing. However, I seem to be able to route all traffic at this point.

[jayh]

My first guess would be an MTU setting. In today's networks, Ethernet frames of 1500 bytes are generally expected to pass end-to-end without fragmentation. If the maximum frame size is smaller, then ICMP messages tell the endpoints that the frame is too big and a smaller size is negotiated. If both a smaller-than normal MTU exists and a firewall filters the ICMP unreachable messages, you have a scenario where small packets such as traditional ping work, but web sites fail to load.

Google the acronym "PMTUD" (Path Maximun Transmission Unit Discovery) for more details.

As I'm not your service provider and I didn't run a test of MTU on your specific network, this is somewhat of a scientific wild-ass guess but it's most often the problem in cases as you described.

If you have a firewall setting that filters ICMP unreachables you're contributing to the problem but not the root cause of  it.