Re: SIP with NAT traversal and STUN using NPF

[Martin Husemann <martin%duskware.de@localhost>]

On Sat, Jun 13, 2026 at 02:10:21PM -0400, Greg Troxel wrote:
> Martin Husemann <martin%duskware.de@localhost> writes:
> 
> > (I love subjects with tons of acronyms...)
> >
> > Has anyone here used NetBSD and NPF on a firewall and managed to allow
> > a SIP device (like VoIP phone system) in the local LAN to connect via a
> > STUN server to on an IPv4 connnection?
> 
> I think so, but I am surprised you are having trouble.
> 
> You said firewall, and you didn't say NAT.

OK, sorry, should have been clearer.

I have a dual stack connection, but only a single IPv4 adress. Unfortunately
the VoIP servers of my provider (at least the ones in my current plan)
are IPv4 only - otherwise I would have done an "exposed host" setup for
the IPv6 address of the VoIP device.

So I use NPF on the firewall, and do NAT for IPv4.

The VoIP device talks to a STUN server at my provider and requests simple
NAT traversal like this:

Frame 2: Packet, 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: b6:3c:5c:ee:8a:e4 (b6:3c:5c:ee:8a:e4), Dst: AVMAudiovisu_00:e2:2c (1c:ed:6f:00:e2:2c)
Internet Protocol Version 4, Src: ${STUN_SERVER}, Dst: ${VOIP_INTERNAL_IP}
User Datagram Protocol, Src Port: 3478, Dst Port: 7078
Simple Traversal of UDP Through NAT
    [Request In: 1]
    [Time: 7.990000 milliseconds]
    Message Type: Binding Response (0x0101)
    Message Length: 0x0024
    Message Transaction ID: 9d34044bd68f0157c1199300b27b090d
    Attributes
        Attribute: MAPPED-ADDRESS
            Attribute Type: MAPPED-ADDRESS (0x0001)
            Attribute Length: 8
            Protocol Family: IPv4 (0x0001)
            Port: 44745
            IP: ${MY_PUBLIC_IP}
        Attribute: SOURCE-ADDRESS
            Attribute Type: SOURCE-ADDRESS (0x0004)
            Attribute Length: 8
            Protocol Family: IPv4 (0x0001)
            Port: 3478
            IP: ${SERVER1}
        Attribute: CHANGED-ADDRESS
            Attribute Type: CHANGED-ADDRESS (0x0005)
            Attribute Length: 8
            Protocol Family: IPv4 (0x0001)
            Port: 3479
            IP: ${SERVER2}

I then get blocked incoming UDP connections when the call is established
(RTP for the audio data transfer).

So obviously some magic in between is needed (and this setup all did work
with a different firewall on different hardware; which means it must be
solvable via software once I understand the needed tweaks :-})

I am confused, as the documentation for the VoIP device says I just need
to map ports 5060 and/or 5061 from the public address to 5060/5061 on the
VoIP device. But that part is not actually needed, the VoIP device opens
a connection to port 5061 on my providers server and keeps it alive.

I get calls signalled and can call out - just when the call is
established and RTP audio connections should happen, they are blocked
by my firewall. I could make them pass (i.e. by "pass in" rules
restricted to the servers the VoIP thing communicates with) - but then
where should they be forwarded to (same port on VoIP device?) and how
would I tell npfctl?


Martin