OpenVPN clients can't ping LAN
-
@marvosa Sorry, I wanted to add one more thing... There is an option to forward all IPv4 traffic, and I have it checked, but only when I unchecked it I get the Local Lan, and I have it as shown...
And with unchecked, I've tried as well, nothing happens different on my Ubuntu 20.04 OpenVPN client when I change it...
-
@marvosa Finally, here's the article from Digital Ocean on how to connect to their private "VPC" network via another server on their network...
https://www.digitalocean.com/docs/networking/vpc/resources/droplet-as-gateway/ -
@marvosa Also, you said 192.168.0.0/20 is subject to routing issues, would 172.16.0.0/20 be a better range for the OpenVPN server tunnel network? And, if so, should I re-create the VPN server or just update the existing one with that tunnel network?
-
@jacobisreal said in OpenVPN clients can't ping LAN:
Can ping 10.116.0.3 (pfSense LAN address) with no issues
CAN NOT ping 10.116.0.2 (another server on private LAN) or any other LAN server when connected to VPNIs the default gateway set correctly on the remote server to 10.116.0.3?
Do a simply test with Diagnostic > Ping.
Ping the server with default options. Should get replies. Then try again with source = OpenVPN@jacobisreal said in OpenVPN clients can't ping LAN:
Also, you said 192.168.0.0/20 is subject to routing issues, would 172.16.0.0/20 be a better range for the OpenVPN server tunnel network?
A /20 provides 4k IPs. Do you really need these? I assume, the VPN is only for your admin purposes, so you can go better with a /28.
192.168.0.0 is in generally verey common, 172.16.0.0 as well. If you have multiple clients better use something like 172.28.47.0/24. -
@viragomann Pinging with default to the LAN 10.116.0.2:
PING 10.116.0.2 (10.116.0.2): 56 data bytes 64 bytes from 10.116.0.2: icmp_seq=0 ttl=64 time=2.567 ms 64 bytes from 10.116.0.2: icmp_seq=1 ttl=64 time=0.558 ms 64 bytes from 10.116.0.2: icmp_seq=2 ttl=64 time=0.630 ms --- 10.116.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.558/1.252/2.567/0.931 msPinging from OpenVPN to 10.116.0.2:
PING 10.116.0.2 (10.116.0.2) from 192.168.0.1: 56 data bytes --- 10.116.0.2 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet lossI do have multiple clients, this is for a non-profit project where I need to grant access to the 10.116.0.0/20 network from the OpenVPN which is publicly addressed and open on the WAN. I could change the OpenVPN tunnel address to what you suggest, no problem. But no matter what I do, I can't reach the internal LAN from OpenVPN.
Thanks for your input, let me know what you think. I do not need 4k addresses, but I might need a couple hundred... I won't make any changes until I hear back. Did you review the link about Digital Ocean requiring a "gateway" machine to access their network? -
@jacobisreal
If you really need a /20 use something like 172.28.32.0/20. Ensure that you enter the network address here.Yeah, the VPN tunnel network has nothing to do with the access.
So ensure that the gateway is set correctly on the destination server and that it doesn't block the access by its own firewall. -
As far as the local network, did you mean adding 10.116.0.0/20 or 10.116.0.3/20 as you stated above?>
Yes, my apologies, 10.116.0.3/20 was a typo, I meant 10.116.0.0/20. I made the correction on my post.
On OPT1, you'll want to change the protocol to any.
Also, you said 192.168.0.0/20 is subject to routing issues, would 172.16.0.0/20 be a better range for the OpenVPN server tunnel network?
In a routed tunnel, all subnets have to be unique and 192.168.0.0/20 covers a series of common ranges for SOHO routers. This means any client whose LAN within 192.168.0.1 - 192.168.15.254 will have routing issues when trying to reach your LAN. So, you'll want to change it to something completely uncommon like @viragomann suggested. And a /20 is entirely too wide unless you really do have 4000+ clients. Trim it to fit your client base.
I would verify the mask and gateway on 10.116.0.2 are what you're expecting. Is it using PFsense as the gateway? (i.e. the IP assigned to the LAN interface). Also, for grins and giggles, I would re-verify the mask on your LAN adapter.
-
@viragomann I've temporarily disabled the firewall on the LAN server 10.116.0.2 and there is no gateway defined on it because Digital Ocean doesn't require a gateway for VPC networks. It's an Ubuntu 20.04 server, here's the netplan:
/etc/netplan$ cat 50-cloud-init.yaml # This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} network: version: 2 ethernets: eth0: addresses: - 142.xxx.xxx.xxx/20 - 10.10.0.10/16 gateway4: 142.x.x.x match: macaddress: 5a:xx:xx:xx:xx:xx nameservers: addresses: - 67.207.67.3 - 67.207.67.2 search: [] set-name: eth0 eth1: addresses: - 10.116.0.2/20 match: macaddress: xx:xx:xx:xx:xx:xx nameservers: addresses: - 67.207.67.3 - 67.207.67.2 search: [] set-name: eth1The server I'm trying to reach also has a public internet address, but it's the VPC private address of 10.116.0.2/20 that I'm trying to reach from the OpenVPN server on pfSense that has a LAN address of 10.116.0.3/20. There's no gateway to define.
-
I've temporarily disabled the firewall on the LAN server 10.116.0.2 and there is no gateway defined on it because Digital Ocean doesn't require a gateway for VPC networks. It's an Ubuntu 20.04 server, here's the netplan:>
There's your issue. In order for 10.116.0.2 to reach a network outside of it's LAN subnet (e.g. the OpenVPN tunnel network), there has to be a default gateway set. Configure the gateway to the PFsense LAN IP.
Any device you want to reach over OpenVPN will need PFsense as its gateway.
-
@marvosa Updated OpenVPN tunnel as you suggested.
-
@marvosa Updated OPT1 protocol to any:
-
@marvosa said in OpenVPN clients can't ping LAN:
I've temporarily disabled the firewall on the LAN server 10.116.0.2 and there is no gateway defined on it because Digital Ocean doesn't require a gateway for VPC networks. It's an Ubuntu 20.04 server, here's the netplan:>
There's your issue. In order for 10.116.0.2 to reach a network outside of it's LAN subnet (e.g. the OpenVPN tunnel network), there has to be a default gateway set. Configure the gateway to the PFsense LAN IP.
Any device you want to reach over OpenVPN will need PFsense as its gateway.
I can't set the gateway on that server - it's a private VPC (virtual network) inside Digital Ocean's network. The address 10.116.0.2 is the address they assigned the box on the private VPC on their side. I've read several articles that state I need a NAT rule to access that box - here's the post I read:
https://mohsensy.github.io/sysadmin/2019/06/21/secure-access-to-digital-ocean-resources-using-openvpn.html
And:
https://forum.netgate.com/topic/63243/openvpn-server-openvpn-client-and-nat/2?_=1614660188717Digital Ocean support docs state that there must be iptables rules, but pfSense doesn't use iptables - see:
https://www.digitalocean.com/docs/networking/vpc/resources/droplet-as-gateway/ -
Can you guys please take a look at their documentation? Here's the link:
https://www.digitalocean.com/docs/networking/vpc/resources/droplet-as-gateway/
It doesn't make any sense to me... If pfSense already is configured out-of-the-box to forward, and NAT rules are automatic, then this should just work. I'm pretty smart, I've tried all kinds of configurations, re-imaged the box and tried again all night. There has to be some kind of NAT I'm missing per their documentation. Ahh! :) Thank you for all your help, friends!
-
@jacobisreal
So you can only go with masquerading. However, I'd not recommend that for multiple VPN users.To activate it, go to Firewall > NAT > Outbound. If it is still in automatic mode, switch to hybrid and save that.
Add a new rule:
interface: LAN
protocol: any
sourec: any
destination: any
Translation: interface addressDirty, but may work.
-
@viragomann Like this:
-
It's possible I'm reading this wrong, but the way I see it... in order to make this work, you will need to deploy the "Network with Internet Gateway" model. PFsense is your gateway droplet and all VPC's on the LAN will need PFsense set as the default gateway.
The examples they've shown are for configuring Ubuntu/Debian/Centos droplets as an internet gateway by enabling routing, NAT and configuring the firewall (iptables).
Even if you configured OpenVPN on a properly configured Ubuntu droplet, the other devices on the network would still need their gateway set to the Ubuntu LAN IP in order to be reachable over the tunnel.
It appears that the "Configure Backend Droplets" section should be reviewed in order to add a default route to your VPC's. I'm assuming "droplets" refers to VPC's... or am I misreading what they're describing as a "droplet"?
Fingers crossed for @viragomann's suggestion though.
-
@viragomann Also, take a look at the OpenVPN server config, I still have redirect traffic over IPv4 so I can't enter the local network... should I remove the check and enter the LAN address 10.116.0.0/20 ??
-
@marvosa said in OpenVPN clients can't ping LAN:
It's possible I'm reading this wrong, but the way I see it... in order to make this work, you will need to deploy the "Network with Internet Gateway" model. PFsense is your gateway droplet and all VPC's on the LAN will need PFsense set as the default gateway.
The examples they've shown are for configuring Ubuntu/Debian/Centos droplets as an internet gateway by enabling routing, NAT and configuring the firewall (iptables).
Even if you configured OpenVPN on a properly configured Ubuntu droplet, the other devices on the network would still need their gateway set to the Ubuntu LAN IP in order to be reachable over the tunnel.
It appears that the "Configure Backend Droplets" should be reviewed in order to add a default route. I'm assuming "droplets" refers to VPC's... or am I misreading what they're describing as a "droplet"?
"Droplet" is the term Digital Ocean uses for a virtual machine. A "droplet" has a public IP address and a VPC (or virtual private network) address. In my case, my VPC network is 10.116.0.0/20. The OpenVPN server on pfSense has the WAN address and I configured the LAN address as the VPC address, 10.116.0.3. The server I'm trying to reach on the VPC LAN is 10.116.0.2, but I can't get to it for anything. I'm re-exporting the client config and trying all of your suggestions again... Here goes!
-
@jacobisreal said in OpenVPN clients can't ping LAN:
Also, take a look at the OpenVPN server config, I still have redirect traffic over IPv4 so I can't enter the local network... should I remove the check and enter the LAN address 10.116.0.0/20 ??
This directs the whole upstream traffic from the VPN client over the VPN. This aims to access internet resources with the public IP of the VPC.
If you don't need this uncheck redirect gateway and enter the VPC LAN network into the "Local networks" box. -
@marvosa @viragomann YOU FUKN GENIOUSES! Take a look...
I dunno if it was the NAT masquerade, the change in the OpenVPN tunnel, or what but it's working now!PING 10.116.0.2 (10.116.0.2) from 172.28.32.1: 56 data bytes 64 bytes from 10.116.0.2: icmp_seq=0 ttl=64 time=1.918 ms 64 bytes from 10.116.0.2: icmp_seq=1 ttl=64 time=0.785 ms 64 bytes from 10.116.0.2: icmp_seq=2 ttl=64 time=0.691 ms --- 10.116.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.691/1.131/1.918/0.558 msAND I can ping from local machine (OpenVPN client) to the other VPC box now:
ping 10.116.0.3 PING 10.116.0.3 (10.116.0.3) 56(84) bytes of data. 64 bytes from 10.116.0.3: icmp_seq=1 ttl=64 time=45.5 ms 64 bytes from 10.116.0.3: icmp_seq=2 ttl=64 time=46.3 ms 64 bytes from 10.116.0.3: icmp_seq=3 ttl=64 time=50.4 ms ^C --- 10.116.0.3 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 45.501/47.382/50.382/2.143 msWhat do you think the root cause was and why did all these suggestions work? Could it be the NAT rule?