Re: SIP with NAT traversal and STUN using NPF

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

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

> 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}

That seems like TURN not STUN.  They run on the same port, and it's
confusing.

https://datatracker.ietf.org/doc/html/rfc8489
https://www.rfc-editor.org/info/rfc8656/

See also ICE

https://www.rfc-editor.org/info/rfc8445


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

My impression is that usually the outbound packets of the RTP stream hit
a stateful rule that allow the inbound packets.

It's not clear to me that you are having STUN/TURN problems as much as
RTP problems.

What's also puzzling is that generally at least things like webrtc do
"ICE" where there are candidate methods to interchange RTP packets and
they are tried and the ICE negotiation picks the best one that works.

> 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.

The docs are probably presuming you not having a stateful firewall.

> 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?

When the RTP inbound packets are blocked, are there outbound RTP packets
from the device to the peer?

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).