[Solved] Some hosts missing over OpenVPN

[alexblackie]

The last couple weeks I've been running into an issue that confuses me.

I have OpenVPN set up to give clients an IP from 192.168.32.0/24 and to push the LAN, 192.168.8.0/22 as a route. It works….. mostly. I can access the router, one of my servers, and my desktop. However there are ~5 other machines on that LAN that just simply do not exist over the VPN (and are definitely up).

AFAICT it's not a "I pushed the wrong subnet" issue, as the missing hosts are all over the subnet (not just after a certain IP) -- for example, one host missing is 192.168.10.6, however 192.168.10.2 and 192.168.11.109 are both accessible.

I've been experiencing this on both my remote machines: both Fedora 22, one using NetworkManager's VPN integration and the other just using straight openvpn running in a screen session...

My server-side configuration: http://s.fromalex.com/openvpn-server-config.png
And client-side: https://gist.github.com/alexblackie/18d3a3b09a969c2e535c

I'm at a loss, and not sure where to even begin looking. Any insight would be greatly appreciated.

[johnpoz]

possible mask issue on the client on the vpn side.. When you do a traceroute to those IPs do you go through the tunnel..

Possible firewall issue on the client.  This is common issue

how many hosts do you have that you need a or want to use a /22 in the first place?  Do you have 1000 machines?  If you did wouldn't make sense to put them on smaller broadcast domains say /24's ??

[alexblackie]

Yep, traceroute's going through the VPN.

Disabled firewalls on all machines.

/22 is completely arbitrary–just for my own organization... I definitely don't need it; will try scaling it back to a /24.

[johnpoz]

well if your going down the tunnel and not getting an answer back that points to client.. Sniff on pfsense do you see the traffic going to the client?  Sniff on client to see if sees the traffic and answer.

[alexblackie]

Blech, after a bunch of packet capturing, tracerouting, config spray-and-pray, I realised it wasn't a pfSense issue at all.

All the machines I was looking for were actually VMs, and it turns out the default gateway on those machines was set to the virtual libvirt network, which the responses got lost in before ever hitting pfSense. Setting the default route straight to the pfSense box forced it to go over the secondary macvtap interface, and then everything worked as expected…  :-X

Thanks for your help!

[johnpoz]

"I realised it wasn't a pfSense issue at all."

Which is like 99.9% of all the issues on this board to be honest..

[divsys]

Perhaps a gentle reminder to the OP:

Some might find it helpful if you were to update the original message title to include "[Solved]".

I know this gets missed, often the OP never comes back to check the forum (all their problems are solved after all) but I find it worth repeating from time to time.