Closed
Bug 1278088
Opened 8 years ago
Closed 6 years ago
Mozilla External VPN doesn't provide working connectivity or DNS
Categories
(Infrastructure & Operations :: Infrastructure: OpenVPN, task)
Infrastructure & Operations
Infrastructure: OpenVPN
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: dbaron, Unassigned)
Details
Attachments
(2 files)
The Mozilla External VPN (set up in bug 1269077, etc.) doesn't provide working connectivity or DNS for me, although it apparently works for other people. When I connect, I get: Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1813] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",0]: VPN connection: (IP Config Get) reply received. Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1822] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: VPN connection: (IP4 Config Get) reply received Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1828] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: VPN Gateway: 63.245.214.136 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1828] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Tunnel Device: tun0 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1828] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: IPv4 configuration: Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1828] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Internal Gateway: 10.22.232.5 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1828] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Internal Address: 10.22.232.6 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1828] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Internal Prefix: 32 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1828] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Internal Point-to-Point Address: 10.22.232.5 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1828] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Maximum Segment Size (MSS): 0 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1829] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Static Route: 10.22.72.132/32 Next Hop: 10.22.232.5 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1829] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Static Route: 63.245.214.137/32 Next Hop: 172.31.0.1 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1829] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Static Route: 10.22.232.1/32 Next Hop: 10.22.232.5 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1829] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Forbid Default Route: no Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1829] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: Internal DNS: 10.22.72.132 Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1829] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: DNS Domain: '(none)' Jun 5 00:43:48 pescadero NetworkManager[992]: <info> [1465087428.1829] vpn-connection[0x26f33c0,5203f42b-e64b-4e96-a331-b407c13edad1,"Mozilla Internet VPN",5:(tun0)]: Data: No IPv6 configuration I then end up with the routing table: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.22.232.5 0.0.0.0 UG 50 0 0 tun0 0.0.0.0 172.31.0.1 0.0.0.0 UG 600 0 0 wlan0 10.22.72.132 10.22.232.5 255.255.255.255 UGH 50 0 0 tun0 10.22.232.1 10.22.232.5 255.255.255.255 UGH 50 0 0 tun0 10.22.232.5 0.0.0.0 255.255.255.255 UH 50 0 0 tun0 10.27.88.200 172.31.0.1 255.255.255.255 UGH 600 0 0 wlan0 63.245.214.136 172.31.0.1 255.255.255.255 UGH 600 0 0 wlan0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0 172.31.0.0 0.0.0.0 255.255.0.0 U 600 0 0 wlan0 But I don't seem to be able to reach anything -- not the given DNS server (10.22.72.132), not 8.8.8.8 or 4.2.2.1 I'm using the same software that worked with the office VPNs and with the Datacenter VPN.
If you have multiple LDAP accounts, try the Mofoco one instead of the Community one. (If not, it's something else, but given your BMO email address, it's worth a shot.)
|
Reporter | |
Comment 2•8 years ago
|
||
No, definitely using my Moco LDAP account.
|
|
Reporter | |
Comment 3•8 years ago
|
||
Any idea how to make progress here? Might there be something set up wrong with my account? (I only have one LDAP account that I know of, and it's an @mozilla.com one.)
In the above routing table, why is 10.27.88.200 routing over wlan0 through your home network's 172.31.0.1 gateway?
Can you try ping *and* traceroute for all of: 10.22.232.5 10.22.232.1 10.22.74.25 10.22.74.1 ?
Also, as a second test, please try removing the NetworkManager VPN connection entirely, running 'service network restart' or whatever equivalent, and then running: $ sudo openvpn config.conf From the command line, inside the External VPN configuration tarball, and repeat the ping/traceroute tests for the comment 5 IPs as well as the DNS server IP (10.22.72.132) and Google DNS (8.8.8.8). This may seem like an excessively invasive test, but NetworkManager is at fault for all but one of the past year of Linux tech support complaints about the VPN, so it's essential to confirm that it works *from the command line* before trying to fix NM.
|
|
Reporter | |
Comment 7•8 years ago
|
||
|
|
Reporter | |
Comment 8•8 years ago
|
||
The OpenVPN startup output was: $ sudo openvpn config.conf Mon Jul 18 02:20:52 2016 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb 2 2016 Mon Jul 18 02:20:52 2016 library versions: OpenSSL 1.0.2g-fips 1 Mar 2016, LZO 2.08 Enter Auth Username: ****************** Enter Auth Password: ****** Mon Jul 18 02:20:56 2016 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file Mon Jul 18 02:20:56 2016 UDPv4 link local: [undef] Mon Jul 18 02:20:56 2016 UDPv4 link remote: [AF_INET]63.245.214.136:1194 Mon Jul 18 02:20:56 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Mon Jul 18 02:20:59 2016 [externalvpn.scl3.mozilla.com] Peer Connection Initiated with [AF_INET]63.245.214.136:1194 Mon Jul 18 02:21:02 2016 TUN/TAP device tun0 opened Mon Jul 18 02:21:02 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mon Jul 18 02:21:02 2016 /sbin/ip link set dev tun0 up mtu 1500 Mon Jul 18 02:21:02 2016 /sbin/ip addr add dev tun0 local 10.22.232.6 peer 10.22.232.5 RTNETLINK answers: File exists Mon Jul 18 02:21:02 2016 ERROR: Linux route add command failed: external program exited with error status: 2 Mon Jul 18 02:21:02 2016 Initialization Sequence Completed
|
|
Reporter | |
Comment 9•8 years ago
|
||
And, FWIW, if I add "verb 4" to the config.conf and retry, there's more info on the error with "route add": Mon Jul 18 02:31:23 2016 us=524201 [externalvpn.scl3.mozilla.com] Peer Connection Initiated with [AF_INET]63.245.214.136:1194 Mon Jul 18 02:31:25 2016 us=916787 SENT CONTROL [externalvpn.scl3.mozilla.com]: 'PUSH_REQUEST' (status=1) Mon Jul 18 02:31:26 2016 us=185885 PUSH: Received control message: 'PUSH_REPLY,route 10.22.72.132 255.255.255.255,route 63.245.214.136 255.255.255.255 net_gateway,route 63.245.214.137 255.255.255.255 net_gateway,dhcp-option DNS 10.22.72.132,redirect-gateway def1,route 10.22.232.1,topology net30,ping 10,ping-restart 120,ifconfig 10.22.232.10 10.22.232.9' Mon Jul 18 02:31:26 2016 us=185998 OPTIONS IMPORT: timers and/or timeouts modified Mon Jul 18 02:31:26 2016 us=186014 OPTIONS IMPORT: --ifconfig/up options modified Mon Jul 18 02:31:26 2016 us=186023 OPTIONS IMPORT: route options modified Mon Jul 18 02:31:26 2016 us=186028 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Mon Jul 18 02:31:26 2016 us=186149 ROUTE_GATEWAY 10.247.32.1/255.255.248.0 IFACE=wlan0 HWADDR=5c:c5:d4:1d:b4:4c Mon Jul 18 02:31:26 2016 us=186387 TUN/TAP device tun0 opened Mon Jul 18 02:31:26 2016 us=186411 TUN/TAP TX queue length set to 100 Mon Jul 18 02:31:26 2016 us=186431 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mon Jul 18 02:31:26 2016 us=186460 /sbin/ip link set dev tun0 up mtu 1500 Mon Jul 18 02:31:26 2016 us=189194 /sbin/ip addr add dev tun0 local 10.22.232.10 peer 10.22.232.9 Mon Jul 18 02:31:26 2016 us=190685 /sbin/ip route add 63.245.214.136/32 via 10.247.32.1 Mon Jul 18 02:31:26 2016 us=191923 /sbin/ip route add 0.0.0.0/1 via 10.22.232.9 Mon Jul 18 02:31:26 2016 us=193100 /sbin/ip route add 128.0.0.0/1 via 10.22.232.9 Mon Jul 18 02:31:26 2016 us=196009 /sbin/ip route add 10.22.72.132/32 via 10.22.232.9 Mon Jul 18 02:31:26 2016 us=197342 /sbin/ip route add 63.245.214.136/32 via 10.247.32.1 RTNETLINK answers: File exists Mon Jul 18 02:31:26 2016 us=198562 ERROR: Linux route add command failed: external program exited with error status: 2 Mon Jul 18 02:31:26 2016 us=198622 /sbin/ip route add 63.245.214.137/32 via 10.247.32.1 Mon Jul 18 02:31:26 2016 us=199528 /sbin/ip route add 10.22.232.1/32 via 10.22.232.9 Mon Jul 18 02:31:26 2016 us=200359 Initialization Sequence Completed
|
||
Comment 10•8 years ago
|
||
:limed, is the External VPN publishing the 63.245.214.136 route shown above twice? :dbaron, were there any logs after Initialization Sequence Completed? Did the VPN client abort to the command line, or continue running? At this stage, what were the results of your ping/traceroute tests?
Flags: needinfo?(rtucker)
Flags: needinfo?(limed)
|
|
Reporter | |
Comment 12•8 years ago
|
||
(In reply to Richard Soderberg [:atoll] from comment #10) > :dbaron, were there any logs after Initialization Sequence Completed? No. (Though at verb 4 there were plenty of logs before it.) Or rather, nothing until I hit Ctrl+C to terminate it, at which point it did print out some additional stuff. > Did > the VPN client abort to the command line, or continue running? Continued running. > At this > stage, what were the results of your ping/traceroute tests? See attachment in comment 8.
Flags: needinfo?(dbaron)
|
|
||
Comment 13•8 years ago
|
||
Hm. So, your VPN is working for reaching 8.8.8.8, but isn't working for other things. Okay. Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.22.232.5 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 10.247.32.1 0.0.0.0 UG 600 0 0 wlan0 Why does it say Genmask 128.0.0.0 there? Does the string "0.0.0.0/1" or "0/1" appear somewhere in the config.conf?
|
|
Reporter | |
Comment 14•8 years ago
|
||
(In reply to Richard Soderberg [:atoll] from comment #13) > Hm. So, your VPN is working for reaching 8.8.8.8, but isn't working for > other things. Okay. > > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 0.0.0.0 10.22.232.5 128.0.0.0 UG 0 0 0 tun0 > 0.0.0.0 10.247.32.1 0.0.0.0 UG 600 0 0 wlan0 > > Why does it say Genmask 128.0.0.0 there? Does the string "0.0.0.0/1" or > "0/1" appear somewhere in the config.conf? No. The config.conf is: ----- #-- Config Auto Generated By Viscosity --# #viscosity startonopen false #viscosity dhcp true #viscosity dnssupport true #viscosity name Mozilla Certificate Based VPN remote externalvpn.scl3.mozilla.com 1194 udp remote externalvpn.scl3.mozilla.com 1194 tcp-client remote externalvpn.scl3.mozilla.com 443 tcp-client remote externalvpn.scl3.mozilla.com 80 tcp-client #redirect-gateway def1 auth-user-pass persist-key tls-client tls-auth ta.key 1 pull ca ca.crt dev tun persist-tun cert cert.crt comp-lzo no nobind key key.key cipher AES-256-CBC remote-cert-eku "TLS Web Server Authentication" resolv-retry infinite reneg-sec 2592000 ----- Presumably where it comes from is these lines in comment 9: >Mon Jul 18 02:31:26 2016 us=191923 /sbin/ip route add 0.0.0.0/1 via 10.22.232.9 >Mon Jul 18 02:31:26 2016 us=193100 /sbin/ip route add 128.0.0.0/1 via 10.22.232.9 (When I saw that, I was guessing maybe it did it that way because being slightly more specific overrides the default route through wlan0, which is 0.0.0.0/0.)
|
|
||
Comment 15•8 years ago
|
||
Ah. That makes sense. Thank you for providing the details above - the VPN team will pick up from here soon.
|
||
Updated•8 years ago
|
Flags: needinfo?(limed)
|
||
Comment 16•8 years ago
|
||
I'm using a Mac, but I just connected and got the following routing table and DNS server (and can confirm that I can browse the web and do DNS lookups): jabba@mozpdx-25070:~> netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 0/1 10.22.232.9 UGSc 37 0 utun0 default 192.168.1.1 UGSc 1 0 en0 10.22.72.132/32 10.22.232.9 UGSc 2 0 utun0 10.22.232.1/32 10.22.232.9 UGSc 1 0 utun0 10.22.232.9 10.22.232.10 UHr 69 27 utun0 10.22.232.9/32 link#12 UCS 1 0 utun0 63.245.214.136/32 192.168.1.1 UGSc 2 0 en0 63.245.214.137/32 192.168.1.1 UGSc 2 0 en0 127 127.0.0.1 UCS 1 0 lo0 127.0.0.1 127.0.0.1 UH 13 57716 lo0 128.0/1 10.22.232.9 UGSc 26 0 utun0 169.254 link#5 UCS 1 0 en0 192.168.1 link#5 UCS 15 0 en0 192.168.1.1/32 link#5 UCS 2 0 en0 192.168.1.1 a4:2b:b0:fa:76:8 UHLWIir 9 6471 en0 1103 192.168.1.2 ec:8:6b:24:ba:21 UHLWIi 2 56 en0 1126 192.168.1.5 0:11:32:3e:1d:ff UHLWIi 4 3465179 en0 1163 192.168.1.100 8c:29:37:5b:7b:9c UHLWIi 1 0 en0 863 192.168.1.102 link#5 UHLWIi 1 4 en0 192.168.1.103/32 link#5 UCS 2 0 en0 192.168.1.103 b8:f6:b1:1c:49:3f UHLWIi 1 160 lo0 192.168.1.104 b8:3e:59:ab:7b:33 UHLWIi 1 1420 en0 1191 192.168.1.105 0:24:81:2a:ec:77 UHLWIi 1 1236 en0 1180 192.168.1.106 link#5 UHLWIi 1 19898 en0 192.168.1.107 link#5 UHLWIi 1 0 en0 192.168.1.109 link#5 UHLWIi 1 0 en0 192.168.1.110 link#5 UHLWIi 1 2 en0 192.168.1.113 ac:bc:32:5f:e0:f8 UHLWIi 2 52059 en0 1154 192.168.1.115 link#5 UHLWIi 1 0 en0 192.168.1.116 link#5 UHLWIi 1 0 en0 192.168.1.255 link#5 UHLWbI 1 17216 en0 224.0.0 link#5 UmCS 2 0 en0 224.0.0.251 1:0:5e:0:0:fb UHmLWI 1 0 en0 255.255.255.255/32 link#5 UCS 2 0 en0 255.255.255.255 link#5 UHLWbI 1 17216 en0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fdbb:9428:a347:1::/64 link#5 UC en0 fdbb:9428:a347:1:224:81ff:fe2a:ec77 link#5 UHLWIi en0 fdbb:9428:a347:1:6ddf:dba5:ba15:d785 b8:f6:b1:1c:49:3f UHL lo0 fdbb:9428:a347:1:75a4:6e6:cd34:f29f b8:f6:b1:1c:49:3f UHL lo0 fdbb:9428:a347:1:9d1f:c713:d353:6806 b8:f6:b1:1c:49:3f UHL lo0 fdbb:9428:a347:1:a4bb:8bf1:9724:d52b b8:f6:b1:1c:49:3f UHL lo0 fdbb:9428:a347:1:b1a6:da05:de58:cdb b8:f6:b1:1c:49:3f UHL lo0 fdbb:9428:a347:1:baf6:b1ff:fe1c:493f b8:f6:b1:1c:49:3f UHL lo0 fdbb:9428:a347:1:d000:2cd0:6e0f:6b86 b8:f6:b1:1c:49:3f UHL lo0 fdbb:9428:a347:1:dc69:a662:d258:f9d5 b8:f6:b1:1c:49:3f UHL lo0 fe80::%lo0/64 fe80::1%lo0 UcI lo0 fe80::1%lo0 link#1 UHLI lo0 fe80::%en0/64 link#5 UCI en0 fe80::224:81ff:fe2a:ec77%en0 0:24:81:2a:ec:77 UHLWIi en0 fe80::1ab4:30ff:fe20:e193%en0 link#5 UHLWIi en0 fe80::1ab4:30ff:fe20:f147%en0 link#5 UHLWIi en0 fe80::1ab4:30ff:fe25:c226%en0 link#5 UHLWIi en0 fe80::baf6:b1ff:fe1c:493f%en0 b8:f6:b1:1c:49:3f UHLI lo0 fe80::%awdl0/64 link#10 UCI awdl0 fe80::588b:bdff:fe43:bba2%awdl0 5a:8b:bd:43:bb:a2 UHLI lo0 fe80::%utun1/64 fe80::a7df:5432:a52c:241b%utun1 UcI utun1 fe80::a7df:5432:a52c:241b%utun1 link#13 UHLI lo0 ff01::%lo0/32 ::1 UmCI lo0 ff01::%en0/32 link#5 UmCI en0 ff01::%awdl0/32 link#10 UmCI awdl0 ff01::%utun1/32 fe80::a7df:5432:a52c:241b%utun1 UmCI utun1 ff02::%lo0/32 ::1 UmCI lo0 ff02::%en0/32 link#5 UmCI en0 ff02::%awdl0/32 link#10 UmCI awdl0 ff02::%utun1/32 fe80::a7df:5432:a52c:241b%utun1 UmCI utun1 jabba@mozpdx-25070:~> cat /etc/resolv.conf # # Mac OS X Notice # # This file is not used by the host name and address resolution # or the DNS query routing mechanisms used by most processes on # this Mac OS X system. # # This file is automatically generated. # search utun0.viscosity nameserver 10.22.72.132 jabba@mozpdx-25070:~> By chance, do you have the setting enabled that's along the lines of "send all traffic over this vpn connection" or "only use for traffic destined to the vpn's network" or similar? I'm not sure how that should be set in Network Manager, but the vpn's server does push the correct setting to force all traffic over the VPN, except for local traffic, but it could definitely be interpreted and implemented differently by client. I think the command line openvpn client should work fine, but would need the up/down scripts to update DNS settings. It looks like there could be some IP space conflicts here. I see default route of 10.247.32.1 in some of the log output, and I'm not sure that this is designed to work from any of our offices (or from any 10.0.0.0/8 space for that matter). Can you confirm that you get similar results from a local network that uses something other than 10.x.x.x address space?
|
|
Reporter | |
Comment 17•8 years ago
|
||
(In reply to Justin Dow [:jabba] from comment #16) > By chance, do you have the setting enabled that's along the lines of "send > all traffic over this vpn connection" or "only use for traffic destined to > the vpn's network" or similar? I believe I had it set up NOT to "Use this connection only for resources on its network", although per instructions in comment 6 I've now deleted the NetworkManager configuration for the VPN, so I'm no longer certain how it was configured. > It looks like there could be some IP space conflicts here. I see default > route of 10.247.32.1 in some of the log output, and I'm not sure that this > is designed to work from any of our offices (or from any 10.0.0.0/8 space > for that matter). Can you confirm that you get similar results from a local > network that uses something other than 10.x.x.x address space? I'll try to remember to try again when I'm on such a network. (I'm currently on an office network that uses 10.0.0.0/8 space.) (This wasn't the case for comment 0, but I haven't tried the commandline-openvpn experiment on such a network.)
|
|
Reporter | |
Comment 18•8 years ago
|
||
(In reply to Justin Dow [:jabba] from comment #16) > It looks like there could be some IP space conflicts here. I see default > route of 10.247.32.1 in some of the log output, and I'm not sure that this > is designed to work from any of our offices (or from any 10.0.0.0/8 space > for that matter). Can you confirm that you get similar results from a local > network that uses something other than 10.x.x.x address space? I see similar results in a network that is 192.168.100.0/24. $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.22.232.13 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.100.1 0.0.0.0 UG 600 0 0 wlan0 10.22.72.132 10.22.232.13 255.255.255.255 UGH 0 0 0 tun0 10.22.232.1 10.22.232.13 255.255.255.255 UGH 0 0 0 tun0 10.22.232.13 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 63.245.214.136 192.168.100.1 255.255.255.255 UGH 0 0 0 wlan0 63.245.214.137 192.168.100.1 255.255.255.255 UGH 0 0 0 wlan0 128.0.0.0 10.22.232.13 128.0.0.0 UG 0 0 0 tun0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0 192.168.100.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0 I can ping 8.8.8.8, but not any of the other IP addresses.
|
|
||
Comment 19•8 years ago
|
||
Could you try adding two commands to config.conf: route-nopull redirect-gateway def1 And try the command-line test (openvpn config.conf) again?
|
|
Reporter | |
Comment 20•8 years ago
|
||
(In reply to Richard Soderberg [:atoll] from comment #19) > Could you try adding two commands to config.conf: > > route-nopull > redirect-gateway def1 > > And try the command-line test (openvpn config.conf) again? Same results. Of the 6 IP addresses, 8.8.8.8 is the only one that responds to pings. (Didn't try traceroute.) $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.22.232.5 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.0.254 0.0.0.0 UG 600 0 0 wlan0 1.1.1.1 192.168.0.254 255.255.255.255 UGH 600 0 0 wlan0 10.22.232.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 63.245.214.136 192.168.0.254 255.255.255.255 UGH 0 0 0 wlan0 128.0.0.0 10.22.232.5 128.0.0.0 UG 0 0 0 tun0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0 192.168.0.0 0.0.0.0 255.255.0.0 U 600 0 0 wlan0
|
|
Reporter | |
Comment 21•8 years ago
|
||
And the openvpn output was: Mon Jul 25 00:30:13 2016 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb 2 2016 Mon Jul 25 00:30:13 2016 library versions: OpenSSL 1.0.2g-fips 1 Mar 2016, LZO 2.08 Enter Auth Username: ****************** Enter Auth Password: ****** Mon Jul 25 00:30:31 2016 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file Mon Jul 25 00:30:31 2016 UDPv4 link local: [undef] Mon Jul 25 00:30:31 2016 UDPv4 link remote: [AF_INET]63.245.214.136:1194 Mon Jul 25 00:30:31 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Mon Jul 25 00:30:35 2016 [externalvpn.scl3.mozilla.com] Peer Connection Initiated with [AF_INET]63.245.214.136:1194 Mon Jul 25 00:30:38 2016 Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS]) Mon Jul 25 00:30:38 2016 Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS]) Mon Jul 25 00:30:38 2016 Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS]) Mon Jul 25 00:30:38 2016 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) Mon Jul 25 00:30:38 2016 Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS]) Mon Jul 25 00:30:38 2016 Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS]) Mon Jul 25 00:30:38 2016 TUN/TAP device tun0 opened Mon Jul 25 00:30:38 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mon Jul 25 00:30:38 2016 /sbin/ip link set dev tun0 up mtu 1500 Mon Jul 25 00:30:38 2016 /sbin/ip addr add dev tun0 local 10.22.232.6 peer 10.22.232.5 Mon Jul 25 00:30:38 2016 Initialization Sequence Completed
|
|
||
Comment 22•6 years ago
|
||
Breaking the silence. I looked into this a bit during the work to make a 2.4 server, as I too have had bad luck with external. Most of this bug reads like a fairly standard "networkmanager is hard and our instructions are old" issue, and I wanted to see if there was more to it. I did discover a misconfig in the server that would have presented anyone using the external vpn with a bad experience (probably "can't do anything/must disconnect" every 30 mins), which I've since remedied. Pings are nondeterministic on the external; the filters to the internal network are so very tight that I have a working connection and can't ping most of the devices between me and the world, home or at an office. I had a solid hour on the external at home, and basic triage at the office is working (somewhat to my surprise). As it stands, I -think- the externalvpn service is healed. If there are still issues, I can look some more. But otherwise I think THIS bug is some combination of (resolved | lingering-bigger-issue-of-linux-instructions-are-bad,-but-this-is-known-and-not-getting-better-until-a-new-server-is-launch-ready).
QA Contact: jbircher
|
|
Reporter | |
Comment 23•6 years ago
|
||
Yes, this now works. Thanks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•