17.1.1 pbr

Started by dragon2611, February 11, 2017, 05:08:45 PM

Previous topic - Next topic
February 11, 2017, 05:08:45 PM Last Edit: February 11, 2017, 05:14:34 PM by dragon2611
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.

February 11, 2017, 05:20:51 PM #1 Last Edit: February 11, 2017, 05:41:19 PM by dragon2611
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.

Quote from: djGrrr on February 12, 2017, 03:53:55 PM
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.