Discussion:
Disable port translation in SNAT
James Lamanna
2014-07-24 12:13:46 UTC
Permalink
Hi,
Is there a way to disable port translation during SNAT so that traffic
originates from the same external port as it did internally?
I realize that this might be able to be done with a separate SNAT rule for
each port, but I have a port range of 50 or so (RTP) so I'm wondering if
it's possible to do on a range basis.

Thanks.

--James
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pascal Hambourg
2014-07-24 18:43:03 UTC
Permalink
Hello,
Hi,
Is there a way to disable port translation during SNAT so that traffi=
c
originates from the same external port as it did internally?
When possible this is already the default when you don't specify a port
range nor --random. From the man page :

--to-source ipaddr[-ipaddr][:port-port]
which can specify a single new source IP address, an inclusive
range of IP addresses, and optionally, a port range (which is
only valid if the rule also specifies -p tcp or -p udp). If no
port range is specified, then source ports below 512 will be
mapped to other ports below 512: those between 512 and 1023
inclusive will be mapped to ports below 1024, and other ports
will be mapped to 1024 or above. Where possible, no port alter-
ation will occur.

Sometimes the source port must be translated in order to avoid a
conflict with an existing connection to the same destination which
already uses that source port.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
James Lamanna
2014-07-24 19:09:09 UTC
Permalink
Hi,
I have one device (an IP phone) on an AirRouter (based on linux, uses i=
ptables).
it still is translating ports in the 16000 range all the way down to 10=
25, which breaks RTP (it apparently doens't have very good SIP/SDP=20
conn-tracking on it).

That's why I was a bit puzzled as to why it keeps translating the ports=
down to the low 1000s. I had thought it was the default to preserve it=
=2E

-- James
Post by Pascal Hambourg
Hello,
Hi,
Is there a way to disable port translation during SNAT so that traff=
ic
Post by Pascal Hambourg
originates from the same external port as it did internally?
When possible this is already the default when you don't specify a po=
rt
Post by Pascal Hambourg
--to-source ipaddr[-ipaddr][:port-port]
which can specify a single new source IP address, an inclusiv=
e
Post by Pascal Hambourg
range of IP addresses, and optionally, a port range (which i=
s
Post by Pascal Hambourg
only valid if the rule also specifies -p tcp or -p udp). If n=
o
Post by Pascal Hambourg
port range is specified, then source ports below 512 will b=
e
Post by Pascal Hambourg
mapped to other ports below 512: those between 512 and 1023
inclusive will be mapped to ports below 1024, and other port=
s
Post by Pascal Hambourg
will be mapped to 1024 or above. Where possible, no port alter=
-
Post by Pascal Hambourg
ation will occur.
Sometimes the source port must be translated in order to avoid a
conflict with an existing connection to the same destination which
already uses that source port.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pascal Hambourg
2014-07-27 07:53:13 UTC
Permalink
Hi,
I have one device (an IP phone) on an AirRouter (based on linux, uses=
iptables).
it still is translating ports in the 16000 range all the way down to =
1025,
which breaks RTP (it apparently doens't have very good SIP/SDP=20
conn-tracking on it).
Can you indicate the kernel version running on that router, and the
exact SNAT rule ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loading...