Hi,
Looking at an issue with SIP-Cisco and a Barracuda firewall, I've come across something I need to know more about.
The setup is as follows: CLIENT -> KAMAILIO -> ASTERISK CLIENT <- KAMAILIO <- ASTERISK
Client sends INVITE, Kamailio forwards to Asterisk, SIP 100 and SIP 183 are being sent and finally a 200 OK. We now expect the Client to send back an ACK packet, but that never reaches us.
In this case the SIP 183 is the first packet that contains the full record route of the path, the 200 OK contain the same record-routes being:
Record-Route: sip:192.168.0.200;r2=on;lr;ftag=12D1120C-1C4;did=4c8.9203;nat=yes Record-Route: sip:1.2.3.4;r2=on;lr;ftag=12D1120C-1C4;did=4c8.9203;nat=yes Record-Route: sip:4.3.2.1;r2=on;lr;did=4c8.3f471377 Record-Route: sip:10.0.0.101;r2=on;lr;did=4c8.3f471377
192.168.0.200 is the private address of Kamailio 1.2.3.4 is the public address of Kamailio 4.3.2.1 is the public address of the Client 10.0.0.101 is some private addres of the Client
What we're seeing is that the Client is sending his ACK message to our 192.169.200 private address, which he will never reach. So me question in this case is; is the order of the Record-route headers relevant and do I have any say in which order Kamailio outputs these headers?
To be clear, the Kamailio config only contains one reference to record_route which is caught for INVITE messages, which only fires when all things like NAT and transaction checks haven't already picked it up.
Kind regards, Dirk
The order of the Record-Route headers is very relevant, and must strictly correspond to the order in which the intermediate proxy chain is traversed. The RR header of the Kamailio closest to your Client will be at the top of the RR stack, and this will be the first hop in the Route set used in in-dialog requests (e.g. end-to-end ACKs, BYEs, reinvites).
Thus, it is entirely appropriate that your client is trying to send the ACK to 192.168.0.200 on the network/transport layer.
-- Alex
I think the Route set as presented in the first email is correct. The Client is also having a proxy, so the caller device has to use the Route set from bottom up, sending first to its proxy, which should send to Kamailio's public IP. If the caller device is sending directly to kamailio, then there is something wrong with that device.
Cheers, Daniel
On 06/10/16 16:38, Alex Balashov wrote:
The order of the Record-Route headers is very relevant, and must strictly correspond to the order in which the intermediate proxy chain is traversed. The RR header of the Kamailio closest to your Client will be at the top of the RR stack, and this will be the first hop in the Route set used in in-dialog requests (e.g. end-to-end ACKs, BYEs, reinvites).
Thus, it is entirely appropriate that your client is trying to send the ACK to 192.168.0.200 on the network/transport layer.
-- Alex
This was also my understanding. But as you can understand I want to be certain. Currently this issue only rises with the Cisco hardware in combination with the Barracuda firewall. Other appliances seem to respect the order properly.
On 07-10-16 09:30, Daniel-Constantin Mierla wrote:
I think the Route set as presented in the first email is correct. The Client is also having a proxy, so the caller device has to use the Route set from bottom up, sending first to its proxy, which should send to Kamailio's public IP. If the caller device is sending directly to kamailio, then there is something wrong with that device.
To be complete, this is the entire message:
Via: SIP/2.0/UDP 4.3.2.1:5060;rport=5060;branch=z9hG4bK397b.fc14665.0 Via: SIP/2.0/UDP 10.0.1.50:5060;rport=57093;received=10.0.1.50;branch=z9hG4bK60450F49 Record-Route: sip:192.168.0.200;r2=on;lr;ftag=12D1120C-1C4;did=4c8.9203;nat=yes Record-Route: sip:1.2.3.4;r2=on;lr;ftag=12D1120C-1C4;did=4c8.9203;nat=yes Record-Route: sip:4.3.2.1;r2=on;lr;did=4c8.3f471377 Record-Route: sip:10.0.0.101;r2=on;lr;did=4c8.3f471377 From: +2233445566 sip:user@sip.domain.net;tag=12D1120C-1C4 To: sip:12345678@sip.domain.net;tag=as70bcd8b2 Call-ID: 6A54E603-894E11E6-8784FA54-A855A3EA@10.0.1.50 CSeq: 102 INVITE Server: sip.domain.net Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: sip:+2233445566@192.168.0.201:5060 Content-Type: application/sdp Content-Length: 237
v=0 o=charles 2051523742 2051523742 IN IP4 1.2.3.4 s=sip.domain.net c=IN IP4 1.2.3.4 t=0 0 m=audio 13772 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv
Cheers, Dirk
Got an update on this from the firewall's perspective. Apparently the Barracuda was in (SIP) Proxy mode. After turning that off and just using plain NAT everything worked like expected.
Cheers, Dirk
On 07/10/16 15:13, Dirk Teurlings - Signet B.V. wrote:
Got an update on this from the firewall's perspective. Apparently the Barracuda was in (SIP) Proxy mode. After turning that off and just using plain NAT everything worked like expected.
No surprise to get SIP traffic messed up by a firewall ALG...
Cheers, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla -
Dirk Teurlings - Signet B.V.