Re: SIP with NAT traversal and STUN using NPF
Martin Husemann <[email protected]> Sat, 13 Jun 2026 21:30:09 +0200
| Newsgroups | gmane.os.netbsd.devel.network |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Jun 13, 2026 at 02:10:21PM -0400, Greg Troxel wrote: > Martin Husemann <[email protected]> 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