If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

DC vpn can't reach 10.22.0

RESOLVED WORKSFORME

Status

Infrastructure & Operations
Infrastructure: OpenVPN
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: arr, Unassigned)

Tracking

Details

(Reporter)

Description

4 years ago
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?

Comment 1

4 years ago
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?

Comment 4

4 years ago
: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.

Updated

4 years ago
Flags: needinfo?(dmoore)

Updated

4 years ago
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
Last Resolved: 4 years ago
Flags: needinfo?(dmoore)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.