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 > > >