Need help finding a website connectivity problem

PSX_Defector

@PSX_Defector said:

@Jason said:

@PSX_Defector said:

Drop the MTU from 1492 to 1484 then 1476. See if it works then.

That's what I was thinking.

The question is, do you know why?

I don't, but I'd like to. Why the "8" drops?

Time for class folks.

We know the site is up and running, as we can access it via other places. We know it's on Azure because of the trace. The trace tells us another interesting tidbit though. I'm wondering if anyone can see it.

PSX_Defector

@art_of_shred said:

@PSX_Defector said:

@Jason said:

@PSX_Defector said:

Drop the MTU from 1492 to 1484 then 1476. See if it works then.

That's what I was thinking.

The question is, do you know why?

I don't, but I'd like to. Why the "8" drops?

And the drop in 8's is because it's a base8 world. The MTU is the size of the packet in bytes. Odd byte numbers make for a bad time.

Which brings another item. Does anyone know why I went straight for MTU?

JaredBusch

It is PPPoE which impacts the MTU. but there is a firewall rule in place that has been there for a year and supposedly it was working, up until a week or so ago.

JaredBusch

@PSX_Defector said:

@art_of_shred said:

@PSX_Defector said:

@Jason said:

@PSX_Defector said:

Drop the MTU from 1492 to 1484 then 1476. See if it works then.

That's what I was thinking.

The question is, do you know why?

I don't, but I'd like to. Why the "8" drops?

And the drop in 8's is because it's a base8 world. The MTU is the size of the packet in bytes. Odd byte numbers make for a bad time.

Which brings another item. Does anyone know why I went straight for MTU?

I had this thread on the MTU subject 2 weeks ago.

http://mangolassi.it/topic/7118/a-little-confused-on-openvpn-mtu

I made no changes on the pppoe interface though. so I would not know why it would have been a cause (if it is).

I looked at a config backup from July and it is the same for pppoe being 1492

JaredBusch

@PSX_Defector said:

@art_of_shred said:

@PSX_Defector said:

@Jason said:

@PSX_Defector said:

Drop the MTU from 1492 to 1484 then 1476. See if it works then.

That's what I was thinking.

The question is, do you know why?

I don't, but I'd like to. Why the "8" drops?

And the drop in 8's is because it's a base8 world. The MTU is the size of the packet in bytes. Odd byte numbers make for a bad time.

Which brings another item. Does anyone know why I went straight for MTU?

Because it is DSL and DSL is generally PPPoE which takes up another 8 bytes?

JaredBusch

When you use the wizard to setup PPPoE on an ERL is automatically creates this firewall rule and applies it to the out of the PPPoE

modify PPPoE_OUT {
    description "TCP clamping"
    rule 1 {
        action modify
        modify {
            tcp-mss 1452
        }
        protocol tcp
        tcp {
            flags SYN
        }
    }
}

ethernet eth2 {
    description WAN
    duplex auto
    pppoe 0 {
        default-route auto
        firewall {
            in {
                name PPPoE_IN
            }
            local {
                name PPPoE_LOCAL
            }
            out {
                modify PPPoE_OUT
            }
        }
        mtu 1492
        name-server auto
        password 
        user-id 
    }
    speed auto
}

Jason

@PSX_Defector said:

@art_of_shred said:

@PSX_Defector said:

@Jason said:

@PSX_Defector said:

Drop the MTU from 1492 to 1484 then 1476. See if it works then.

That's what I was thinking.

The question is, do you know why?

I don't, but I'd like to. Why the "8" drops?

Time for class folks.

We know the site is up and running, as we can access it via other places. We know it's on Azure because of the trace. The trace tells us another interesting tidbit though. I'm wondering if anyone can see it.

my thought was it was odd that a hop inside the ISP network did not reply. Microsoft not replying is expected.

JaredBusch

@Jason said:

@PSX_Defector said:

@art_of_shred said:

@PSX_Defector said:

@Jason said:

@PSX_Defector said:

Drop the MTU from 1492 to 1484 then 1476. See if it works then.

That's what I was thinking.

The question is, do you know why?

I don't, but I'd like to. Why the "8" drops?

Time for class folks.

We know the site is up and running, as we can access it via other places. We know it's on Azure because of the trace. The trace tells us another interesting tidbit though. I'm wondering if anyone can see it.

my thought was it was odd that a hop inside the ISP network did not reply. Microsoft not replying is expected.

I was concerned about the 10.X.X.X showing in a trace. The site is on 10.204.10.0/24 and I have routes across VPN tunnels to 10.1.1.0/24, a few 10.204.X.0/24 and 10.254.103.0/24 as well.

But the site on the other end of that VPN tunnel also has all that and works fine.

JaredBusch

But bundystl.com is hosted on Azure and if you look at it directly (bundystl.azurewebsites.net), instead of via CloudFlare, it works just fine from on the client site.

it has the same trace results.
https://i.imgur.com/OX3y3Zs.jpg

JaredBusch

@PSX_Defector setting the MTU down to 1476 makes no difference in the pages loading.

PSX_Defector

@JaredBusch said:

@Jason said:

@PSX_Defector said:

@art_of_shred said:

@PSX_Defector said:

@Jason said:

@PSX_Defector said:

Drop the MTU from 1492 to 1484 then 1476. See if it works then.

That's what I was thinking.

The question is, do you know why?

I don't, but I'd like to. Why the "8" drops?

Time for class folks.

We know the site is up and running, as we can access it via other places. We know it's on Azure because of the trace. The trace tells us another interesting tidbit though. I'm wondering if anyone can see it.

my thought was it was odd that a hop inside the ISP network did not reply. Microsoft not replying is expected.

I was concerned about the 10.X.X.X showing in a trace. The site is on 10.204.10.0/24 and I have routes across VPN tunnels to 10.1.1.0/24, a few 10.204.X.0/24 and 10.254.103.0/24 as well.

But the site on the other end of that VPN tunnel also has all that and works fine.

Ahh, the plot thickens!

I thought it was strange that I couldn't get the same trace, but since you mention that, it makes more sense. The reason I say something about MTU is that I know there is sometimes fun when attempting to access certain sites if they are behind carrier NAT. Remember when SBC flipped over some PoPs to NAT for various stuff between BRAS and edge? I saw wacky routes, slow sites, all kinds of things. Most of it was because idiots were double NAT'ed. But on occasion, I would find a site that would not work without the MTU being 1500.

Now with the VPN tunnel tidbit, we need to make sure we are good. I thought it might have been a problem, but I didn't see it in your screenshots. The scope should be sufficiently small enough to not encompass any of the hops you are hitting. But I would double check that.

This is why I use 172.16.0.0/24 on my network at home. I never see funny shit like this.

JaredBusch

/wtb someone else on CenturyTel to test with.

JaredBusch

@PSX_Defector said:

@JaredBusch said:

@Jason said:

@PSX_Defector said:

@art_of_shred said:

@PSX_Defector said:

@Jason said:

@PSX_Defector said:

Drop the MTU from 1492 to 1484 then 1476. See if it works then.

That's what I was thinking.

The question is, do you know why?

I don't, but I'd like to. Why the "8" drops?

Time for class folks.

We know the site is up and running, as we can access it via other places. We know it's on Azure because of the trace. The trace tells us another interesting tidbit though. I'm wondering if anyone can see it.

my thought was it was odd that a hop inside the ISP network did not reply. Microsoft not replying is expected.

I was concerned about the 10.X.X.X showing in a trace. The site is on 10.204.10.0/24 and I have routes across VPN tunnels to 10.1.1.0/24, a few 10.204.X.0/24 and 10.254.103.0/24 as well.

But the site on the other end of that VPN tunnel also has all that and works fine.

Ahh, the plot thickens!

I thought it was strange that I couldn't get the same trace, but since you mention that, it makes more sense. The reason I say something about MTU is that I know there is sometimes fun when attempting to access certain sites if they are behind carrier NAT. Remember when SBC flipped over some PoPs to NAT for various stuff between BRAS and edge? I saw wacky routes, slow sites, all kinds of things. Most of it was because idiots were double NAT'ed. But on occasion, I would find a site that would not work without the MTU being 1500.

Now with the VPN tunnel tidbit, we need to make sure we are good. I thought it might have been a problem, but I didn't see it in your screenshots. The scope should be sufficiently small enough to not encompass any of the hops you are hitting. But I would double check that.

This is why I use 172.16.0.0/24 on my network at home. I never see funny shit like this.

let me revert the MTU and then shutdown some tunnels.

JaredBusch

dropbox.com doesn't load correctly.
https://i.imgur.com/RAqGgjZ.jpg

and I cannot get this page to load at all from the site: https://www.dropbox.com/s/uxcd517zt2y99ut/Smart Label Creator v1110 WIN.zip?dl=0

Scratch that, it finally loaded poorly.
https://i.imgur.com/52TpOKm.jpg

DustinB3403

@JaredBusch Does it load fine from your cell phone?

It seems like an ISP issue more than anything.

dafyre

Except his ERL can pull the site down... Could it be an odd case of double nat or something?

Does your site-to-site VPN send internet-bound traffic over the VPN or just ERL -> Internet?

hubtechagain

This post is deleted!

JaredBusch

honestly, I have no idea wtf is going on at this point.

dafyre

If you can curl the website from the ERL... then it is most likely doing something funky.

scottalanmiller

Any progress here? I don't have any ideas yet, but want to see what the resolution is.