OPNsense Forum
Archive => 17.1 Legacy Series => Topic started by: dragon2611 on February 11, 2017, 05:08:45 pm
-
Pretty sure 17.1.1 doesn't fix all the policy routing issue as I've got a teamspeak server running on a host with 2 WAN uplinks on the DNS points to WAN2, since upgrading no-one can connect to it.
It's a NAT port forward from the secondary uplink.
-
Specifically it looks like the reply doesn't automatically get routed to WAN2 to match the incoming, Not sure if I redirected all traffic from that host to WAN2 if it would work.
Edit: Even with a policy wan rule to put outbound traffic to WAN2 it still doesn't work, 17.1.x so far is a lemon if you have multiple wans/policy routing requirements it seems
-
Can you try running this from the shell as root?
sysctl net.pf.share_forward=0
This should restore the stock FreeBSD way of doing policy routing.
-
I have also Teamspeak related problems, but they are different:
As soon as i have a 24h reconnect i have to restart the ts client. Before that it will not connect to the external TS server. Very strange but it is the same behavior on all devices. I will dig into it tonight.
-
Can you try running this from the shell as root?
sysctl net.pf.share_forward=0
This should restore the stock FreeBSD way of doing policy routing.
I'm afraid I already restored the VM from a backup that was taken prior to upgrading
-
Right re-applied the update and sysctl net.pf.share_forward=0 does appear to resolve the issue.
-
Sorry, we are circling back to a default of net.pf.share_forward=0 and a GUI override to in 17.1.2 to get to see underlying base OS update issues first, then improve shared forwarding further.