-
@thenarc said in OpenVPN One Client ... can't get it to go:
@grimm-spector Well if the gateway corresponding to your VPN connection is shown as either Offline or Pending, that would explain why your client cannot successfully use it. Try editing the settings for the gateway corresponding to your VPN connection and set the Monitor IP to something (like one of Google's DNS servers maybe, 8.8.8.8 or 8.8.4.4). You could also try the Disable Gateway Monitoring option for it so that it's always considered up. Clearly that wouldn't be a solution, but at least would be a decent test.
Alright, I have redirected it to googles dns and it shows Online. Traffic still doesn't pass, though I am not seeing any record of it's IP in the firewall logs. I've tried pinging some webhosts, pinging a LAN address that isn't the GW (this worked), tried wgets on random web files, all failed. If I disable only my deny rules however, traffic is able to get through when the gateway is down and it redirects to the main GW.
Edit:
I may have found something, due to the network setup here there are two gateways, though one is just forwarding to pfSense with the DMZ setting. That gateawy is on a different subnet, the subnet that appears here:
UDPv4 link local (bound): [AF_INET]192.168.2.xx:xxxx
I blanked the last digit and port, point is that the origin IPs are all on the subnet 192.168.1.0/24, and pfSense normally using 192.168.2.0 as it's WAN routes all 192.168.2.0/24 traffic to the main router on that subnet. Is this OpenVPN bonding to the wrong IP? Is this perhaps the issue, and why I'm not getting the right results? How can I fix it if it is?
-
@grimm-spector I'm not sure I fully understand the setup, but your OpenVPN client wouldn't be connecting successfully if it were trying to make the connection via the wrong gateway. When you look at Status > OpenVPN, in the Local Address column does your true (ISP-assigned) WAN IP appear? Also, in your VPN client configuration, do you have the Don't Pull Routes option enabled? I'm kind of grasping at straws, but those two things came to mind as worth checking. It may also be interesting to run a Diagnostics > Traceroute setting the Source Address to your OpenVPN interface. That ought to show how it's trying to route packets out the VPN tunnel.
-
@thenarc The local address is the 192.168.2.0 one, which is the one the WAN has, and is used to connect to the modem. The hosts are with certain special exceptions which cannot be changed currently, on the 192.168.1.0 subnet, which the gateway is on the LAN interface in pfSense.
The part that confuses me most, is after removing the deny rules the OpenVPN status page now shows a significant amount of data has been uploaded and downloaded, as if the shielded client was working through the VPN the entire time. If I check my public IP on the shielded host it does indeed show the VPN IP, and the other hosts show the normal IP.
However, if I turn on the deny rule, it all breaks and nothing goes to the VPN anymore. So if they VPN gateway goes down it will just use the default GW...
The current rule is on the LAN interface, where the hosts to be protected reside, and I have a rule set to their alias that has their IPs in it, set to deny block traffic with the default GW selected, at the top of the list. The one below is the same but allows them to pass to the VPN GW. And below that a default rule that excludes them and acts on all other hosts, and allows them to pass to the default GW. Something must be wrong with the Block rule, but I don't know what.
And then of course there's that issue where the monitoring was not working either, which I am unsure how to fix.
Edit: Maybe this will help, the VPN has a virtual IP, and an IP on that same segment also shows up as the gateway IP and monitor IP. It's an outside net, starting with 10., instead of something internal. Is it possible that IP is somehow being blocked by pfSense when it tries to monitor it for being active as a gateway?
-
@grimm-spector I wouldn't worry too much about the gateway monitoring. If it works using a google DNS server as the monitor IP, just use that; I do for my VPN client connections. I am confused about the firewall rules. The LAN rules are "first match top-to-bottom", so if you have a block rule above your pass rule for the VPN gateway, then anything matching that block rule is just going to be blocked completely. What is the perceived problem with removing that block rule? It sounds as if things work the way you want when you don't have it enabled, but I assume I'm missing something.
-
@thenarc said in OpenVPN One Client ... can't get it to go:
@grimm-spector I wouldn't worry too much about the gateway monitoring. If it works using a google DNS server as the monitor IP, just use that; I do for my VPN client connections. I am confused about the firewall rules. The LAN rules are "first match top-to-bottom", so if you have a block rule above your pass rule for the VPN gateway, then anything matching that block rule is just going to be blocked completely. What is the perceived problem with removing that block rule? It sounds as if things work the way you want when you don't have it enabled, but I assume I'm missing something.
If the VPN fails, then without the block rule the traffic would in theory be directed to the normal gateway, and the client would no longer be protected by the VPN but they would be unaware. The block rule stops all traffic with the host if the VPN goes down. That's why the monitoring is useful, so I'd really like to get it working properly.
The block rule is in theory only supposed to be stopping the traffic from going to the regular gateway, and not stopping it from traversing the network in general, and I am not sure what I have set wrong that causes it to block all traversal for that host.
-
@grimm-spector Ah okay, if your goal is to prevent clients that are supposed to go through the VPN from unknowingly using the main gateway instead, you don't want to use block rules, you want to use packet tagging/matching. This is a great turotial:
https://www.infotechwerx.com/blog/Prevent-Any-Traffic-VPN-Hosts-Egressing-WAN -
@grimm-spector said in OpenVPN One Client ... can't get it to go:
@thenarc said in OpenVPN One Client ... can't get it to go:
@grimm-spector I wouldn't worry too much about the gateway monitoring. If it works using a google DNS server as the monitor IP, just use that; I do for my VPN client connections. I am confused about the firewall rules. The LAN rules are "first match top-to-bottom", so if you have a block rule above your pass rule for the VPN gateway, then anything matching that block rule is just going to be blocked completely. What is the perceived problem with removing that block rule? It sounds as if things work the way you want when you don't have it enabled, but I assume I'm missing something.
If the VPN fails, then without the block rule the traffic would in theory be directed to the normal gateway, and the client would no longer be protected by the VPN but they would be unaware. The block rule stops all traffic with the host if the VPN goes down. That's why the monitoring is useful, so I'd really like to get it working properly.
The block rule is in theory only supposed to be stopping the traffic from going to the regular gateway, and not stopping it from traversing the network in general, and I am not sure what I have set wrong that causes it to block all traversal for that host.
Cool, that helps a lot, thank you. That seems to be working, the only issue that remains is that the gateway monitoring doesn't work, but I suppose that's perhaps unsolvable and perhaps a "feature" of how the VPN gateway functions in this case. Again, thank you very much!
-
@grimm-spector No problem. The gateway monitoring does work with an alternate monitoring IP like 8.8.8.8 though, right? That's basically as good, it just measures whether the gateway is up "by proxy" insofar as it's pinging a host via the gateway it's monitoring instead of pinging the gateway itself.
-
@thenarc said in [Solved] OpenVPN One Client ... can't get it to go:
@grimm-spector No problem. The gateway monitoring does work with an alternate monitoring IP like 8.8.8.8 though, right? That's basically as good, it just measures whether the gateway is up "by proxy" insofar as it's pinging a host via the gateway it's monitoring instead of pinging the gateway itself.
Ah, so it's sending a keep alive through the VPN then? That would work then I guess. Thanks!
-
@grimm-spector Exactly, it will work just fine :)