How to make bi-directional NAT'ting?

How to make bi-directional NAT'ting?

["Яцко Эллад Геннадьевич (ngs)"]

Hello!

I have some specific problem with Cisco CP7961G IP phone.
It sends packets to external Softswitch using one UDP port
which differs from 5060 (voipControlPort in its .XML), but
it waits answers on 5060!
And I can't do anything with it! I have tried Firmware from
8.0.x up to 8.5.x - all the same!

One thing I think is make corresponding translation on IPTables.
SNAT in direct path (from 79161 to Softswitch) and DNAT
in backward direction (from outside Softswitch to 7961).

BUT IT DOESN'T WORK! :-)

$IPTABLES -t nat -A PREROUTING          -p udp -s 80.251.x.x 
                         -d 80.251.y.y --dport 5060 -j DNAT 
--to-destination 172.16.128.200:5060
$IPTABLES -t nat -A POSTROUTING -o eth0 -p udp -s 172.16.128.0/24 
--sport 1024:65535 -d 80.251.x.x --dport 5060 -j SNAT --to-source      
80.251.y.y:5060

What do I do wrong?

Kind regards,
Ellad Yatsko

Re: How to make bi-directional NAT'ting?

[Tyler J. Wagner]

On 2011-08-23 09:26, "яцко Ёллад √еннадьевич (ngs)" wrote:
> Hello!
> 
> I have some specific problem with Cisco CP7961G IP phone.
> It sends packets to external Softswitch using one UDP port
> which differs from 5060 (voipControlPort in its .XML), but
> it waits answers on 5060!
> And I can't do anything with it! I have tried Firmware from
> 8.0.x up to 8.5.x - all the same!
> 
> One thing I think is make corresponding translation on IPTables.
> SNAT in direct path (from 79161 to Softswitch) and DNAT
> in backward direction (from outside Softswitch to 7961).
> 
> BUT IT DOESN'T WORK! :-)
> 
> $IPTABLES -t nat -A PREROUTING          -p udp -s 80.251.x.x
>                         -d 80.251.y.y --dport 5060 -j DNAT --to-destination
> 172.16.128.200:5060
> $IPTABLES -t nat -A POSTROUTING -o eth0 -p udp -s 172.16.128.0/24 --sport
> 1024:65535 -d 80.251.x.x --dport 5060 -j SNAT --to-source      80.251.y.y:5060

SIP is difficult to correct with NAT. It includes connection data at layer
7. So the Softswitch may be ignoring packet headers and replying to that.

I don't think NAT is your solution here. Something else is wrong in the SIP
setup of this device.

Regards,
Tyler

-- 
"[...] the effectiveness of pat-downs does not matter very much, because
the obvious goal of the TSA is to make the pat-down embarrassing enough
for the average passenger that the vast majority of people will choose
high-tech humiliation over the low-tech ball check."
   -- Jeffrey Goldberg, "For the First Time, the TSA Meets Resistance"
      The Atlantic, 2010-10-29

Re:

[Tyler J. Wagner]

On 2011-08-23 12:08, Ellad Yatsko wrote:
> Main problem is DNAT does not work as I wait. It seems to me there is an
> implicit additional
> DNAT rule for SNAT, and because *my* DNAT rule does not work. May you show
> me how it
> could be "switched off"? :-)

It's not an implicit rule. If either rule matches the FIRST time the
traffic is seen, it will become an established connection. NAT will be
applied to it in both directions. See the current list of tracked
connections with:

cat /proc/net/ip_conntrack

Don't run that on a system with a lot of traffic. You'll get one line for
each session. For 1000 sessions, that's manageable. For 500,000, it will
block the terminal for a long time.

Regards,
Tyler

-- 
"The map is not the territory."
   -- Alfred Korzybski

Re:

[Jan Engelhardt]

On Tuesday 2011-08-23 13:35, Tyler J. Wagner wrote:

>On 2011-08-23 12:08, Ellad Yatsko wrote:
>> Main problem is DNAT does not work as I wait. It seems to me there is an
>> implicit additional
>> DNAT rule for SNAT, and because *my* DNAT rule does not work. May you show
>> me how it
>> could be "switched off"? :-)
>
>It's not an implicit rule. If either rule matches the FIRST time the
>traffic is seen, it will become an established connection. NAT will be
>applied to it in both directions. See the current list of tracked
>connections with:
>
>cat /proc/net/ip_conntrack
>
>Don't run that on a system with a lot of traffic. You'll get one line for
>each session. For 1000 sessions, that's manageable. For 500,000, it will
>block the terminal for a long time.

That's why one normally uses conntrack -L | less so that that does not 
happen.

Re:

[Tyler J. Wagner]

On 2011-08-24 08:35, Jan Engelhardt wrote:
>> Don't run that on a system with a lot of traffic. You'll get one line for
>> each session. For 1000 sessions, that's manageable. For 500,000, it will
>> block the terminal for a long time.
> 
> That's why one normally uses conntrack -L | less so that that does not 
> happen.

Unfortunately, conntrack isn't installed by default on a lot of
distributions. Just "less /proc/..." will do the same.

Regards,
Tyler

-- 
"Religion is the opiate of the masses, so long as the masses are straight.
However, amass a bunch of lesbians and you're going to need actual drugs."
   -- OKCupid Blog, with apologies to Karl Marx
      http://blog.okcupid.com/index.php/gay-sex-vs-straight-sex/