On 2/8/24 10:18, Stuart Henderson wrote:
On 2024/02/08 09:19, Peter J. Philipp wrote:
On 2/7/24 20:15, Janne Johansson wrote:
pass in log quick on wg1 inet proto udp from 192.168.178.1 to any port = 5060 sc
rub (reassemble tcp) divert-packet port 22222
The mix of udp and tcp reassembly seems interesting there.
Yeah it does, but it is added on both stern (which works)
and superpod (which doesn't). Since this is not such a big
problem I'm gonna rest on it, and perhaps move the
divert'ing entirely to stern. The reason being is that the
incoming SIP packets are not fragmented, as they are not
really (or ever) big enough. So my phone setup works on
SDP'ing outgoing SIP packets.
I think that's a red herring.
"reassemble tcp" is poorly named and does not actually deal with
reassembling fragmented packets, see the paragraphs following this in
pf.conf(5) -
reassemble tcp
Statefully normalises TCP connections. reassemble
tcp performs the following normalisations:
the things done by "reassemble tcp" *only* apply to TCP packets.
In other works there is no way to remove the reassemble tcp
scrub option as it's not in my rules to begin with.
It is added automatically for divert-packet rules.
I would start by adding "match log(matches)" to the top of pf.conf and
monitor the pflog0 interface to make sure packets are matched by the
intended rules. (tcpdump -neipflog0)
I immediately thought this was good advice. Also after giving my reply
some time and thinking about it I think I don't need sipdiv itself on
superpod. The reason being that incoming packets never were
problematic, and what's coming in is coming through a wireguard from the
fritzbox at my parents house, and it is leaving through wireguard to my
home. Since the MTU of both wireguards is at 1420 if it goes in it must
go out. I'm glad I still built sipdiv because stern is before the
wireguards in my home. It requires shrinking the SIP with SDP.
Thankfully the fritzboxes understand SDP, it's weird to find a knob for
this (I couldn't) on FritzOS! itself.
So I have a .pcap that I'd share with anyone why the early quick rule
does not get called. It has to do with nat rules on the wireguard
facing my parents house, they create a state and once it's there I'm
reasoning that NAT states don't get diverted. I don't think there is
any NAT rules on stern that are similar.
Thanks and Best Regards to all who replied!
-peter
PS: please forgive the thunderbird formatting. I still haven't set up a
way to get inbound mail into a mutt client, after setting up a mail host
that has no sshd but rather is controlled on console.
