Re: SIP with NAT traversal and STUN using NPF

[Greg Troxel <gdt%lexort.com@localhost>]

Martin Husemann <martin%duskware.de@localhost> writes:

> On Sun, Jun 14, 2026 at 05:00:26PM +0200, Edgar Fuß wrote:
>> Possibly dumb question: does NPF support stateful UDP?
>
> There ain't no dumb question, and better to double check anyway!

Indeed, but NPF the toolkit supports "pass stateful out".

> The answer depends on what you define as "stable". The various UDP messages
> from my VoIP device to the server are all mapped with a stable source
> port translation.
>
> But: the same dest port is not translated back 1:1 when a UDP packet is
> received from the server with a different source port.

huh?   A NAT mapping is created when local A sends to outside B

  A:B a:b

which allocates A' and a' on the wan side of the NAT and sends

  A':B a':b

which stores a mapping that

  B:A' b:a'

will get turned back into

  B:A b:a

on the LAN side.  There is generally not an expectation of other ports
getting mapped.

> Example (traced on my outside interface):
>
> 12:58:34.326026 PPPoE  [ses 0x10d] IP (tos 0x0, ttl 63, id 62136, offset 0, flags [DF], proto UDP (17), length 210)
>     ${MY_IP}.16797 > ${REMOTE_IP}.32536: [udp sum ok] UDP, length 182
> 12:58:34.334538 PPPoE  [ses 0x10d] IP (tos 0xb8, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 210)
>     ${REMOTE_IP}.32536 > ${MY_IP}.29564: [no cksum] UDP, length 182
> 12:58:34.346054 PPPoE  [ses 0x10d] IP (tos 0x0, ttl 63, id 62142, offset 0, flags [DF], proto UDP (17), length 210)
>     ${MY_IP}.16797 > ${REMOTE_IP}.32536: [udp sum ok] UDP, length 182
> 12:58:34.354267 PPPoE  [ses 0x10d] IP (tos 0xb8, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 210)
>     ${REMOTE_IP}.32536 > ${MY_IP}.29564: [no cksum] UDP, length 182

the mystery is why the REMOTE->MY packets are using what seems like the
wrong port.

> Where ${MY_IP} is my public IPv4 and ${REMOTE_IP} is the server of
> my provider.
>
> I need UDP port 29564 incoming mapped to the VoIP device original source
> port while this call is active. I suppose if UPnP would be available
> the Fritz!Box would arrange for this via that.

So what happened when you ran tcpdumpd and recorded every single packet
sent to or from the fritzbox and then examined the entire trace?

> Can I make NPF map this automatically?

Not really, because how do you know where it's supposed to go (port on
the inside), and your global port space is being shared by N inside
hosts.

> I tried a 
>
n> 	map $ext_if dynamic no-ports proto udp $voip_ip <-> $ext_v4
>
> rule, assuming the no-ports option (that disables port mapping) and
> the <-> for both in and out would give me the desired behaviour, but
> this did not work. Maybe with a bit of NPF debugging it could be made
> to work for this case - or I am doing something stupid.

Then how do replies from other systems that aren't the fritzbox get in?

> I would really prefer a NPF only solution over anything involving
> UPnP, NAT-PMP or PCP. Besides, contrary to documentation claims, I see
> no PCP activity from the device at all. It tries to find a UPnP server
> though.

Seems like you either need docs or more reverse engineering.  It seems
obvious a next step is to give it a firewall with UPnP and capture all
traffic.   Then maybe do that, but block the UPnP  with an intervening
otherwise-transparent firewall.


Also, is the SIP traffic encrypted?  If not, what's in it?  Either way,
can you turn on debug logging on the fritzbox?

I cannot overstate the importance of capturing all traffic and later
examining it, excluding parts as you understand them.  The point is to
notice things you are not looking for.

e.g.

  tcpdump -s1500 -wFRITZ host 10.0.0.91

or whatever.