Cannot access/ping machines in /23 subnet

[aman.h...@gmail.com]

Hi,

I have a weird situation here. My remote subnet (to which I VPN into to access servers/machines/IP phones etc.) is 192.168.0.0/23. That means servers/machines etc. will get IP's starting from 192.168.0.1 - 192.168.1.254 with subnet mask of 255.255.254.0. When I connect to this VPN server, I can only ping/access servers/machines which is IP's in 192.168.0.X range but cannot access anything that is 192.168.1.X range. VPN clients gets IPs in 192.168.50.0/24 but they are allowed to access 192.168.0.0/23.

Same configuration works very well in Windows/Linux. My configuration and versions are as below:

MacOS High Sierra

OpenVPN server: 2.4.4

Tunnelblick 3.7.4 (build 4900)

Configuration:

---

client

resolv-retry 20

keepalive 10 60

nobind

mute-replay-warnings

ns-cert-type server

comp-lzo

max-routes 500

verb 1

persist-key

persist-tun

explicit-exit-notify 1

dev tun

proto udp

port 1194

cipher AES-128-CBC

cert keys/client.crt

key keys/client.key

ca keys/client-ca.crt

remote X.X.X.X 1194 # public address 

remote X.X.X.X 1194 # static WAN 1

---

Log:

---

2018-01-31 19:54:19 DEPRECATED OPTION: --max-routes option ignored.The number of routes is unlimited as of OpenVPN 2.4. This option will be removed in a future version, please remove it from your configuration.

2018-01-31 19:54:19 OpenVPN 2.4.4 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Nov  2 2017

2018-01-31 19:54:19 library versions: LibreSSL 2.5.5, LZO 2.10

2018-01-31 19:54:19 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337

2018-01-31 19:54:19 Need hold release from management interface, waiting...

*Tunnelblick: OS X 10.13.3; Tunnelblick 3.7.4 (build 4900)

2018-01-31 19:54:19 *Tunnelblick: Attempting connection with client using shadow copy; Set nameserver = 769; monitoring connection

2018-01-31 19:54:19 *Tunnelblick: openvpnstart start client.tblk 1337 769 0 1 0 1100208 -ptADGNWradsgnw 2.4.4-libressl-2.5.5

2018-01-31 19:54:20 *Tunnelblick: openvpnstart log:

     OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):

     

          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.4-libressl-2.5.5/openvpn

          --daemon

          --log

          /Library/Application Support/Tunnelblick/Logs/-SUsers-Sahanjrah-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sclient.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_1100208.1337.openvpn.log

          --cd

          /Library/Application Support/Tunnelblick/Users/ahanjrah/client.tblk/Contents/Resources

          --setenv

          IV_GUI_VER

          "net.tunnelblick.tunnelblick 4900 3.7.4 (build 4900)"

          --verb

          3

          --config

          /Library/Application Support/Tunnelblick/Users/ahanjrah/client.tblk/Contents/Resources/config.ovpn

          --verb

          3

          --cd

          /Library/Application Support/Tunnelblick/Users/ahanjrah/client.tblk/Contents/Resources

          --management

          127.0.0.1

          1337

          --mtu-test

          --management-query-passwords

          --management-hold

          --script-security

          2

          --route-up

          /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -p -w -ptADGNWradsgnw

          --down

          /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -p -w -ptADGNWradsgnw

2018-01-31 19:54:19 *Tunnelblick: openvpnstart starting OpenVPN

2018-01-31 19:54:20 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337

2018-01-31 19:54:20 *Tunnelblick: Established communication with OpenVPN

2018-01-31 19:54:20 MANAGEMENT: CMD 'pid'

2018-01-31 19:54:20 MANAGEMENT: CMD 'state on'

2018-01-31 19:54:20 MANAGEMENT: CMD 'state'

2018-01-31 19:54:20 MANAGEMENT: CMD 'bytecount 1'

2018-01-31 19:54:20 MANAGEMENT: CMD 'hold release'

2018-01-31 19:54:20 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.

2018-01-31 19:54:20 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2018-01-31 19:54:20 TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:1194

2018-01-31 19:54:20 Socket Buffers: R=[196724->196724] S=[9216->9216]

2018-01-31 19:54:20 UDP link local: (not bound)

2018-01-31 19:54:20 UDP link remote: [AF_INET]X.X.X.X:1194

2018-01-31 19:54:20 MANAGEMENT: >STATE:1517457260,WAIT,,,,,,

2018-01-31 19:54:20 MANAGEMENT: >STATE:1517457260,AUTH,,,,,,

2018-01-31 19:54:20 TLS: Initial packet from [AF_INET]X.X.X.X:1194, sid=46628b79 c989367e

2018-01-31 19:54:20 VERIFY OK: depth=1, CN=certificateAuthority, C=CO, ST=ST, L=L, O=O, OU=OU, dnQualifier=certificateAuthority

2018-01-31 19:54:20 VERIFY OK: nsCertType=SERVER

2018-01-31 19:54:20 VERIFY OK: depth=0, C=CO, ST=ST, O=O, OU=OU, CN=server, dnQualifier=server

2018-01-31 19:54:22 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

2018-01-31 19:54:22 [server] Peer Connection Initiated with [AF_INET]X.X.X.X:1194

2018-01-31 19:54:23 MANAGEMENT: >STATE:1517457263,GET_CONFIG,,,,,,

2018-01-31 19:54:23 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

2018-01-31 19:54:23 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.

2018-01-31 19:54:23 PUSH: Received control message: 'PUSH_REPLY,register-dns,route 192.168.0.0 255.255.254.0,route 192.168.50.0 255.255.255.0,topology net30,ping 10,ping-restart 60,dhcp-option DNS 192.168.50.1,dhcp-option DOMAIN example.com,ifconfig 192.168.50.126 192.168.50.125'

2018-01-31 19:54:23 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:1: register-dns (2.4.4)

2018-01-31 19:54:23 OPTIONS IMPORT: timers and/or timeouts modified

2018-01-31 19:54:23 OPTIONS IMPORT: --ifconfig/up options modified

2018-01-31 19:54:23 OPTIONS IMPORT: route options modified

2018-01-31 19:54:23 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

2018-01-31 19:54:23 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key

2018-01-31 19:54:23 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication

2018-01-31 19:54:23 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key

2018-01-31 19:54:23 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication

2018-01-31 19:54:23 Opened utun device utun0

2018-01-31 19:54:23 do_ifconfig, tt->did_ifconfig_ipv6_setup=0

2018-01-31 19:54:23 MANAGEMENT: >STATE:1517457263,ASSIGN_IP,,192.168.50.126,,,,

2018-01-31 19:54:23 /sbin/ifconfig utun0 delete

                                        ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

2018-01-31 19:54:23 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

2018-01-31 19:54:23 /sbin/ifconfig utun0 192.168.50.126 192.168.50.125 mtu 1500 netmask 255.255.255.255 up

2018-01-31 19:54:23 MANAGEMENT: >STATE:1517457263,ADD_ROUTES,,,,,,

2018-01-31 19:54:23 /sbin/route add -net 192.168.0.0 192.168.50.125 255.255.254.0

                                        add net 192.168.0.0: gateway 192.168.50.125

2018-01-31 19:54:23 /sbin/route add -net 192.168.50.0 192.168.50.125 255.255.255.0

                                        add net 192.168.50.0: gateway 192.168.50.125

                                        **********************************************

                                        Start of output from client.up.tunnelblick.sh

                                        Disabled IPv6 for 'Wi-Fi'

                                        Disabled IPv6 for 'Bluetooth PAN'

                                        Disabled IPv6 for 'Thunderbolt Bridge'

                                        Retrieved from OpenVPN: name server(s) [ 192.168.50.1 ], domain name [ example.com ], search domain(s) [  ], and SMB server(s) [  ]

                                        Not aggregating ServerAddresses because running on OS X 10.6 or higher

                                        Prepending 'example.com' to search domains '' because the search domains were not set manually (or are allowed to be changed) and 'Prepend domain name to search domains' was selected

                                        Saved the DNS and SMB configurations so they can be restored

                                        Changed DNS ServerAddresses setting from '192.168.1.254' to '192.168.50.1'

                                        Changed DNS SearchDomains setting from '' to 'example.com'

                                        Changed DNS DomainName setting from 'attlocal.net' to 'example.com'

                                        Did not change SMB NetBIOSName setting of ''

                                        Did not change SMB Workgroup setting of ''

                                        Did not change SMB WINSAddresses setting of ''

                                        DNS servers '192.168.50.1' will be used for DNS queries when the VPN is active

                                        NOTE: The DNS servers do not include any free public DNS servers known to Tunnelblick. This may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.

                                        Flushed the DNS cache via dscacheutil

                                        /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil

                                        Notified mDNSResponder that the DNS cache was flushed

                                        Setting up to monitor system configuration with process-network-changes

                                        End of output from client.up.tunnelblick.sh

                                        **********************************************

2018-01-31 19:54:27 *Tunnelblick: No 'connected.sh' script to execute

2018-01-31 19:54:27 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

2018-01-31 19:54:27 Initialization Sequence Completed

2018-01-31 19:54:27 MANAGEMENT: >STATE:1517457267,CONNECTED,SUCCESS,192.168.50.126,X.X.X.X,1194,,

2018-01-31 19:54:32 *Tunnelblick process-network-changes: A system configuration change was ignored

2018-01-31 19:54:32 *Tunnelblick: This computer's apparent public IP address (Y.Y.Y.Y) was unchanged after the connection was made

2018-01-31 19:57:32 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1557,1557] remote->local=[1557,1557]

---

I am not sure what might be the issue here. Can someone please check the logs and help me find the cause of such Bizarre behavior here.

Thanks

[Tunnelblick developer]

Is it possible that the LAN that you are using has the address 192.168.1.0? That's what is hinted at by:

Changed DNS ServerAddresses setting from '192.168.1.254' to '192.168.50.1'

OpenVPN (on Macs, anyway) can't work with a local subnet that has the same IP addresses as the remote subnet. When they are exactly the same OpenVPN usually warns about that, but more likely the local subnet is 192.168.1.0/24, which isn't exactly the same but does overlap.

The choice of subnet on the remote side (192.168.0.0/23) is very unfortunate, since it will overlap with many (maybe even most) default setups that home and SOHO routers use, which is 192.168.0.0/24 or 192.168.1.0/24). Those setups are very common, for example, in Internet cafes and other publicly accessible Wi-Fi networks.

[aman S]

Yes, the subnet at home (from where I am trying to access this VPN) is 192.168.1.0/24.

We don't have many macs here at the organization, it's just me and one other person and we both were facing this. All others have Windows/Linux machines and they connect just fine. It is unfortunate, but I'll try to change the subnet at VPN location to something bizarre. What would you suggest for that? Perhaps 192.168.151.0/23? That is pretty random number for a range. Also, I am not that sure but the DHCP range in this case should be 192.168.151.1 - 192.168.152.254, please correct me if I am wrong.

Thank you for making this clear for me.

[Tunnelblick developer]

I just had an idea: What happens if you check "Route all IPv4 traffic through the VPN"? I think that may solve the problem. (But when connected to your VPN you wouldn't be able to access other devices (computers, printers, etc.) on your home network.

Here's what I wrote before thinking of that:

I'm not an expert on routing – OpenVPN does all of the routing, not Tunnelblick.

You might want to consult OpenVPN experts about why it works for Windows/Linux but not Mac. (I don't really see how it can work, by the way: if your computer wants to access, say, 192.168.1.99, should it access that address on your local network or on your VPN's local network? How can it possibly do both?

I'm not sure about this but I think the third octet (the 153) should be an even number since you want both the even and odd addresses for it. So I think you might want 192.168.152.0/23. 152 decimal is 230 octal, so the range would be 192.168.152.0 - 192.168.153.255. But this makes my brain hurt and I could easily be wrong.

[aman S]

Hmm, I am not sure how windows or Linux does it but I tried that option as well (Route all IPv4 traffic through the VPN) and it did not work. I suppose the right way to do is to change the range on the VPN side of the network so that even if I am sitting @starbucks, I could access my machines remotely without worrying about subnet/IP clash. For now, changing the home network to 192.168.5.X/24 did the trick.

I'll get in touch with OpenVPN devs to see what is the right way to do things.

Thanks for you the help.

[aman S]

Hi,

I got this figured out with the help of openvpn trac users (selvanair and cron2). All I needed was to make use of --redirect-gateway parameter in client config (although this can be pushed by the server as well).

In my client config I added:

redirect-gateway block-local

and after connecting to VPN, it worked like a charm. I can access all the machines/IP phones/switches/servers etc. etc. that sits in a remote location.

I just updated this thread so that if anybody else face this issue, they don't have to go through all the hassle.

Cheers!

[Tunnelblick developer]

Thanks for the update.

I think that if you specify "redirect-gateway block-local" then you can't access the machines on the local LAN when you're connected. Is that correct?

[aman S]

That is partially correct. But in my specific case, I don't run anything on my LAN, all the servers and other network devices are on a remote location, hence this solution fits my need.

I tried to access my router at home (after connecting to the VPN), and I was able to access it. So I think instead of blocking, this option just gives the remote gateway preference to access devices. If anything would've been running on the same IP remotely (192.168.1.254), then I think it would've not been possible to access the local router. This is just my thinking, I'll perform some tests when I get chance and update.