Opened 6 years ago

Closed 6 years ago

#1013 closed User question (notabug)

Cannot connect to /23 subnet on remote network

Reported by: amans Owned by:
Priority: trivial Milestone:
Component: Networking Version: OpenVPN 2.4.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

When connecting from MacOS High Sierra using Tunnelblick (which is just a wrapper around OpenVPN), user cannot access machines that are on specific IP range (/23).

Same configuration file works perfect with Windows 10 (or earlier but not tested) and Linux (tested on Ubuntu 16.04 LTS, CentOS 6/7, Arch Linux)

OpenVPN server: 2.4.4
Tunnelblick 3.7.4 (build 4900)

Network 1 - Client network
Subnet - /24
Range - 192.168.1.1 - 192.168.1.254

Network 2 - Server network (This is where OpenVPN server is installed)
Subnet - /23
Range - 192.168.0.1 - 192.168.1.254
OpenVPN clients get IP - 192.168.50.1 - 192.168.50.254

After the connection is successful, from client n/w, users can ping IP's in 192.168.0.X range but not in 192.168.1.X range.

Attachments (1)

Configuration and log.txt (9.7 KB) - added by amans 6 years ago.

Download all attachments as: .zip

Change History (11)

Changed 6 years ago by amans

Attachment: Configuration and log.txt added

comment:1 Changed 6 years ago by Selva Nair

Your server is pushing route to 192.168.0.0/23 but that overlaps with your local subnet of 192.168.1.0/24. On most systems both routes can co-exist but the one with lower prefix will get preference. So the 192.168.1.0/24 range will continue to get routed to the local LAN. Is that what you want to see and not happening on the Mac?

comment:2 Changed 6 years ago by Gert Döring

--redirect-gateway block-local

might achieve "I can reach remote hosts in 192.168.1.x even though I am *in* a local 192.168.1.x, which would normally be preferred"

The manpage says:

block-local -- Block access to local LAN when the tunnel is
active, except for the LAN gateway itself. This is accomplished
by routing the local LAN (except for the LAN gateway address)
into the tunnel.

comment:3 Changed 6 years ago by Selva Nair

If that's the objective the OP needs something like like --redirect-local-except-gateway (not a real option) as --redirect-gateway is not in use. Manually adding two /25 routes to 192.168.1.0 and 192.168.1.128 and a /32 to the gateway would do it.

But the post says the connection works as expected on Linux but not on Mac which is suspicious whatever that "works" means.

comment:4 Changed 6 years ago by amans

Thanks,

So the 192.168.1.0/24 range will continue to get routed to the local LAN. Is that what you want to see and not happening on the Mac?

Not exactly. It is actually vice versa if I read it correct. 192.168.1.0/24 is routed to the local LAN. Probably that is why I am not able to communicate with the machines in 192.168.1.X range on the remote server (VPN). I don't care about client network once I am connected to the VPN. My purpose is the access the machines that are sitting inside remote network to which I am VPN'ing into.

But the post says the connection works as expected on Linux but not on Mac which is suspicious whatever that "works" means.

It means the same configuration (shared in attachment) works well in linux (# openvpn --client my_client_conf.ovpn) and I am able to ping whole of the /23 network (includes 192.168.0.X and 192.168.1.X) from client n/w (192.168.1.0/24)

Same works (please refer above) in Windows without making any changes to the configuration file.

I'll try the suggestion from cron2 to add "--redirect-gateway block-local" and see how it goes once I am at home tonight.

Thanks again guys for looking into this and making some suggestions.
TGIF

comment:5 Changed 6 years ago by amans

By the way here is routing table for my Mac when connected to the VPN:

https://www.dropbox.com/s/dlx6n6paupaoa5h/Screenshot%202018-02-02%2016.57.24.png?dl=0

comment:6 Changed 6 years ago by Selva Nair

The routing table looks right (as expected). Except that there are routes added by --redirect-gateway def1 but neither your config nor the logs show that option is being used. But that's not very relevant here..

As per the config and logs you had posted, 192.168.1.0/24 will go to the LAN, rest of 192.168.0.0/23 will go through the tunnel. The routing table confirms that.

If you want to route all of 192.168.0.0/23 through the tunnel try the block-local option cron2 suggested -- should work if redirect-gateway is ok. Or add three extra routes as I wrote earlier.

I have no idea why it "works" the way you want to on Linux or Windows without seeing the config, logs and routing tables on those systems before after the tunnel is up. In my view all three platforms should behave more or less the same way in this regard if they are all on the same local LAN and have similar routes before connecting to the VPN.

comment:7 Changed 6 years ago by amans

selvanair, I tried to find but could not tell if that option ( --redirect-gateway block-local ) will go to client config or the server config. Can you please confirm.
Thanks

comment:8 Changed 6 years ago by Selva Nair

Priority: criticaltrivial
Type: Bug / DefectUser question

You may push it from the server or use it in your client config.

Trac is not the right place to ask usage questions. If you want to discuss this further, asking on the openvpn-users list or the forum (or #openvpn on IRC if you prefer) may get you more detailed help.

comment:9 Changed 6 years ago by amans

selvanair,

I added "redirect-gateway block-local" in my client config and it worked. I can ping every host in remote location including 192.168.0.X and 192.168.1.X.

A big thanks to you and cron2 for guiding me through this.

Thanks.

comment:10 Changed 6 years ago by Antonio Quartulli

Resolution: notabug
Status: newclosed
Note: See TracTickets for help on using tickets.