route everything through openvpn connection: issues with interface active
-
A customer has a pfSense-CE-2.7.2 in a VM. The proverbial excavator cut his coax cable so for emergency he attached his starlink antenna and managed to set that up as another WAN_NEW interface. I disabled the original WAN interface to reduce complexity.
Internet works then, but now with a dynamic IP on WAN_NEW. He wants to run his VOIP stuff ... so he came up with an OpenVPN tunnel where the provider gives him a static IP on the other side of the tunnel. So he set up a ovpn-client on WAN_NEW, and wrote an outbound NAT rule to rewrite everything ... (I don't know the exact rule right now, I wait for the config.xml ...). Internet still works, he is visible with that IP.
Now he needs portforwardings on WAN_NEW ... (you see, this should be 1:1 emergency setup ...): so he created an interface for that ovpn-tunnel. As soon as that interface is active problems arise: he reports DNS issues etc / things work for 15-30 minutes, then issues. When the ovpn-iface is disabled: everything fine.
I already modified the system DNS servers to assign them to "none" ... unsure what the def gw is in the end: is it WAN_NEW or the ovpn-interface? Which one to use in the outbound NAT rule?
Sure: I only hear and read what he tells me to have changed, I don't know exactly what has been changed.
In the back of my head I remember some issue with ovpn as interface but I can't remember exactly.
forgive my abstract descriptions, I will try to come up with more details as soon as I have them.
Any helpful ideas here? thanks in advance
-
I have a screenshot from that mentioned NAT rule:
VPN_TRUSTZONE_AUSTRIA sits on that opvnc4 = openvpn-client
I didn't write that rule and I can't tell if it's correct or not.
The goal: everything should go out from that external VPN-tunnel-IP ... it looks fishy to me that way.
It works when checking "what is my ip" ... but the overall quality of the connection isn't very cool.
(aside from that the vpn-provider doesn't allow ports below 1024 or so ... so goodbye web-services ;-) )
-
@sgw said in route everything through openvpn connection: issues with interface active:
so he created an interface for that ovpn-tunnel. As soon as that interface is active problems arise: he reports DNS issues etc / things work for 15-30 minutes, then issues. When the ovpn-iface is disabled: everything fine.
Normally VPN providers push the default route to the client to direct the whole upstream traffic over the VPN.
If you don't want this, but want to policy-route the traffic instead, open the client settings and check "Don't pull routes".
-
@viragomann would that explain the different behavior with or without the activated interface?
thanks anyway -
@sgw
Not really for now. If the whole upstream traffic (and DNS) is routed to the VPN provider, I'd expect that it either works or is blocked.Did he configure a gateway group for upstream traffic by any chance?
-
@viragomann no gw group in place so far
-
Would it make sense to edit the general routing to use the (enabled) openvpn-client-interface as default gateway?
-
@sgw
Setting the route statically would be a bad idea.As mentioned above, normally the VPN provider pushes the default route to the client.
You can verify this by checking the routing table. If set you should see 0.0.0.0/1 and 128.0.0.0/1 pointing to the VPN servers virtual IP.
But I thought, that isn't, what you want.If the routes are not set and you want to direct all upstream traffic over the VPN edit the client settings and add the above subnets to the "IPv4 Remote network(s)".
-
@viragomann will check asap
I assume the default gateway should be the underlying WAN_NEW interface that points to the one and only upstream, in his case the starlink appliance.
Then comes the openvpn connection on top and I have to check what he has in "Remote IPv4 networks" (I thought I had looked for that and didn't see it ...?)
plus: it seems unbound somehow gets irritated ... I suggested switching over to the simpler DNS forwarder for a check. Might get access again in the next hours.
I suggested changing the "Outgoing Network Interfaces" from "All" to only WAN_NEW ... that might change the strange DNS behavior.
-
@sgw said in route everything through openvpn connection: issues with interface active:
I assume the default gateway should be the underlying WAN_NEW interface that points to the one and only upstream
The default gateway could be changed by the OpenVPN client according to its settings and if the server pushes the route.
Therefor I suggested to check the routing table, while the VPN client is connected.
Usually VPN servers push the default route, but depends on the use case.@sgw said in route everything through openvpn connection: issues with interface active:
I suggested changing the "Outgoing Network Interfaces" from "All" to only WAN_NEW
Remember that this setting just allows Unbound to send out upstream requests on the selected interfaces, but basically the request packet will follow the routing table. I.e. if the route for the requested DNS server points to the WAN GW, the packet will be sent out on the WAN interface.
-
@viragomann I lost oversight. The customer edited stuff on his own ... and wrote he succeeded by adding fw rules and policy-based-routing. Sounds like overkill a bit, but ok if he's happy.
I have to accept that this box is out of my control somehow now ;-)thanks for your help. I might report back if I get access again and see things.