You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using pbr for routing outgoing SMTP traffic via a wireguard connection instead of the WAN interface.
My Setup
interface wan is the local uplink
interface smtp_vpn is the wireguard interface
my local IP on this interface is 10.90.12.1
a single peer is configured (and connected) with a few allowed_ips is configured (including 0.0.0.0/0)
resulting default route for the wireguard interface:
root@router:~# ip r | grep -w default | grep smtp_vpn
default dev smtp_vpn proto static scope link metric 20
Problem
The default route configured in the dynamically generated routing table pbr_smtp_vpn is wrong:
root@router:~# ip r show table pbr_smtp_vpn | grep -w default
default via 10.90.12.1 dev smtp_vpn
Here the local IP address (10.90.12.1) is used as a default gateway.
This obviously does not work.
Instead the original link-level route should have been applied (see "My Setup" above).
Workaround
In order to let the configured packets flow via the smtp_vpn interface, I configured a static route via OpenWrt for the table dynamically maintained by pbr:
Probably the above is not robust enough, but it works as for now.
And now there are two default routes in this dynamic pbr table:
root@router:~# ip r show table pbr_smtp_vpn | grep -w default
default via 10.90.12.1 dev smtp_vpn
default dev smtp_vpn proto static scope link metric 15
For unknown reasons, the (unwanted) host-based route (via 10.90.12.1) is ignored by the kernel. This lets the static route handle the traffic.
Possible cause
/etc/init.d/pbr currently contains the following function:
pbr_get_gateway4() {
local iface="$2" dev="$3" gw
network_get_gateway gw "$iface"trueif [ -z"$gw" ] || [ "$gw"='0.0.0.0' ];then# gw="$(ubus call "network.interface.${iface}" status | jsonfilter -e "@.route[0].nexthop")"
gw="$(ip -4 a list dev "$dev"2>/dev/null | grep inet | awk '{print $2}'| awk -F "/"'{print $1}')"fieval"$1"='$gw'
}
The currently active gw= assignment picks the local IP as the gateway IP.
I cannot imagine a situation, where the local IP could be the proper choice for a default route.
Thus, the above fallback is probably of no use at all?
I would recommend one of the following changes:
A) do not set a route, if no default gateway is found
no surprises, no problems
a static route should be a reasonable workaround for most affected users
B) set a link-scope route, if no default gateway is found
this works for wireguard interfaces (just by accident)
Thanks for maintaining the great pbr package!
The text was updated successfully, but these errors were encountered:
I am using
pbr
for routing outgoing SMTP traffic via a wireguard connection instead of the WAN interface.My Setup
wan
is the local uplinksmtp_vpn
is the wireguard interface10.90.12.1
allowed_ips
is configured (including0.0.0.0/0
)Problem
The default route configured in the dynamically generated routing table
pbr_smtp_vpn
is wrong:Here the local IP address (
10.90.12.1
) is used as a default gateway.This obviously does not work.
Instead the original link-level route should have been applied (see "My Setup" above).
Workaround
In order to let the configured packets flow via the
smtp_vpn
interface, I configured a static route via OpenWrt for the table dynamically maintained bypbr
:Probably the above is not robust enough, but it works as for now.
And now there are two default routes in this dynamic
pbr
table:For unknown reasons, the (unwanted) host-based route (via
10.90.12.1
) is ignored by the kernel. This lets the static route handle the traffic.Possible cause
/etc/init.d/pbr
currently contains the following function:The currently active
gw=
assignment picks the local IP as the gateway IP.I cannot imagine a situation, where the local IP could be the proper choice for a default route.
Thus, the above fallback is probably of no use at all?
I would recommend one of the following changes:
Thanks for maintaining the great
pbr
package!The text was updated successfully, but these errors were encountered: