Port Forward SIP on TCP not working

OpenWrt 21.02.1 r16325-88151b8303

I had issues with dropped SIP UDP packets so I am attempting to use TCP. Asterisk is configured to successfully allow outgoing calls but incoming calls do not complete. I ran WireShark on the input to the router and I see TCP SYN coming in from the VOIP provider and my firewall is sending back a TCP RST. I then ran Wireshark on the output of the router and there are no port 5060 external packets coming in. I then set up Port Forwarding using LuCI:

config redirect
        option src_dport '5060'
        option dest_ip '192.168.1.98'
        option src_port '5060'
        option src 'wan'
        option name 'twilio-asburn'
        option dest_port '5060'
        option dest 'lan'
        option target 'DNAT'
        list proto 'tcp'
        list proto 'udp'
        option reflection '0'
        option src_ip '54.172.60.0/30'

config redirect
        option src_dport '5060'
        option dest_ip '192.168.1.98'
        option src_port '5060'
        option src 'wan'
        option name 'twilio-umtilla'
        option dest 'lan'
        option dest_port '5060'
        option target 'DNAT'
        list proto 'tcp'
        list proto 'udp'
        option reflection '0'
        option src_ip '54.244.51.0/30'

And I still do not see any port 5060 packets from the router on the local network. Where Is my mistake?

  • Isn't this (TCP) 5061?
  • I'm not sure where you're running Wireshark...but since you need to look at the Internet, you would need to run tcpdump on the OpenWrt - on the WAN interface.

Which firewall, the OpenWrt or the server?

Are you certain the traffic initiates with a SRC port 5060 too?

1 Like

[SOLVED] Incoming calls not reaching hosts on the network - #2 by vgaetera

1 Like

This did not fix the problem, but thanks.

opkg update
opkg install kmod-nf-nathelper-extra
/etc/init.d/firewall restart

cat << EOF >> /etc/sysctl.conf
net.netfilter.nf_conntrack_helper=1
EOF
/etc/init.d/sysctl restart

I don't have much time right now to dig in further but will soon.

No, it is still 5060. SYN; RST were seen on the WAN side of the OpenWRT router. Yes, my VOIP provider is also using port 5060. My OpenWrt router is not passing packets from my VOIP provider.

1 Like

If this is any help:

sysctl net.netfilter.nf_conntrack_helper; \
> iptables-save -c -t raw | grep -e PREROUTING -e sip

net.netfilter.nf_conntrack_helper = 1
:PREROUTING ACCEPT [2760734:2989293911]
[668387:46993304] -A PREROUTING -i br-lan -m comment --comment "!fw3: lan CT helper assignment" -j zone_lan_helper
[2092346:2942300531] -A PREROUTING -i eth1 -m comment --comment "!fw3: wan CT helper assignment" -j zone_wan_helper
[1796:154195] -A zone_lan_helper -p tcp -m comment --comment "!fw3: SIP VoIP connection tracking" -m tcp --dport 5060 -j CT --helper sip
[0:0] -A zone_lan_helper -p udp -m comment --comment "!fw3: SIP VoIP connection tracking" -m udp --dport 5060 -j CT --helper sip
[0:0] -A zone_wan_helper -s 54.172.60.0/30 -d 192.168.1.98/32 -p tcp -m tcp --sport 5060 --dport 5060 -m conntrack --ctstate DNAT -m comment --comment "!fw3: twilio-asburn (CT helper)" -j CT --helper sip
[0:0] -A zone_wan_helper -s 54.244.51.0/30 -d 192.168.1.98/32 -p tcp -m tcp --sport 5060 --dport 5060 -m conntrack --ctstate DNAT -m comment --comment "!fw3: twilio-umtilla (CT helper)" -j CT --helper sip

The logs don't provide anything useful that I can figure out to show. Should this be a bug report? I am still stuck :grimacing:

opkg update
opkg install tcpdump
tcpdump -evni any port 5060

A VoIP client uses port 5060 to contact the VoIP server, but the VoIP server will never use port 5060 to contact the VoIP client. Instead the server uses that port, that the client used to contact the server. So it's normal not to see any incoming traffic to port 5060 at the wan interface.

I have a similar VoIP setup like you, the only difference: instead of asterisk I'm using yate (from the OpenWrt repos). Runs flawlessly since several years (starting with OpenWRT 18.06)

I suspect, you have a mal-configuration with your asterisk software. But this is just a shot in the blue sky.

1 Like

Hi,

SIP is an umbrella of various protocols, there are two major bits:

  1. signalling usually runs via 5060 tcp (less preferably udp) or 5061 tls (a.k.a. Secure SIP). this only covers setup session between two nodes [refer to SIP=Session Initiation Protocol]. It is not mandated by RFC to use 5060 by the way, this is just a habit.
  2. the bearer/payload/media traffic is negotiated via Session Description Protocol (SDP) which uses whatever high ports between media nodes. It can be really whatever, check your VoIP provider and Asterisk config what is used.

Now the problem is that your Asterisk is behind NATed network I guess, sitting on your LAN side and owrt is firewalling your internet connection which is creating a huge problem: in order for media to flow you'll need open UDP ports negotiated via SDP dynamically or open a huge range of ports statically, e.g. Cisco by default using port range of UDP 16000-32000 for media. You probably don't want to open such huge range.

So, if you know your VoIP provider's and Asterisk's UDP range you can accordingly statically open all ports [I really not recommending] and this will work. But the very moment you make direct calls to someone else, i.e. not via your VoIP provider but directly between two SIP clients, which you can, no service provider is per definition required, you'll got a new problem: you may need to open new UDP port range depending on the other end's config. Thus if you want to be able to talk with anybody you'll need to open all high ports at the end ...

And there is the problem of being NATed: your internal IP address which is reported by your client as the media end point is not visible on the public network, it is hidden by your WAN IP so SIP clients will fail to communicate to each other.

So I suggest to check how STUN works or use Session Border Controller (SBC), it will help you to automatically change IP address in SDP messages in both direction and can help dynamically pin hole necessary (and only the necessary ports) in firewall. SBC will also provide various other security measure, e.g. protecting from DOS, malformed SIP attacks etc etc.

good luck.

1 Like

Yes, Asterisk is behind the NATed network on the OpenWRT firewall. I could be wrong but my understanding is that for incoming TCP calls Twilio will Initiate the call to my Asterisk with a 3 way handshake from port 5060. That is the only port that is needed to be opened for the connection to be initiated from Twilio. I have been trying to open that port only for their packets.

I am not worried, at this time, about random SIP calls from other locations so I don't need to open lots of ports.

I am assuming that the RTP packets will still be using UDP and If I get the incoming SIP packets working then it should not be too much of a problem to get RTP to work.

I am not very familiar with them and will look into them when I get this problem fixed.

14:20:34.914431  In e8:a2:45:bc:be:18 ethertype IPv4 (0x0800), length 76: (tos 0x10, ttl 237, id 51003, offset 0, flags [DF], proto TCP (6), length 60)
    54.172.60.2.37507 > 152.36.139.242.5060: Flags [S], cksum 0x14bb (correct), seq 139074933, win 29200, options [mss 1460,sackOK,TS val 1343688274 ecr 0,nop,wscale 7], length 0
14:20:34.914612 Out 74:44:01:76:39:61 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    152.36.139.242.5060 > 54.172.60.2.37507: Flags [R.], cksum 0x4d04 (correct), seq 0, ack 139074934, win 0, length 0
14:20:38.942915  In e8:a2:45:bc:be:18 ethertype IPv4 (0x0800), length 76: (tos 0x10, ttl 223, id 62419, offset 0, flags [DF], proto TCP (6), length 60)
    54.244.51.2.41253 > 152.36.139.242.5060: Flags [S], cksum 0x3b77 (correct), seq 2028693719, win 29200, options [mss 1460,sackOK,TS val 2142107153 ecr 0,nop,wscale 7], length 0
14:20:38.943097 Out 74:44:01:76:39:61 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    152.36.139.242.5060 > 54.244.51.2.41253: Flags [R.], cksum 0x8b16 (correct), seq 0, ack 2028693720, win 0, length 0

Hope that helps! I believe I copied all the applicable lines. The 54... packets are from Twilio. The 152... packets are my public IP.

There were packets before this but I believe they are just the normal handshakes/ keep-alive packets. Well, I have attached a set of them below any way.

14:20:29.930622  In e8:a2:45:bc:be:18 ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl 227, id 64247, offset 0, flags [DF], proto TCP (6), length 52)
    54.244.51.0.5060 > 152.36.139.242.38637: Flags [.], cksum 0x4494 (correct), ack 1203087159, win 1416, options [nop,nop,TS val 2592498059 ecr 1576703569], length 0
14:20:29.930743 Out 76:44:01:76:39:60 ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl 226, id 64247, offset 0, flags [DF], proto TCP (6), length 52)
    54.244.51.0.5060 > 192.168.1.98.38637: Flags [.], cksum 0xa6a4 (correct), ack 1203087159, win 1416, options [nop,nop,TS val 2592498059 ecr 1576703569], length 0
14:20:29.930770 Out 76:44:01:76:39:60 ethertype IPv4 (0x0800), length 68: (tos 0x10, ttl 226, id 64247, offset 0, flags [DF], proto TCP (6), length 52)
    54.244.51.0.5060 > 192.168.1.98.38637: Flags [.], cksum 0xa6a4 (correct), ack 1, win 1416, options [nop,nop,TS val 2592498059 ecr 1576703569], length 0
14:20:29.930852  In 10:78:d2:e9:d4:24 ethertype IPv4 (0x0800), length 68: (tos 0x60, ttl 64, id 59012, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.98.38637 > 54.244.51.0.5060: Flags [.], cksum 0xa47a (correct), ack 1, win 1968, options [nop,nop,TS val 1576765389 ecr 2592436240], length 0
14:20:29.930852  In 10:78:d2:e9:d4:24 ethertype IPv4 (0x0800), length 68: (tos 0x60, ttl 64, id 59012, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.98.38637 > 54.244.51.0.5060: Flags [.], cksum 0xa47a (correct), ack 1, win 1968, options [nop,nop,TS val 1576765389 ecr 2592436240], length 0
14:20:29.930910 Out 10:78:d2:e9:d4:24 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 59012, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.98.38637 > 54.244.51.0.5060: Flags [.], cksum 0xa47a (correct), ack 1, win 1968, options [nop,nop,TS val 1576765389 ecr 2592436240], length 0
14:20:29.931002 Out 74:44:01:76:39:61 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 63, id 59012, offset 0, flags [DF], proto TCP (6), length 52)
    152.36.139.242.38637 > 54.244.51.0.5060: Flags [.], cksum 0x426a (correct), ack 1, win 1968, options [nop,nop,TS val 1576765389 ecr 2592436240], length 0

I think you're wrong: 5060 is the listening port, Twilio will Initiate call signalling to your Asterisk onto destination port 5060, not from! Try without limiting source port, only specify destination port 5060.

1 Like

You are correct, it is the destination port that is 5060! LuCI won't let me leave the destination port blank so I said !5060 (NOT 5060) for the source port. The red text in LuCI says either negation or range. I tried a range but it didn't like it for some reason so I went with negation.

# sysctl net.netfilter.nf_conntrack_helper; \
>  iptables-save -c -t raw | grep -e PREROUTING -e sip
net.netfilter.nf_conntrack_helper = 1
:PREROUTING ACCEPT [9966:3041331]
[5254:558621] -A PREROUTING -i br-lan -m comment --comment "!fw3: lan CT helper assignment" -j zone_lan_helper
[4712:2482710] -A PREROUTING -i eth1 -m comment --comment "!fw3: wan CT helper assignment" -j zone_wan_helper
[94:7884] -A zone_lan_helper -p tcp -m comment --comment "!fw3: SIP VoIP connection tracking" -m tcp --dport 5060 -j CT --helper sip
[0:0] -A zone_lan_helper -p udp -m comment --comment "!fw3: SIP VoIP connection tracking" -m udp --dport 5060 -j CT --helper sip
[0:0] -A zone_wan_helper -s 54.172.60.0/30 -d 192.168.1.98/32 -p tcp -m tcp ! --dport 5060 -m conntrack --ctstate DNAT -m comment --comment "!fw3: twilio-asburn (CT helper)" -j CT --helper sip
[0:0] -A zone_wan_helper -s 54.244.51.0/30 -d 192.168.1.98/32 -p tcp -m tcp --dport 5060 -m conntrack --ctstate DNAT -m comment --comment "!fw3: twilio-umtilla (CT helper)" -j CT --helper sip

I essentially got the same response when I called my phone - SYN, RST:

# tcpdump -evni any port 5060
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
18:09:05.676639  In e8:a2:45:bc:be:18 ethertype IPv4 (0x0800), length 76: (tos 0x10, ttl 235, id 62984, offset 0, flags [DF], proto TCP (6), length 60)
    54.172.60.3.41617 > 152.36.139.242.5060: Flags [S], cksum 0xf93a (correct), seq 2890371644, win 29200, options [mss 1460,sackOK,TS val 4120402812 ecr 0,nop,wscale 7], length 0
18:09:05.676821 Out 74:44:01:76:39:61 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    152.36.139.242.5060 > 54.172.60.3.41617: Flags [R.], cksum 0x2430 (correct), seq 0, ack 2890371645, win 0, length 0
18:09:09.770014  In e8:a2:45:bc:be:18 ethertype IPv4 (0x0800), length 76: (tos 0x10, ttl 228, id 31260, offset 0, flags [DF], proto TCP (6), length 60)
    54.244.51.1.39135 > 152.36.139.242.5060: Flags [S], cksum 0x0ac7 (correct), seq 2915749221, win 29200, options [mss 1460,sackOK,TS val 2339998159 ecr 0,nop,wscale 7], length 0
18:09:09.770187 Out 74:44:01:76:39:61 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    152.36.139.242.5060 > 54.244.51.1.39135: Flags [R.], cksum 0xf9ef (correct), seq 0, ack 2915749222, win 0, length 0
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Under LuCI - > Network -> Firewall -> Port forwards if I create a new rule to redirect traffic targeting port 44440 on WAN interface to my internal server listening on port 44441 this is the generated firewall rule:

config redirect
        option target 'DNAT'
        option name 'Test'
        option src 'wan'
        option src_dport '44440'
        option dest 'lan'
        option dest_ip '192.168.1.xx'
        option dest_port '44441'

-A zone_wan_prerouting -p tcp -m tcp --dport 44440 -m comment --comment "!fw3: Test" -j DNAT --to-destination 192.168.1.xx:44441
-A zone_wan_prerouting -p udp -m udp --dport 44440 -m comment --comment "!fw3: Test" -j DNAT --to-destination 192.168.1.xx:44441

So not sure what you mean "destination port blank is disallowed" and why you think it is strange: that's the whole point, anybody from public internet connecting to your owrt device on port X on WAN side, i.e. to destination port X from source point of view, will be redirected to internal server on port Y, i.e. to the real destination port.

So in your case simply set followings:

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option dest_ip '192.168.1.xx
        option name 'SIP Signalling'
        list proto 'tcp'
        option src_dport '5060'
        option dest_port '5060'

-A zone_wan_prerouting -p tcp -m tcp --dport 5060 -m comment --comment "!fw3: SIP Signalling" -j DNAT --to-destination 192.168.1.xx:5060

Once signalling is working and your SIP trunk/client via Asterisk can establish connection, enable SIP OPTION ping to make sure it is reliable (and if your provider allows). Then you can think about how media should be sort out: as said you open a fixed udp range what your provider configured, or use e.g. STUN.

I removed the following in Port Forwarding - Advanced Settings:

Match helper:    SIP VoIP connection tracking (SIP)

I then removed

kmod-nf-nathelper-extra

That was a Red Herring.

And now I can successfully call my phone number!!! :grinning_face_with_smiling_eyes:

I guess I was not really understanding the port issue with LuCI's port forwarding

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.