655794 - Can't connect to build.mozilla.org from the Toronto office (also, and much less importantly, can't connect to build.mozilla.org when VPNed in to MV office VPN)

Status: RESOLVED FIXED

(Infrastructure & Operations :: RelOps: General, task)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Bug 626122 regressed recently -- sometime in the past few days, I think.  I'm filing this as a clone of that bug instead of reopening since I suspect you'd prefer it that way.

+++ This bug was initially created as a clone of Bug #626122 +++

When I connect to the mountain view office VPN from home (with the "Use this connection only for resources on its network" option in my VPN configuration), I'm unable to connect to http://build.mozilla.org/ .  Being unable to connect to build.mozilla.org means that http://tbpl.mozilla.org/ won't load.  I've heard reports of the same thing (can't load TBPL over office VPN) from other people.

When I connect to the office VPN, the DNS result I get for build.mozilla.org changes from what I get when unconnected:
$ host build.mozilla.org
build.mozilla.org is an alias for dm-wwwbuild01.mozilla.org.
dm-wwwbuild01.mozilla.org has address 63.245.208.186

to what I get when I'm inside the office:
$ host build.mozilla.org
build.mozilla.org has address 10.2.74.128
build.mozilla.org mail is handled by 10 dm-mail01.mozilla.org.
build.mozilla.org mail is handled by 10 dm-mail02.mozilla.org.

However, when I "Use this connection only for resources on its network", 10.2.74.128 isn't considered a resource on the network at the other end of the VPN, so I can't connect.

(If I uncheck "Use this connection only for resources on its network" and send *all* my traffic through the VPN, then it works, but I'd rather not have to do that...)

Comment 1

[Ravi Pina [:ravi]]

Amy has been doing much DNS juggling to get things clean.  This also sounds like a tie in with bug 604688.

In the mean time I suggest you implement your work around.

Assigning to the correct group.

Comment 2

[Amy Rich [:arr] [:arich]]

I think Ravi is correct in that the problem here is the coupling of the hostname and the service.  Adding dependency.

Comment 4

[Dave Miller [:justdave]]

inheriting blocker status from the duped bug.

Comment 5

[Zandr Milewski [:zandr]]

Taking this one, will need netops involvement.

Comment 6

[(no longer active)]

Any ETA on the fix, please?

Comment 7

[Ravi Pina [:ravi]]

No ETA.

Is the work around not working for you?

Comment 8

[(no longer active)]

I have no idea how to use this workaround.  Would you please advise?

Comment 9

[(no longer active)]

Again, to make things more clear, this is blocking our work from the office.  I'm considering working from home tomorrow if this is not fixed by then.

Comment 10

[Zandr Milewski [:zandr]]

We've traced this to a failure in the VPN tunnel between Toronto and Mountain View. The Toronto office should now be working.

We are now looking in to the VPN route issue that dbaron reported, which we believe to be entirely separate.

Comment 11

[Zandr Milewski [:zandr]]

The route has been restored on the VPN concentrator.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

The workaround doesn't apply to the Toronto office, because the people there can't disable the VPN.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Gah, sorry - didn't read all my bugmail before replying - ignore my comment!