Firewall rules for VoIP/SIP DNAT from WAN to LAN

Installing and Using OpenWrt
1

I'm trying to get WAN->LAN DNAT for SIP VoIP working. SIP clients are on the Internet, and SIP server is on the LAN with OpenWRT between them.

The rule I have created for this is:

config redirect
	option reflection '0'
	option dest 'lan'
	option target 'DNAT'
	option name 'SIP from Internet'
	option src 'wan'
	list proto 'tcp'
	list proto 'udp'
	option dest_ip '10.75.22.8'
	option helper 'sip'
	option src_dport '5060'
	option dest_port '5060'

but SIP connection attempts are still dropped:

Feb 17 21:30:46 gw kernel: [811723.373242] drop wan in: IN=eth0.2 OUT= SRC=2.1.1.2 DST=7.3.7.253 LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=36603 DPT=5060 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x3f00

where eth0.2 is indeed my WAN interface and 7.3.7.253 is indeed the IP address on eth0.2 (i.e. my Internet address as assigned by my ISP),

I do have kmod-nf-nathelper-extra installed and the nftables configuration is configured for the SIP helper:

table inet fw4 { # 
        ct helper sip { # 
                type "sip" protocol udp
                l3proto inet
        }

But honestly that seems to be getting ahead of the problem. The problem seems to be that even the initial packet of the incoming connection to the SIP server on the LAN is not even being allowed.

Does anyone have a working configuration for DNATting SIP from the Internet to a SIP server on their LAN that they want to share?

2

Doing a bit of debugging, I notice that every zone has a helper_<zone> chain with a list of all of the conntrack helpers in it as such:

        chain helper_lan { # handle 10
                udp dport 10080 ct helper set "amanda" comment "!fw4: Amanda backup and archiving proto" # handle 104028
                udp dport 1719 ct helper set "RAS" comment "!fw4: RAS proto tracking" # handle 104029
                tcp dport 1720 ct helper set "Q.931" comment "!fw4: Q.931 proto tracking" # handle 104030
                meta nfproto 2 tcp dport 6667 ct helper set "irc" comment "!fw4: IRC DCC connection tracking" # handle 104031
                meta nfproto 2 udp dport 137 ct helper set "netbios-ns" comment "!fw4: NetBIOS name service broadcast tracking" # handle 104032
                meta nfproto 2 tcp dport 1723 ct helper set "pptp" comment "!fw4: PPTP VPN connection tracking" # handle 104033
                tcp dport 6566 ct helper set "sane" comment "!fw4: SANE scanner connection tracking" # handle 104034
                udp dport 5060 ct helper set "sip" comment "!fw4: SIP VoIP connection tracking" # handle 104035
                meta nfproto 2 udp dport 161 ct helper set "snmp" comment "!fw4: SNMP monitoring connection tracking" # handle 104036
                udp dport 69 ct helper set "tftp" comment "!fw4: TFTP connection tracking" # handle 104037
        }

except for chain helper_wan which is empty. If I manually add the sip helper rules to it with:

# nft insert rule inet fw4 helper_wan udp dport 5060 ct helper set "sip"
# nft insert rule inet fw4 helper_wan tcp dport 5060 ct helper set "sip"

so that it looks like:

        chain helper_wan { # handle 24
                udp dport 5060 ct helper set "sip" # handle 104334
                tcp dport 5060 ct helper set "sip" # handle 104333
        }

hosts on the Internet trying to connect to my SIP server stop being dropped and work.

3

SIP is a whole art itself, but frequently is simple if you employ a recent UAC and UAS.

What you will find is that when forwarding traffic without a (destination IP) rewrite, the SIP server must recognise that it is authoritative for the federated domain for which it receives traffic. Sometimes also it disallows traffic from the wider Internet (0.0.0.0/0), safest if you have botnets probing your IP.

Without special config, it is likely authoritative for 10.75.22.8. But with additional config, it will accept and respond to traffic for 7.3.7.253. This extra config is often necessary, since rewriting the IP headers of the packet is only half of the work: the UAC will write the destination IP into SIP signalling, especially the (record-)route, to, (often the) from, and the R-URI headers, among others, unless you've set the UAC to use your WAN IP as proxy, and the LAN IP as domain. Proxy config at the UAC is simplest and allows you to set up some fake FQDN as your domain, and you set only a static forward rewriting dest IP of the signalling.

Some SIP UAC/UAS employ their own NAT mitigations, especially in route headers and tags, so it may serve best not to use any helpers. In this case, a static-forward of a range of available UDP media ports (to the UAS) is advised.

Good luck.

4

Yes, you are quite correct about the need to handle SDP ports and addresses and the like. But that is what the netfilter sip helper is supposed to do.

What seems to be going wrong here with firewall4 is that the initial packet to the router on port 5060 is not even being allowed into the router and of course therefore cannot establish a session that has the sip helper attached to it and also cannot be forwarded to the SIP server on the LAN.

This seems to be a bug in firewall4's handling of sip helpers on the WAN.

But your alternative suggestion is quite useful and most likely my path forward. Both my SIP server and clients support ICE which is it's own entire and comprehensive NAT jumping solution for SIP.

Thanks for your input @systemcrash.

5

Please review the wiki on etc config firewall how to specify the ports on the wan interface. Their might be a mix-up.

6

I have of course done this already, any number of times. I have also used Luci to confirm my configuration.

That said, if you see anything specific that I have messed up I'd be more than happy to be set straight.