Jason Opperisano wrote:
free, seems current, not sure if it meets your requirements:
http://siproxd.sourceforge.net/index.php
It very well could... I've been playing with it, but my ultimate goal for this is to put the result onto a Linksys WRT54G/GS running the Sveasoft customized firmware. There are versions of siproxd built for that box, but I am not yet comfortable that it's reliable enough to deploy to client sites (siproxd, that is).
explain to me how the above rules would not successfully forward the UDP traffic to your server, because i must be missing something. whether or not it's how you would *like to do it* is immaterial.
Well, unless I'm misunderstanding, the rules you posted will not work in this application because:
1) You are forwarding all inbound UDP traffic to a single device. My example was simplified; the final application for this technique could have tens of phones behind the NAT, each needing to work this way. That's why I phrased my original request the way I did; it was predicated on learning the outbound port number and other bits related to a specific "connection" (even though this is UDP) and basing the inbound rules on those details.
2) You assume that the port number assigned when the phone sends out its first UDP packet (from port 4000) by the NAT will also be 4000... it very well may not be, if that port is already in use on the public side of the NAT for another user. In that case, the FORWARD rule can't work, because it doesn't know what port number the conntrack code assigned for this specific connection (and it could be different for the next connection).
I'll spend some more time working with siproxd to see if it can do what I need. If not, I suppose it would be possible to create a netfilter module that watched for the outbound UDP and created a RELATED connection with the appropriate inbound rule. It wouldn't have to peek into the packets at all, just use the information already present in the conntrack structures.
