Closed Bug 894415 Opened 12 years ago Closed 12 years ago

unable to access mtv1 based foopys from datacenter VPN

Categories

(Infrastructure & Operations :: Infrastructure: OpenVPN, task)

Product:
Infrastructure & Operations
Component:
Infrastructure: OpenVPN
Platform:
x86_64
Linux
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bhearsum, Assigned: jabba)

Details

Eg, foopy123.build.mtv1.mozilla.com Callek tells me that they used to be accessible, but Amy says that it's not possible... In any case, this is a regression compared to the RelEng VPN :(.
Looks like their PDUs aren't accessible either, unsurprisingly. Eg: foopy123-mgmt.build.mtv1.mozilla.com
Hmm. I am able to ping that host through the datacenter vpn and 10.250.48.0/22 is in the ACL. Might need some more troubleshooting... Are you getting refused, timeout, other error?
Timeouts: ➜ buildbotcustom nc.traditional -vz foopy123.build.mtv1.mozilla.com 22 foopy123.build.mtv1.mozilla.com [10.250.49.167] 22 (ssh) : Connection timed out ➜ buildbotcustom /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.242.24.1 0.0.0.0 UG 0 0 0 wlan0 10.2.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.8.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.10.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.12.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.14.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.16.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.18.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.20.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.21.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.22.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.22.248.1 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 10.22.248.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.24.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.26.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.30.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.32.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.34.0.0 10.22.248.9 255.254.0.0 UG 0 0 0 tun0 10.110.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.128.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.130.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.132.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.134.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.150.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.224.0.0 10.22.248.9 255.255.0.0 UG 0 0 0 tun0 10.242.24.0 0.0.0.0 255.255.248.0 U 9 0 0 wlan0 10.253.0.0 10.22.248.9 255.255.255.0 UG 0 0 0 tun0 63.245.214.137 10.242.24.1 255.255.255.255 UGH 0 0 0 wlan0 63.245.215.58 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.215.245 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.215.254 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.216.84 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.47 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.202 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.203 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.204 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.210 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.213 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.214 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.215 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.216 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.217 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 63.245.217.218 10.22.248.9 255.255.255.255 UGH 0 0 0 tun0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
I know it's unlikely to be related, but it might be worth noting that bug 812432 happened over the weekend. I don't know that would impact vpn routes though!
Turns out the "don't push office routes if connecting from an office" logic broke this, since we exclude 10.250.0.0/16 now. I left that exclusion, but added 10.250.48.0/22 (the releng network inside mtv1) to the global routes list, which means now if connecting from an office, you only get the /22 for the build network and if connecting from outside the office, you get the full /16 in addition to the /22. The client should be intelligent enough to use the /22 when needed and fall back to the /16 for office stuff outside the build network, since the /16 includes the /22.
Assignee: infra → jdow
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
WFM now. Thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.