Hi Alexander,
I removed the protocol restrictions. Once more it was proved that for TCP/TLS there are still dark zones which have evaded us so far :) Let's be cautious!! ;)
thanks for the help in troubleshooting
regards, bogdan
Alexander Ph. Lintenhofer wrote:
If not, I vote for changing it. Then it will work for the only person
who uses it ...maybe there will be a little more people in the future using TLS (therefore TCP) and sitting behind NAT.....
Nevertheless thank you for this great work, OpenSER-Team!
regards, Philipp
Bogdan-Andrei Iancu wrote:
ok.....
so fixing this bug it means just removing a line.....does somebody has any objection is I fix it now on the last 100 meters :D ?
Is anybody out there using TCP and relays on the "not working feature" of fix_nated_contact?
If not, I vote for changing it. Then it will work for the only person who uses it ;-)
klaus
regards, bogdan
Alexander Ph. Lintenhofer wrote:
.... and it is not really a big deal to implement it :-)
regards, Philipp
Bogdan-Andrei Iancu wrote:
Hi Alexander,
sound like a solid reason. It means that the solution will be to allow fix_nated_contact() for TCP based protos. any other suggestions?
I think it should be fine to allow fix_nated_contact() also for TCP/TLS (to have correct alias mapping)
regards klaus
regards, bogdan
Alexander Philipp Lintenhofer wrote:
> Hi Bogdan, > > This is the answer, Andrei gave me: > "....ser aliases only the ports, it never adds an alias for an > IP (security risk)....." > > I think, he means TCP-hijacking in the case of a > modificated/malformed via-header. > > regards, > Philipp > >> Hi Alexander, >> >> indeed, it seams you have case. Even if the draft says that the >> alias tuple must include the VIA ip:port, currently the IP is >> considered as received IP. Why? not sure (is Andrei's work), >> but I can speculate on the overhead introduce in getting the >> address from via and convert it to IP (via may contain DNS name >> which should be resolved!). >> >> If we go ahead on this road, right, you need a way to set the >> NAT IP in the contact -> use fix_nated_contact() which does not >> support TCP :D. I do not like this approach because the alias >> is a mixture between the NAT IP and the inside port :/ >> >> If we go as the draft says, and use via ip:port we have to face >> the need of performing DNS lookup only to generate the alias >> ....this is even uglier and more dangerous. and also we will >> end having private IPs in RURIs and in aliases..which is a >> little bit tricky - a private IP is not unique ;). >> >> so, I would say the best way is the first one....and to allow >> fix_nated_contact() also for TCP/TLS......... >> >> regards, >> bogdan >> >> >> >> Alexander Ph. Lintenhofer wrote: >> >>> Hi All, >>> >>> I just wanted to ask you once again about the TCP-alias >>> riddle. I found out, that there is a problem with the >>> combination of fix_nated_contact(), force_tcp_alias() and NAT: >>> >>> Imagine following situation: >>> >>> Alice behind NAT: socket 172.16.0.6:2421 >>> Nat-Box translates this to 192.168.0.13:6007 >>> >>> The Outbound-Proxy of Alice is 192.168.0.1 >>> >>> Bob is registered with 192.168.1.1 >>> >>> 1.) >>> Her INVITE: >>> ==================================================================== >>> >>> INVITE sip:bob@192.168.1.1:2331;transport=tcp;line=wxqurd1s >>> SIP/2.0 >>> [...] >>> Via: SIP/2.0/TCP 172.16.0.6:2421;received=192.168.0.13; >>> branch=z9hG4bK-wm9jcstcboys;rport=6007 >>> From: "Alice" sip:alice@atlanta.com;tag=sufzmxi0us >>> To: "Bob" sip:bob@biloxi.com;tag=c9550czwtn >>> [...] >>> Contact: sip:alice@172.16.0.6:2421;transport=tcp;line=fyyuh6tl >>> [...] >>> ==================================================================== >>> >>> >>> 2.) >>> fix_nated_contact() doesn't work with TCP (look at nathelper.c). >>> force_tcp_alias() now creates following tuple as TCP-alias: >>> 192.168.0.13:6007 to 192.168.0.13:2421 >>> >>> Reason: >>> The TCP-alias is not built solely from the Via-header as >>> suggested in the draft. The portnumber is taken from the >>> Via-header and the IP-address is taken from the source of the >>> incoming datagram. I read it in the sourcecode and assured it >>> by contacting Andrei! >>> >>> 3.) >>> So as a result of the notfixed Contact-header of Alice's >>> INVITE the BYE of Bob is addressed to 172.16.0.6:2421. But no >>> TCP-alias exists for this socket :-( >>> >>> 4.) >>> I made following test by rewriting the Contact-header.... >>> ==================================================================== >>> >>> if (method=="INVITE") >>> { >>> replace("Contact: sip:alice@172.16.0.6:2421;transport=tcp;", >> "Contact: >>> sip:alice@192.168.0.13:2421;transport=tcp;"); >> } >>> ==================================================================== >>> >>> ...with success. Now TCP-alias works as you can see on my >>> Ethereal-trace below! >>> Compare the destination port of the packet to the destination >>> port of the RURI! >>> ==================================================================== >>> >>> [...] >>> Transmission Control Protocol, Src Port: 5060 (5060), Dst >>> Port: 6007 (6007), ... >>> Session Initiation Protocol >>> Request-Line: BYE >>> sip:alice@192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0 >>> Message Header >>> [...] >>> From: "Bob" sip:bob@biloxi.com;tag=kcsveifugd >>> To: "Alice" sip:alice@atlanta.com;tag=ricaq5cy15 >>> Contact: sip:bob@192.168.1.1:2331;transport=tcp;line=wxqurd1s >>> [...] >>> ==================================================================== >>> >>> >>> Another solution: >>> Comment the lines in nathelper.c which force the return in >>> case of TCP or TLS. Now all works well! >>> >>> But why?????????????? >>> >>> regards, >>> Philipp >> >> >> >>