OPNsense Forum
Archive => 19.1 Legacy Series => Topic started by: DanMc85 on April 02, 2019, 12:40:36 am
-
Has anyone else noticed issues with utilizing an OpenVPN client in a multi-gateway setup (not redirecting all traffic) on any 19.1.x build of OPNSense? I have tried both a clean reinstall/rebuild and the usual upgrade with existing configuration with same result. There is a bug somewhere.
So here is my basic setup...
I have a VLAN 100 on my LAN... any device in this subnet goes out a Private Internet Access VPN Client GATEWAY that is running on OPNSense as a client. Others do this with a simple Alias for specific devices, regardless the principal setup is the same.
So from what I can tell on any build of 19.1.x (tried them all) and currently 19.1.4 this setup stops working.
Here is what I can see so far:
- OpenVPN client connects perfectly
- OpenVPN client obtains DHCP IP Address from VPN Server (Private Internet Access) and assigns an IP address to the OPNSense Firewall.
- There is an active interface on the firewall (OVPNC1) which then activates a DYNAMIC IPv4 Gateway for this connection... Monitor IP is set to Private Internet Access DNS Server: 209.222.18.218
- There are firewall rules for OpenVPN to allow Any Any
- There are firewall rules for the VLAN 100 interface to allow any traffic out Private Internet Access VPN Gateway.
- There are manual Outbound NAT Rules created
Somehow something is broken somewhere. If I go to ping interface diagnostics, chose the VLAN 100 or Private Internet Access Interfaces. Ping any address. It fails.
On the home screen dashboard, dpinger shows the gateway as down/offline. VPN connection is up perfectly.
- Makes no sense.
I feel this is an outbound NAT issue, but I am not sure where to dig deeper for troubleshooting other than modifying NAT rules, firewall rules, etc... which I have already played around with.
I attached some screenshots of it working perfectly on 18.7.10_4
Reference Topics:
https://forum.opnsense.org/index.php?topic=4979.msg52493#msg52493
https://forum.opnsense.org/index.php?topic=11843.msg53785#msg53785
https://blog.networkprofile.org/pia-vpn-on-pfsense-2-4-4/
-
Attached is a screenshot of the gateway offline/down on 19.1.4. Same VPN connection, direct upgrade with no configuration changes.
-
https://github.com/opnsense/core/issues/3381
-
- Screenshot of NAT rules
- tcpdump on ovpnc interface while pinging your monitor IP
- Routing table showing your open vpn routes
- I'd tick "Lock" in interface assignments
-
- Screenshot of NAT rules
- tcpdump on ovpnc interface while pinging your monitor IP
- Routing table showing your open vpn routes
- I'd tick "Lock" in interface assignments
Information you requested:
https://github.com/opnsense/core/issues/3381#issuecomment-479684767
-
Do you have only one client config or more?
Do you have also a server config?
When assigning interface don't use "OpenVPN" interface in NAT rules.
Why do you have don't pull routes ticked? Do you use policy based routing via gateway in firewall rules?
-
Do you have only one client config or more?
Do you have also a server config?
When assigning interface don't use "OpenVPN" interface in NAT rules.
Why do you have don't pull routes ticked? Do you use policy based routing via gateway in firewall rules?
- 1 OpenVPN Client Config
- 3 OpenVPN Server Configs
- Yes, all traffic is not going over VPN Client. Only traffic from VLAN 100 is going over the VPN Client - Private Internet Access Gateway.
-
The only thing wrong is that in one tcpdump your public IP is used as source in the tunnel which can't work.
If you post screenshots with wrong configurations but say you tested after you deleted it, it's hard to troubleshoot from remote.
Just remove the useless NAT rules with OpenVPN interface and try again. It will work .. why shouldn't it work? It's just NAT, the error is clear :)
-
Exactly, it was trying to use the firewall IP (firewall hostname shown) as the source network in the tcpdump. Instead of the VPN client IP as the source.
I did. As I mentioned there are no OpenVPN interface NAT rules. Those are gone and were added during testing. It doesnt work.
Look at the last screenshot on github link.
Sent from my SM-G973U using Tapatalk
-
No, please now a fresh screenshot of NAT rules and a tcpdump on ovpnc interface with the ping :)
-
FYI issue is still occurring on 19.1.6
-
As this is a configuration issue there wont be a fix in a new release ;)
-
I noticed this same issue occurring on my OPNsense instance after upgrading from 19.1.10 to 19.7.*
I have cloned the 19.1.10 version and spent significant time playing around and trying to work out what's going on, but nothing obvious is presenting itself as the cause. I basically rolled back for now, but did anybody figure out what is causing the issue?
Essentially traffic just stops flowing to the internet out of the PIA gateway altogether after the upgrade. rolling back to 19.1.10 solves the issue again for me.
My setup is pretty much identical to the one described by DanMC85.
-
I noticed this same issue occurring on my OPNsense instance after upgrading from 19.1.10 to 19.7.*
I have cloned the 19.1.10 version and spent significant time playing around and trying to work out what's going on, but nothing obvious is presenting itself as the cause. I basically rolled back for now, but did anybody figure out what is causing the issue?
Essentially traffic just stops flowing to the internet out of the PIA gateway altogether after the upgrade. rolling back to 19.1.10 solves the issue again for me.
My setup is pretty much identical to the one described by DanMC85.
Wait for 19.7.3, there is a fix for Multiwan and local connections
-
Thats great news,
Thanks for the response mimugmail :D
-
Hi Guys,
Just tried again by running the update to 19.7.3 and I'm afraid I'm still experiencing the exact same issue as before, rolled back for now again.
-
Didn't get much chance to do any testing, but what I can say for sure was that the firewall gateway monitoring could no longer reach/ping the PIA DNS servers at 209.222.18.218 after the upgrade was complete, but when running 19.1.10 this works, just double checked it after rolling back.