Summary:	ASTERISK-24149: Routing problems on firewall with chan_pjsip packets on port 5060 (chan_sip and/or other port working)
Reporter:	Martin (martin_g)	Labels:
Date Opened:	2014-07-31 11:57:39	Date Closed:	2014-09-04 20:15:30
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_pjsip
Versions:	12.4.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS 6.5 FreePBX 12.0.1beta29 Asterisk 12.4 openVZ Container on Proxmox 3.1	Attachments:	( 0) info_1.txt ( 1) issue_24149_1.cap ( 2) issue_24149_full_log_1
Description:	Have a very weird bug on routing  chan_pjsip on the firewall. I thought it is a firewall/router problem but other ports than 5060 work and chan_sip works also on 5060. Short: My phone is behind a SNAT attached to a bridge to the servernet and registers well. When I try to call the phone, the SNAT is reverted correctly but the SIP/Invite packet is not routed to the correct interface. Exactly same constellation works with chan_sip and with other ports tzhan 5060 (e.g. 5061 or 5000). Firewall rules are the same for 5060 and 5061. Long: If it is okay, I would refer to this thread, it is explained there: http://community.freepbx.org/t/differences-in-nat-between-chan-sip-and-pjsip/23394 If not, I will write one more summary. I know it sounds like a problem on the router/firewall, but there really is no special configuration. If there were a problem with port 5060 I think chan_sip would not work either. Are there any differences in packet construction between these sip stacks? I compared both invite packets in tcpdump/wireshark but I could not see a really offending problem. In pjsip the DF flag is set and the packet is larger than in sip, but is shorter than the MTU (1500). About 1120B length.
Comments:	By: Matt Jordan (mjordan) 2014-07-31 14:00:52.233-0500 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information For both situations, please provide the output with 'sip set debug on' and 'pjsip set logger on'. We'll need to inspect the differences in the packets and where the channel driver/stack sent the packet to. By: Martin (martin_g) 2014-08-01 01:37:53.675-0500 Attached the Logfile, an infofile and a Wireshark viewable Dump done on the Firewall By: Rusty Newton (rnewton) 2014-08-08 17:34:16.528-0500 I took a look, I don't see a reason the PJSIP packet would be routed differently. Though I'm more of a generalist and not specifically a SIP expert. I'll ping a SIP expert to take a look. By: Matt Jordan (mjordan) 2014-08-13 09:59:19.942-0500 I'm going to go out on a limb and say that this isn't just a firewall but a SIP ALG in the mix here, since the destination IP address and port are the same for both packets sent by {{chan_sip}} and {{chan_pjsip}}. There is one major difference in the two SIP packets sent by {{chan_sip}}/{{chan_pjsip}} - that being the {{Contact}} header. I'm curious: does your firewall/ALG provide any information when the PJSIP packet hits it? By: Martin (martin_g) 2014-08-13 10:15:57.172-0500 Can you tell me which line seems wrong? I´m not a SIP expert, there is too much output for me. Which information should the firewall provide? It´s a regular Debian Etch server with iptables firewall. I didn´t see any "kernel panic" or something like this. I can log whatever you want to be logged in the iptables script. But I don´t think it is a real decision of the iptables script not to route this packet. Did you have a look into the packetdump? It´s a dump captured with tcpdump and viewable with wireshark. It is captured on the firewall. By: Martin (martin_g) 2014-08-13 10:49:01.776-0500 I do not know which feedback you need. I commented that firewall does no kernel panic or similar message. By: Matt Jordan (mjordan) 2014-08-14 10:39:42.516-0500 Yes, I looked at the pcap, hence why I commented that the only difference between the two packets is the {{Contact}} header. Let's look at your issue description: {quote} Have a very weird bug on routing chan_pjsip on the firewall. I thought it is a firewall/router problem but other ports than 5060 work and chan_sip works also on 5060. Short: My phone is behind a SNAT attached to a bridge to the servernet and registers well. When I try to call the phone, the SNAT is reverted correctly but the SIP/Invite packet is not routed to the correct interface. Exactly same constellation works with chan_sip and with other ports tzhan 5060 (e.g. 5061 or 5000). Firewall rules are the same for 5060 and 5061. {quote} From that, you're telling us that: # {{chan_pjsip}} works on all ports but 5060. # {{chan_sip}} works on all ports. So the only time things fail to work is when {{chan_pjsip}} sends to port 5060. Looking at your pcap, there are no ICMP destination unreachable errors. When transmitting to port 5060, using both {{chan_sip}} and {{chan_pjsip}}, Asterisk sends to the same destination address. The request lines are effectively the same; the {{From}} and {{To}} headers appear to be effectively the same. The only difference is in the {{Contact}} header, where {{chan_sip}} uses a much shorter user identifier in the URI and {{chan_pjsip}} ... does not. A firewall doesn't explain this issue. If there was a firewall involved, I'd expect to see a Destination unreachable ICMP packet when {{chan_pjsip}}'s request gets bounced off. A SIP ALG *does* explain this, as a SIP ALG may choose to kill a packet in the router when it inspects the headers. Hence: do you have an ALG in your router? Is it turned on? Is it displaying anything? Right now, I don't know why the ALG would kill the packet. It _may_ be because of the Contact header in the packet that {{chan_pjsip}} sent out; it may not. Without further information, however, this bug will be closed. We aren't going to change things randomly in Asterisk in the vain hopes that something works. By: Rusty Newton (rnewton) 2014-09-04 20:17:43.340-0500 If you find more information that leads you to believe this is a bug, you can discuss with a bug marshal in #asterisk-bugs on irc.freenode.net and we may reopen the issue. Closed for now, as we don't have anything to move forward with here.