Openvpn issues in 2.3-beta
-
When using a interface not your default gateway, to connect from when selecting this in the configuration, in previous openvpn configurations, the reply went through the selected interface however now it uses default gateway unless your route the IP through a different wan, also this used to happen if sticky connections wasn't enabled but this isn't the case anymore, .. so sticky connections is broken, or openvpn is.
-
I usually go for the recommended Multi WAN setup, works fine here. https://doc.pfsense.org/index.php/Multi-WAN_OpenVPN
-
My point is in 2.2.6 this works just with sticky and in beta it doesn't. To me this seems a step backwards. Why have sticky => ensure that that the data leaves the connection it originates from if you're not going to make it work?
This is BETA not ALPHA shit should work, that dpinger consumes a lot of cpu that's BETA. shit that doesn't work is ALPHA
-
Sticky wouldn't have ever affected that.
It would take a static route to make the traffic leave through a specific interface. Binding/listening is fine, but sending traffic out has always required a static route to leave an alternate WAN.
-
This a client or a server? Sticky has no impact whatsoever on what you're talking about.
-
client and yes it does have an effect, when you define the client interface openvpn should bind from it. And since this is a wan interface it shouldn't suddenly start using a different wan interface as it's gateway.
And maybe this issue isn't with sticky but with openvpn, but each connection has it's gateway and traffic shouldn't jump from one wan to an other.
-
It will bind to that address, yes, but it still obeys the system routing table when deciding which interface the traffic exits, which is why a static route is needed to ensure the traffic exits the correct way.
If it worked in the past, something on the system must have been setting a static route for that address to leave the non-default WAN.
-
No that can't be the case, why you may ask
<router>–---[openvpn linked]–-- <dedicated server="">router has 2 static ip with seperate /28
same for dedicated server static ip with cidr /28when i ssh to the main ip of the dedicated server the traffic was routed through the main gateway wan1 only the cidr/28 traffic is routed over the vpn. only the vpn is routed over the second wans static ip wan2.
but when I sshed to the dedicated server the traffic went over wan1 (no there was no pf rules, correcting this behaviour) and openvpn client would connect to dedicated server vpn through wan2, basically 2 clients same network however taking different routes to get to a specific service without using pf only by selecting what interface openvpn client should connect from.
so why doesn't this work in beta 2.3 any more. ok, I can make it work through pf. and I would agree that if you bind to a lan interface then go through NAT that it would select the default gateway. but in this case you've binded from a specific wan and it should always try and use that wan and connect from it, and there for using it's gateway if traffic goes out its range. Shouldn't a traffic use it's own gateway.
like:
8.1.1.0/24 ->8.1.1.1
8.2.1.0/24 ->8.2.1.1why would traffic jump from 8.2.1.0/24 to 8.1.1.0/24, ok there's a default gateway but it should forward it to it's gateway first and not move from one interface to the one next to it.
Or maybe that's just me looking at it all wrong.</dedicated></router>
-
I'm almost positive 'pass out route-to' rules used to route the traffic appropriately for OpenVPN clients in 2.2.x. The issues inherent in doing that with Squid seemed to be TCP-only, or not relevant to the OpenVPN client use case. It's not in 2.3 though. It's matching the appropriate rule to do so.
@138(1000012211) pass out route-to (igb1 192.168.1.254) inet from 192.168.1.2 to ! 192.168.1.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"where 192.168.1.2 is WAN, 1.254 is WAN's gateway. But it ends up going out via the routing table on a diff interface.
Need to try that on 2.2.6 and compare.
