Closed Bug 1083535 Opened 10 years ago Closed 10 years ago

no response from DNS server after connecting to Mozilla VPN

Categories

(Infrastructure & Operations :: Corporate VPN: Support requests, task)

Product:
Infrastructure & Operations
Component:
Corporate VPN: Support requests
Platform:
x86_64
Linux
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: dbaron, Assigned: dparsons)

Details

I followed the instructions at https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=30769829 to set up access to the Mozilla VPN using NetworkManager.

When I connect, I'm unable to access anything that's Mozilla-related because connections to the DNS server for internal sites time out.  (I'm still able to access non-Mozilla stuff because the VPN restricts the use of its DNS server to certain hostname and address ranges.)

In particular, when I connect, I see this in syslog:

Oct 15 22:34:00 crum NetworkManager[856]: <info> Starting VPN service 'openvpn'...
Oct 15 22:34:00 crum NetworkManager[856]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 20834
Oct 15 22:34:00 crum NetworkManager[856]: <info> VPN service 'openvpn' appeared; activating connections
Oct 15 22:34:00 crum NetworkManager[856]: <info> VPN plugin state changed: init (1)
Oct 15 22:34:01 crum NetworkManager[856]: <info> VPN plugin state changed: starting (3)
Oct 15 22:34:01 crum NetworkManager[856]: <info> VPN connection 'Mozilla Datacenter (only Mozilla connections)' (Connect) reply received.
Oct 15 22:34:01 crum nm-openvpn[20840]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Feb  4 2014
Oct 15 22:34:01 crum nm-openvpn[20840]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 15 22:34:01 crum nm-openvpn[20840]: Control Channel Authentication: using '/home/dbaron/c/mozilla/DC-vpn/dbaron-ovpn-config/ta.key' as a OpenVPN static key file
Oct 15 22:34:01 crum nm-openvpn[20840]: UDPv4 link local: [undef]
Oct 15 22:34:01 crum nm-openvpn[20840]: UDPv4 link remote: [AF_INET]63.245.214.137:1194
Oct 15 22:34:01 crum nm-openvpn[20840]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1558'
Oct 15 22:34:01 crum nm-openvpn[20840]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Oct 15 22:34:01 crum nm-openvpn[20840]: [openvpn.scl3.mozilla.com] Peer Connection Initiated with [AF_INET]63.245.214.137:1194
Oct 15 22:34:03 crum nm-openvpn[20840]: TUN/TAP device tun0 opened
Oct 15 22:34:03 crum nm-openvpn[20840]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1557 10.22.248.122 10.22.248.121 init
Oct 15 22:34:03 crum NetworkManager[856]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
Oct 15 22:34:03 crum NetworkManager[856]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
Oct 15 22:34:03 crum NetworkManager[856]: <warn> /sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...
Oct 15 22:34:03 crum NetworkManager[856]: <info> VPN connection 'Mozilla Datacenter (only Mozilla connections)' (IP Config Get) reply received.
Oct 15 22:34:03 crum NetworkManager[856]: <info> VPN connection 'Mozilla Datacenter (only Mozilla connections)' (IP4 Config Get) reply received.
Oct 15 22:34:03 crum NetworkManager[856]: <info> VPN Gateway: 63.245.214.137
Oct 15 22:34:03 crum NetworkManager[856]: <info> Tunnel Device: tun0
Oct 15 22:34:03 crum NetworkManager[856]: <info> IPv4 configuration:
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Internal Gateway: 10.22.248.121
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Internal Address: 10.22.248.122
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Internal Prefix: 32
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Internal Point-to-Point Address: 10.22.248.121
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Maximum Segment Size (MSS): 0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.22.248.1/32   Next Hop: 10.22.248.1
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.10.0.0/16   Next Hop: 10.10.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.110.0.0/16   Next Hop: 10.110.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.128.0.0/16   Next Hop: 10.128.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.130.0.0/16   Next Hop: 10.130.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.132.0.0/16   Next Hop: 10.132.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.134.0.0/16   Next Hop: 10.134.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.14.0.0/16   Next Hop: 10.14.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.150.0.0/16   Next Hop: 10.150.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.152.0.0/16   Next Hop: 10.152.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.16.0.0/16   Next Hop: 10.16.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.18.0.0/16   Next Hop: 10.18.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.2.0.0/16   Next Hop: 10.2.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.20.0.0/16   Next Hop: 10.20.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.21.0.0/16   Next Hop: 10.21.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.22.0.0/16   Next Hop: 10.22.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.224.0.0/16   Next Hop: 10.224.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.24.0.0/16   Next Hop: 10.24.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.253.0.0/24   Next Hop: 10.253.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.26.0.0/16   Next Hop: 10.26.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.30.0.0/16   Next Hop: 10.30.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.32.0.0/16   Next Hop: 10.32.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.34.0.0/15   Next Hop: 10.34.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 10.8.0.0/16   Next Hop: 10.8.0.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 223.202.6.0/27   Next Hop: 223.202.6.0
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.215.245/32   Next Hop: 63.245.215.245
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.215.254/32   Next Hop: 63.245.215.254
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.215.58/32   Next Hop: 63.245.215.58
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.215.73/32   Next Hop: 63.245.215.73
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.215.94/32   Next Hop: 63.245.215.94
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.217.202/31   Next Hop: 63.245.217.202
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.217.204/32   Next Hop: 63.245.217.204
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.217.210/32   Next Hop: 63.245.217.210
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.217.213/32   Next Hop: 63.245.217.213
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.217.214/31   Next Hop: 63.245.217.214
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.217.216/31   Next Hop: 63.245.217.216
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.217.218/32   Next Hop: 63.245.217.218
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.217.47/32   Next Hop: 63.245.217.47
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Static Route: 63.245.223.14/32   Next Hop: 63.245.223.14
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Forbid Default Route: yes
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Internal DNS: 10.22.75.40
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Internal DNS: 10.22.75.41
Oct 15 22:34:03 crum NetworkManager[856]: <info>   DNS Domain: 'mozilla.com'
Oct 15 22:34:03 crum NetworkManager[856]: <info> No IPv6 configuration
Oct 15 22:34:03 crum nm-openvpn[20840]: Initialization Sequence Completed
Oct 15 22:34:04 crum NetworkManager[856]: <info> VPN connection 'Mozilla Datacenter (only Mozilla connections)' (IP Config Get) complete.
Oct 15 22:34:04 crum NetworkManager[856]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
Oct 15 22:34:04 crum NetworkManager[856]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv6 routing and DNS.
Oct 15 22:34:04 crum NetworkManager[856]: <info> Writing DNS information to /sbin/resolvconf
Oct 15 22:34:04 crum dnsmasq[3035]: setting upstream servers from DBus
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.41#53 for domain 63.in-addr.arpa
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.41#53 for domain 6.202.223.in-addr.arpa
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.41#53 for domain 10.in-addr.arpa
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.41#53 for domain mozilla.org
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.41#53 for domain build.mozilla.org
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.41#53 for domain mozilla.com
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.40#53 for domain 63.in-addr.arpa
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.40#53 for domain 6.202.223.in-addr.arpa
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.40#53 for domain 10.in-addr.arpa
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.40#53 for domain mozilla.org
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.40#53 for domain build.mozilla.org
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.22.75.40#53 for domain mozilla.com
Oct 15 22:34:04 crum dnsmasq[3035]: using nameserver 10.251.75.5#53
Oct 15 22:34:04 crum NetworkManager[856]: <info> VPN plugin state changed: started (4)


But then I can't reach the DNS servers (and I confirmed with mpoessy that he sees the same DNS servers) that are supposed to be used for internal lookups:

$ host www.w3.org
www.w3.org has address 128.30.52.37
www.w3.org mail is handled by 2 lisa.w3.org.
$ host www.mozilla.org
;; connection timed out; no servers could be reached
$ host www.mozilla.org 10.251.75.5
Using domain server:
Name: 10.251.75.5
Address: 10.251.75.5#53
Aliases: 

www.mozilla.org is an alias for mozorg.dynect.mozilla.net.
mozorg.dynect.mozilla.net has address 63.245.217.105
mozorg.dynect.mozilla.net has IPv6 address 2620:101:8008:5::2:1
$ host www.mozilla.org 10.22.75.40
;; connection timed out; no servers could be reached
$ host www.mozilla.org 10.22.75.41
;; connection timed out; no servers could be reached


Could this be some sort of ACL issue?
(Oh, and the reason I'm trying to do this is that I want to access https://people.mozilla.org/~klahnakoski/modevmetrics/ ; I recently learned that the reason those haven't been working for me for a year or two (I thought they were just broken) was that they now require VPN access.)
I notice 10.251.75.5 comes up in your log as a DNS server. This is not a valid DNS server, and it is not handed out by our VPN server... this is something your VPN client is coming up with on its own. 10.251.75.5 is actually an admin server in sfo1. 

If you send your DNS queries to 10.22.75.40, everything should work OK. Can you give that a try?
Assignee: vpn-support → dparsons
(In reply to Dan Parsons [:lerxst] from comment #2)
> I notice 10.251.75.5 comes up in your log as a DNS server. This is not a
> valid DNS server, and it is not handed out by our VPN server... this is
> something your VPN client is coming up with on its own. 10.251.75.5 is
> actually an admin server in sfo1. 

No, 10.251.75.5 is a perfectly fine DNS server, and it's the DNS server I get from DHCP in the SFO office with no VPN connection.  Without VPN, it's my only DNS server, and everything works fine.  Thus when the VPN is used and gives its own DNS server for some addresses, I'm still using that server for all the others.

> If you send your DNS queries to 10.22.75.40, everything should work OK. Can
> you give that a try?

Doesn't work; see shell output in comment 0.
It appears like you are using NetworkManager for the VPN connection. This tool has many known bugs, mostly around the configuration import/parsing. https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=30769829#MozillaVPN%28DatacenterVPN%29-LinuxNetworkManagerPlugin:ManualConfiguration has screenshots with what each settings dialogue should look like.

I think particularly you have two issues: 

1) it's not updating your DNS server to the one provided by the VPN (probably missing resolvconf package)
2) it's missing the "Use this connection only for resources on its network" checkbox.

Combined, these two issues would result in DNS queries failing. It is possible there are some other issues, so it's best to compare all the screenshots in that mana page to your config to make sure everything is correct. In theory the 10.251.75.5 name servers will work while in the office, but when remote, you'll want the vpn-provided name server.

It's pushing it in your log output:
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Internal DNS: 10.22.75.40
Oct 15 22:34:03 crum NetworkManager[856]: <info>   Internal DNS: 10.22.75.41

However, I believe the resolvconf package is required for NetworkManager to actually utilize it.

Note: Some maintenance will be happening soon to change those DNS servers for VPN users, so if when you next connect, you get different ones, that is expected.

Hope this helps.
(In reply to Justin Dow [:jabba] from comment #4)
> I think particularly you have two issues: 
> 
> 1) it's not updating your DNS server to the one provided by the VPN
> (probably missing resolvconf package)

No, it is updating it, but I can't connect to the DNS server provided by the VPN, as pointed out at the end of comment 0 (see the various "host" commands).

Is there some sort of ACL issue that would prevent me from conecting to it when I'm connected to the VPN?

For what it's worth, the routing table when I'm connected to the VPN looks like this:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.251.24.1     0.0.0.0         UG    0      0        0 eth0
10.2.0.0        10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.8.0.0        10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.10.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.14.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.16.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.18.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.20.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.21.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.22.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.22.248.1     10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
10.22.248.33    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.24.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.26.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.30.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.32.0.0       10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.34.0.0       10.22.248.33    255.254.0.0     UG    0      0        0 tun0
10.110.0.0      10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.128.0.0      10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.130.0.0      10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.132.0.0      10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.134.0.0      10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.150.0.0      10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.152.0.0      10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.224.0.0      10.22.248.33    255.255.0.0     UG    0      0        0 tun0
10.251.24.0     0.0.0.0         255.255.248.0   U     1      0        0 eth0
10.253.0.0      10.22.248.33    255.255.255.0   UG    0      0        0 tun0
63.245.214.137  10.251.24.1     255.255.255.255 UGH   0      0        0 eth0
63.245.215.58   10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.215.73   10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.215.94   10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.215.245  10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.215.254  10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.217.47   10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.217.202  10.22.248.33    255.255.255.254 UG    0      0        0 tun0
63.245.217.204  10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.217.210  10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.217.213  10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.217.214  10.22.248.33    255.255.255.254 UG    0      0        0 tun0
63.245.217.216  10.22.248.33    255.255.255.254 UG    0      0        0 tun0
63.245.217.218  10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
63.245.223.14   10.22.248.33    255.255.255.255 UGH   0      0        0 tun0
223.202.6.0     10.22.248.33    255.255.255.224 UG    0      0        0 tun0

> 2) it's missing the "Use this connection only for resources on its network"
> checkbox.

No, it's not missing.  That's why connections to non-mozilla hosts still work.

> Combined, these two issues would result in DNS queries failing. It is
> possible there are some other issues, so it's best to compare all the
> screenshots in that mana page to your config to make sure everything is
> correct.

I did that before filing the bug.

> However, I believe the resolvconf package is required for NetworkManager to
> actually utilize it.

I have that package installed.
:dbaron, I've looked over comment 0 again and I do not see you trying to send DNS queries to 10.22.75.40. Can you try this command and tell me what happens (while connected to the VPN)?

host www.mozilla.org 10.22.75.40
That command (exactly) is in comment 0, 5 lines from the end, along with some other related ones.
:dbaron, quite sorry I missed those lines. As you are the only person with this issue, I suspect the problem is client-side, however I would really like to make sure of that before proceeding. To that end, do you have access to a Mac or Windows machine that you can test your VPN username & password on, to see if you have the same problem or not?
Not easily (or, really, not a machine that I trust with my credentials).
While I'm trying to figure this out, can you give me some more information?

(1) I see that you're unable to send DNS queries to 10.22.75.40, but are you able to ping it?

(2) Can you show me the iptables configuration you're running when you're on the VPN? The command 'iptables-save' might dump the config, depending on which distribution you're running.
(In reply to Dan Parsons [:lerxst] from comment #10)
> While I'm trying to figure this out, can you give me some more information?
> 
> (1) I see that you're unable to send DNS queries to 10.22.75.40, but are you
> able to ping it?

no

$ ping 10.22.75.40
PING 10.22.75.40 (10.22.75.40) 56(84) bytes of data.
^C
--- 10.22.75.40 ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12094ms


> (2) Can you show me the iptables configuration you're running when you're on
> the VPN? The command 'iptables-save' might dump the config, depending on
> which distribution you're running.

It produces no output.  But then if I run iptables -L, it will produce output:

 $ iptables-save
 # iptables-save 
 # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
 # iptables-save
# Generated by iptables-save v1.4.21 on Thu Oct 16 20:08:08 2014
*filter
:INPUT ACCEPT [12:1829]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [11:1891]
COMMIT
# Completed on Thu Oct 16 20:08:08 2014
 # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
I've triple-checked your VPN profile and verified you have all the access you should for this to work, and you do. As best I can tell, this is a client side issue. The best way I can help you at this point is for me to ssh into your machine and try to figure out what's going on. Alternatively, you can tell me which Linux distribution and exact version you're using, and I can try to recreate the problem on my end, but I am doubtful that a fresh install of whatever you're running will have this problem, so I really think the best option is for me to troubleshoot from inside your machine.

How would you like to proceed?
:dbaron, how would you like to proceed?
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3270]
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3270] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3275]
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3275] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3280]
deleted bogus whiteboard tag
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3280]
Closing this due to inactivity - feel free to reopen if this is still an issue.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Resolution: FIXED → INCOMPLETE
This now works with the new VPN setup.
Resolution: INCOMPLETE → WORKSFORME
You need to log in before you can comment on or make changes to this bug.