Re: SIP with NAT traversal and STUN using NPF

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

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

> On Sat, Jun 13, 2026 at 07:51:37PM -0400, Greg Troxel wrote:
>> That seems like TURN not STUN.  They run on the same port, and it's
>> confusing.
>
> Wireshark calls the protocol "CLASSIC-STUN" and the packet a "BINDING REQUEST".

Just skimmed the RFC.  It is confusing because "binding request" does
not request a binding.   It is simply sending a UDP packet to the STUN
server and the STUN server sticks the apparent source address inside the
packet and replies.  So the originator finds out the public address of
the last NAT.

That's all fine; the point is for the client (e.g. SIP) to know the
last NAT public IP address in concocting NAT/FW traversal schemes.

I would check to see that the STUN reponse shows up on the LAN, and that
the debug logs on the SIP client indicate that it's ok.  But it probably
is.

> Yes, that is what I would expect too, and various docs claim it should
> just work (though some say through NAT it is always hit or miss - but
> since it worked w/o any trouble or special setup with the old firewall
> and no special setup there I had expected it to just work with NPF too).

Yes, but NPF is not a firewall.  NPF is a facility within which one can
write rules to construct a firewall.

>> It's not clear to me that you are having STUN/TURN problems as much as
>> RTP problems.
>
> I think they are related, I definitively don't get the incoming RTP connection
> working when the call is picked up.

Why do you think they are related?

  Do the STUN responses make it back?

  Do you see outgoing RTP?

  Do the incoming RTP packets reverse-match outgoing packets?

  What do the SIP debug logs say about the chosen traversal method, and
  does it make sense?

Keep in mind that docs may be about hardphone-hardphone direct calls
rather than each hardphone contacting a proxy/registrar.  For direct,
you probably do need static NAT.  But I don't know that anybody does
that.

>> When the RTP inbound packets are blocked, are there outbound RTP packets
>> from the device to the peer?
>
> This is a bit puzzling. When the call is picked up I start seeing a stream
> of UDP packets from my VoIP device to some server/port (I guess that is
> the outgoing audio) and an incoming stream of UDP packets all blocked
> by the firewall from another server/port. And I fail to match both
> server/port to anything in the "BINDING RESPONSE" packet.

The BINDING RESPONSE should tell you the outbound last NAT IP address.
Same as a what-is-my-ip service, more or less.

   https://porkbun.com/tools/whats_my_ip_address

except that you haven't explained where you are registering and if it is
in the global internet, and where the calls are to/from, SIP-SIP or SIP
to the proxy/registrar to be continued some other way.

The ootbound UDP packets should have a dst that was signaled by the SIP
peer in response to INVITE, for a VOIP service usually their servers.

>> I wonder if you are using a hardware SIP terminal ("hardphone") vs using
>> a program on a computer (linphone, or bareseip on android).   I wonder
>> if you have tried signal calls, or XMPP calls, from your LAN (with v6
>> disabled).
>
> It is a black box device, a consumer grade wifi-router + DECT gateway
> (Fritz!Box) that I use for the DECT part mostly (and as a wifi access
> point, but no routing).

And it is also an ATA with a FXO port, that you plug an analog phone
into?  Or an ATA with a virtual FXO port that is local DECT?  (We don't,
AFAIK, do DECT in the US, or really I am not familiar with it.)

> Are there any application gateway modules for NPF (or IPF that could be
> ported) and would that help? I still don't see the big picture and need
> to read more of the related RFCs.

Perhaps, but really the SIP signalling should be encrypted.

Yes, understanding more would help.   Read STUN, TURN, and ICE.

The rough tl;dr is

  TURN is a server in the NAT-free zone, usually needing authentication,
  where two parties can send UDP packets and get what the other sends.
  SIP, xmpp and matrix servers tend to have them.

  ICE is a way for two parties, perhaps both impaired by firewall/NAT,
  to try all sorts of ways to get through firewall/NAT to see which
  works, to be able to end up with a bidirectional UDP stream that
  mimimizes a cost metric.  Specifically, I think, if both A and B can
  know their public addreses A' and B', they can agree on ports a and b
  and
    A sends: A:B' a:b
    B sends  B:A' b:a
  so that B's inbound packets arriving at A's firewall match A's
  outgoing packets (after NAT).   I probably don't have that 100% right
  but that's an example thing that might work that ICE tries.   ICE can
  also try using a TURN server.  That's higher cost, but with worse
  NAT/firewall the only thing that is sort of guaranteed to work (no
  guarantees ever, GfW, DPI, etc.).


I think you should try signal calls and xmpp calls and see if they work.
That's signal/jingle signaling instead of SIP but the RTP part should be
similar.

You should definitely validate TCP connections to random places, and UDP
request/response (dns queries, ntp, and STUN).

When you are placing a call, is it trying to connect to some other
terminal behind some other NAT, or is it trying to connect to some
server in the NAT-free zone of the global internet?

It is possible that the firewall traversal code in the fritzbox is not
really good enough for the modern world, and that it is expecting to do
some sort of signaling to the firewall, with some icky windowsy
protocol.