Closed Bug 894775 Opened 11 years ago Closed 10 years ago

DC vpn can't reach 10.22.0

Categories

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

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: arich, Unassigned)

Details

We have a spider hooked up to some mac minis in scl3.  I can reach the spider (10.22.0.154) from boris, but I can't reach it from the VPN (not even ping, which I thought was supposed to be universally allowed).  I presume this is an oversight, since the DC vpn should be able to reach everything?
Hmm. The openvpn box can ping it. The vpn is pushing a route to 10.22/16 and the vpn_admin group is allowing 10.22/16. I wonder if there is a local firewall or ACL on the spider, or a netops firewall blocking the VPN subnet?
I'm going to guess that the openvpn box is no longer perform NAT for the VPN clients. The console network is, historically, non-routable. It's entirely possible that the spider was configured without a default gateway. That would explain why the openvpn box can reach it, but not the clients.
Actually, after further testing, I can reach 10.22.0.154 from both boris and SCL3 vpns. All the configs seem to be set up as I would expect. WORKSFORME?
:dmoore, have you tried from the Datacenter (Global) VPN? Indeed it is not set up to do NAT and normally can't reach the console network at all, but since the box itself can reach this host and only its clients can't, I'm wondering if this is the issue or indeed a missing gateway on the spider.
Flags: needinfo?(dmoore)
Flags: needinfo?(dmoore)
Flags: needinfo?(dmoore)
Mozilla VPN can't reach this box, and I have no idea how to parse the ping output below.

SCL3 VPN and Boris PVN *can* reach this box, presumably due to their direct-connected interfaces on 10.22.0.x.

Per comment 0, I'm resolving this as WORKSFORME - the original issue, "unable to reach 10.22.0.154 from DC VPNs", has been resolved, and so there's nothing further to do here.

openvpn1.corpdmz.scl3$ ping 10.22.0.154
PING 10.22.0.154 (10.22.0.154) 56(84) bytes of data.
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.1: icmp_seq=1 Redirect Host(New nexthop: 10.22.72.155)
From 10.22.72.155 icmp_seq=1 Time to live exceeded
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(dmoore)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.