6 Oct
2016
6 Oct
'16
4:35 p.m.
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
6 Oct
6 Oct
4:38 p.m.
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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
7 Oct
7 Oct
9:30 a.m.
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
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
10:37 a.m.
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(a)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
3:13 p.m.
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
10 Oct
10 Oct
1:15 p.m.
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
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
2764
days inactive
2768
days old
5 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Dirk Teurlings - Signet B.V.