bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 17:01 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
cfilin@intermedia.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |chip@innovates.com
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 17:01 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
cfilin@intermedia.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |chip@innovates.com
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:11 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From kaber@trash.net 2006-08-03 19:11 MET ------- Which kernel version, any patches applied or helpers loaded? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:11 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From kaber@trash.net 2006-08-03 19:11 MET ------- Which kernel version, any patches applied or helpers loaded? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:11 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From kaber@trash.net 2006-08-03 19:11 MET ------- Which kernel version, any patches applied or helpers loaded? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:13 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From cfilin@intermedia.net 2006-08-03 19:13 MET ------- This problem was seen on kernels 2.6.15 and 2.6.17. iptables version on 2.6.17 was 1.3.5 -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:13 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From cfilin@intermedia.net 2006-08-03 19:13 MET ------- This problem was seen on kernels 2.6.15 and 2.6.17. iptables version on 2.6.17 was 1.3.5 -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:23 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From cfilin@intermedia.net 2006-08-03 19:23 MET ------- Additionally: I was able to catch these RTP packets perfectly fine in tables "mangle" and "filter". But not in table "nat" :( -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:23 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From cfilin@intermedia.net 2006-08-03 19:23 MET ------- Additionally: I was able to catch these RTP packets perfectly fine in tables "mangle" and "filter". But not in table "nat" :( -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:40 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From kaber@trash.net 2006-08-03 19:40 MET ------- Any patches applied (like the RTP or SIP helper)? The NAT table only sees NEW connections, so make sure you don't already have a similar connection in /proc/net/ip_conntrack. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:40 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From kaber@trash.net 2006-08-03 19:40 MET ------- Any patches applied (like the RTP or SIP helper)? The NAT table only sees NEW connections, so make sure you don't already have a similar connection in /proc/net/ip_conntrack. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 19:40 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From kaber@trash.net 2006-08-03 19:40 MET ------- Any patches applied (like the RTP or SIP helper)? The NAT table only sees NEW connections, so make sure you don't already have a similar connection in /proc/net/ip_conntrack. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 20:44 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From cfilin@intermedia.net 2006-08-03 20:44 MET ------- This is a good clue. The trouble is that I configure iptables rules dynamically (using pipe to iptables-restore STDIN) right about the time when the RTP connection started. Question: is there are way to command iptables-restore to have conntrack reset the connections? Thanks -c -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-03 20:44 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From cfilin@intermedia.net 2006-08-03 20:44 MET ------- This is a good clue. The trouble is that I configure iptables rules dynamically (using pipe to iptables-restore STDIN) right about the time when the RTP connection started. Question: is there are way to command iptables-restore to have conntrack reset the connections? Thanks -c -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-04 03:06 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
netfilter@linuxace.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |netfilter@linuxace.com
------- Additional Comments From netfilter@linuxace.com 2006-08-04 03:06 MET
-------
This really is a FAQ. Once a session has entered the conntrack table _without
NAT_, adding rules will not change it to _with NAT_ unless:
1) the session expires
2) you reboot
3) you rmmod the iptables modules
You need to have your NAT rules in place _before_ the traffic is accepted.
Otherwise, you'll get the non-NAT conntrack entry.
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-04 03:06 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
netfilter@linuxace.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |netfilter@linuxace.com
------- Additional Comments From netfilter@linuxace.com 2006-08-04 03:06 MET
-------
This really is a FAQ. Once a session has entered the conntrack table _without
NAT_, adding rules will not change it to _with NAT_ unless:
1) the session expires
2) you reboot
3) you rmmod the iptables modules
You need to have your NAT rules in place _before_ the traffic is accepted.
Otherwise, you'll get the non-NAT conntrack entry.
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-04 03:06 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
netfilter@linuxace.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |netfilter@linuxace.com
------- Additional Comments From netfilter@linuxace.com 2006-08-04 03:06 MET
-------
This really is a FAQ. Once a session has entered the conntrack table _without
NAT_, adding rules will not change it to _with NAT_ unless:
1) the session expires
2) you reboot
3) you rmmod the iptables modules
You need to have your NAT rules in place _before_ the traffic is accepted.
Otherwise, you'll get the non-NAT conntrack entry.
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-06 20:46 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
------- Additional Comments From cfilin@intermedia.net 2006-08-06 20:46 MET
-------
Greetings - I've looked into libnetfilter_conntrack and stole a litle code
from ctnl_test.c:
struct nfct_handle* cth = nfct_open(CONNTRACK, 0);
if (cth) {
int ret = nfct_delete_conntrack(cth, orig, NFCT_DIR_ORIGINAL, NFCT_ANY_ID);
fprintf(stdout, "TEST 6: delete conntrack (%d)\n", ret);
if (ret < 0)
errors++;
nfct_close(cth);
}
else {
fprintf(stderr, "Can't open handler\n");
errors++;
}
to reset the connection in conntrack. I tested and it appears to be
working (per "cat /proc/net/ip_conntrack | grep my.ip.add.ress"
anyway)
Question #1: will this work for my need to make NAT table to see the arriving
packets or rebooting the box or unloading the iptable is really the only
(and unacceptable) way to get this done?
Question #2: With the libnetfilter_conntrack is writing to iptables-restore
STDIN really the best way t ochange the NAT table or there is some user space
API that can get this done without the overhead of a separare process?
Thanks
-c
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-06 20:46 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
------- Additional Comments From cfilin@intermedia.net 2006-08-06 20:46 MET
-------
Greetings - I've looked into libnetfilter_conntrack and stole a litle code
from ctnl_test.c:
struct nfct_handle* cth = nfct_open(CONNTRACK, 0);
if (cth) {
int ret = nfct_delete_conntrack(cth, orig, NFCT_DIR_ORIGINAL, NFCT_ANY_ID);
fprintf(stdout, "TEST 6: delete conntrack (%d)\n", ret);
if (ret < 0)
errors++;
nfct_close(cth);
}
else {
fprintf(stderr, "Can't open handler\n");
errors++;
}
to reset the connection in conntrack. I tested and it appears to be
working (per "cat /proc/net/ip_conntrack | grep my.ip.add.ress"
anyway)
Question #1: will this work for my need to make NAT table to see the arriving
packets or rebooting the box or unloading the iptable is really the only
(and unacceptable) way to get this done?
Question #2: With the libnetfilter_conntrack is writing to iptables-restore
STDIN really the best way t ochange the NAT table or there is some user space
API that can get this done without the overhead of a separare process?
Thanks
-c
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-06 20:46 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
------- Additional Comments From cfilin@intermedia.net 2006-08-06 20:46 MET
-------
Greetings - I've looked into libnetfilter_conntrack and stole a litle code
from ctnl_test.c:
struct nfct_handle* cth = nfct_open(CONNTRACK, 0);
if (cth) {
int ret = nfct_delete_conntrack(cth, orig, NFCT_DIR_ORIGINAL, NFCT_ANY_ID);
fprintf(stdout, "TEST 6: delete conntrack (%d)\n", ret);
if (ret < 0)
errors++;
nfct_close(cth);
}
else {
fprintf(stderr, "Can't open handler\n");
errors++;
}
to reset the connection in conntrack. I tested and it appears to be
working (per "cat /proc/net/ip_conntrack | grep my.ip.add.ress"
anyway)
Question #1: will this work for my need to make NAT table to see the arriving
packets or rebooting the box or unloading the iptable is really the only
(and unacceptable) way to get this done?
Question #2: With the libnetfilter_conntrack is writing to iptables-restore
STDIN really the best way t ochange the NAT table or there is some user space
API that can get this done without the overhead of a separare process?
Thanks
-c
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-06 21:04 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
netfilter@linuxace.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From netfilter@linuxace.com 2006-08-06 21:04 MET
-------
Perhaps you should take a look at the conntrack utility. It allows deletion of
conntracks, which it sounds like you have no choice but to do.
http://netfilter.org/projects/conntrack/index.html
Closing - not a bug.
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-06 21:04 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
netfilter@linuxace.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From netfilter@linuxace.com 2006-08-06 21:04 MET
-------
Perhaps you should take a look at the conntrack utility. It allows deletion of
conntracks, which it sounds like you have no choice but to do.
http://netfilter.org/projects/conntrack/index.html
Closing - not a bug.
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-06 21:04 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498
netfilter@linuxace.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From netfilter@linuxace.com 2006-08-06 21:04 MET
-------
Perhaps you should take a look at the conntrack utility. It allows deletion of
conntracks, which it sounds like you have no choice but to do.
http://netfilter.org/projects/conntrack/index.html
Closing - not a bug.
--
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-07 16:47 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From cfilin@intermedia.net 2006-08-07 16:47 MET ------- I've looked at the conntract utility, moreover I now have my own code that throws out connections from conntrack cache. The problem I have is different - the "nat" table is consulted only when a packet creating a *new* conntrack connection is arriving. This means that when the second, third and so on packets are arriving on the same conntack connection, the "nat" table is not consulted and it does not NAT the packets. This is all demonstrated perferctly clear below (I have RTP traffic coming to the interface from 85.141.210.22:9000 all the time) 1) Here's my NAT table: [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:57:27 2006 *nat :PREROUTING ACCEPT [1502:275921] :POSTROUTING ACCEPT [406:45653] :OUTPUT ACCEPT [406:45653] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [12:1247] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [7:511] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [0:0] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 -j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [0:0] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT 2) Traffic from 85.141.210.22:9000 keeps coming in: # cat /proc/net/ip_conntrack | grep src=85.141.210.22 | grep ^udp udp 17 179 src=204.147.182.200 dst=85.141.210.22 sport=18298 dport=9000 packets=22736 bytes=1659728 src=85.141.210.22 dst=204.147.182.200 sport=9000 dport=18298 packets=22826 bytes=1666298 [ASSURED] mark=0 use=1 # cat /proc/net/ip_conntrack | grep src=85.141.210.22 | grep ^udp udp 17 179 src=204.147.182.200 dst=85.141.210.22 sport=18298 dport=9000 packets=22821 bytes=1665933 src=85.141.210.22 dst=204.147.182.200 sport=9000 dport=18298 packets=22911 bytes=1672503 [ASSURED] mark=0 use=1 3) The count of NATed packets is unchanged (they are all zeroes): [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:57:48 2006 *nat :PREROUTING ACCEPT [1502:275921] :POSTROUTING ACCEPT [406:45653] :OUTPUT ACCEPT [406:45653] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [12:1247] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [7:511] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [0:0] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 -j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [0:0] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT 4) Now I delete the conntract entry using my utility (written using libnetfilter_conntrack-0.0.31) [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# ./delete_conntrack udp 85.141.210.22 9000 204.147.182.200 18298 TEST 6: delete conntrack (0) The utility succeeds 5) Looking into the NAT counters again: [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:58:19 2006 *nat :PREROUTING ACCEPT [1523:278443] :POSTROUTING ACCEPT [409:45846] :OUTPUT ACCEPT [409:45846] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [13:1320] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [8:584] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [1:73] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 - j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [1:73] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT # Completed on Mon Aug 7 06:58:19 2006 Excellent, iptables NATed 1 packet of 73 bytes. 6) The traffic from 85.141.210.22:9000 keeps coming in, but the counters in NAT table do not change: [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:58:22 2006 *nat :PREROUTING ACCEPT [1528:279437] :POSTROUTING ACCEPT [412:46074] :OUTPUT ACCEPT [412:46074] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [13:1320] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [8:584] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [1:73] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 - j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [1:73] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT Now if I delete the conntract entry again, NAT table packet counter will increment again but I need to setup iptables so that *all* packets from 85.141.210.22:9000 are NATed, not only the first one opening the conntrack entry. Is there a way to do this with iptables? If not then what is the purpose of NAT table? What is the right way to use it? Thanks in advance for your patience and help? -c -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-07 16:47 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From cfilin@intermedia.net 2006-08-07 16:47 MET ------- I've looked at the conntract utility, moreover I now have my own code that throws out connections from conntrack cache. The problem I have is different - the "nat" table is consulted only when a packet creating a *new* conntrack connection is arriving. This means that when the second, third and so on packets are arriving on the same conntack connection, the "nat" table is not consulted and it does not NAT the packets. This is all demonstrated perferctly clear below (I have RTP traffic coming to the interface from 85.141.210.22:9000 all the time) 1) Here's my NAT table: [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:57:27 2006 *nat :PREROUTING ACCEPT [1502:275921] :POSTROUTING ACCEPT [406:45653] :OUTPUT ACCEPT [406:45653] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [12:1247] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [7:511] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [0:0] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 -j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [0:0] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT 2) Traffic from 85.141.210.22:9000 keeps coming in: # cat /proc/net/ip_conntrack | grep src=85.141.210.22 | grep ^udp udp 17 179 src=204.147.182.200 dst=85.141.210.22 sport=18298 dport=9000 packets=22736 bytes=1659728 src=85.141.210.22 dst=204.147.182.200 sport=9000 dport=18298 packets=22826 bytes=1666298 [ASSURED] mark=0 use=1 # cat /proc/net/ip_conntrack | grep src=85.141.210.22 | grep ^udp udp 17 179 src=204.147.182.200 dst=85.141.210.22 sport=18298 dport=9000 packets=22821 bytes=1665933 src=85.141.210.22 dst=204.147.182.200 sport=9000 dport=18298 packets=22911 bytes=1672503 [ASSURED] mark=0 use=1 3) The count of NATed packets is unchanged (they are all zeroes): [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:57:48 2006 *nat :PREROUTING ACCEPT [1502:275921] :POSTROUTING ACCEPT [406:45653] :OUTPUT ACCEPT [406:45653] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [12:1247] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [7:511] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [0:0] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 -j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [0:0] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT 4) Now I delete the conntract entry using my utility (written using libnetfilter_conntrack-0.0.31) [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# ./delete_conntrack udp 85.141.210.22 9000 204.147.182.200 18298 TEST 6: delete conntrack (0) The utility succeeds 5) Looking into the NAT counters again: [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:58:19 2006 *nat :PREROUTING ACCEPT [1523:278443] :POSTROUTING ACCEPT [409:45846] :OUTPUT ACCEPT [409:45846] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [13:1320] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [8:584] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [1:73] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 - j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [1:73] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT # Completed on Mon Aug 7 06:58:19 2006 Excellent, iptables NATed 1 packet of 73 bytes. 6) The traffic from 85.141.210.22:9000 keeps coming in, but the counters in NAT table do not change: [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:58:22 2006 *nat :PREROUTING ACCEPT [1528:279437] :POSTROUTING ACCEPT [412:46074] :OUTPUT ACCEPT [412:46074] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [13:1320] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [8:584] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [1:73] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 - j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [1:73] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT Now if I delete the conntract entry again, NAT table packet counter will increment again but I need to setup iptables so that *all* packets from 85.141.210.22:9000 are NATed, not only the first one opening the conntrack entry. Is there a way to do this with iptables? If not then what is the purpose of NAT table? What is the right way to use it? Thanks in advance for your patience and help? -c -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-07 16:47 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From cfilin@intermedia.net 2006-08-07 16:47 MET ------- I've looked at the conntract utility, moreover I now have my own code that throws out connections from conntrack cache. The problem I have is different - the "nat" table is consulted only when a packet creating a *new* conntrack connection is arriving. This means that when the second, third and so on packets are arriving on the same conntack connection, the "nat" table is not consulted and it does not NAT the packets. This is all demonstrated perferctly clear below (I have RTP traffic coming to the interface from 85.141.210.22:9000 all the time) 1) Here's my NAT table: [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:57:27 2006 *nat :PREROUTING ACCEPT [1502:275921] :POSTROUTING ACCEPT [406:45653] :OUTPUT ACCEPT [406:45653] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [12:1247] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [7:511] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [0:0] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 -j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [0:0] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT 2) Traffic from 85.141.210.22:9000 keeps coming in: # cat /proc/net/ip_conntrack | grep src=85.141.210.22 | grep ^udp udp 17 179 src=204.147.182.200 dst=85.141.210.22 sport=18298 dport=9000 packets=22736 bytes=1659728 src=85.141.210.22 dst=204.147.182.200 sport=9000 dport=18298 packets=22826 bytes=1666298 [ASSURED] mark=0 use=1 # cat /proc/net/ip_conntrack | grep src=85.141.210.22 | grep ^udp udp 17 179 src=204.147.182.200 dst=85.141.210.22 sport=18298 dport=9000 packets=22821 bytes=1665933 src=85.141.210.22 dst=204.147.182.200 sport=9000 dport=18298 packets=22911 bytes=1672503 [ASSURED] mark=0 use=1 3) The count of NATed packets is unchanged (they are all zeroes): [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:57:48 2006 *nat :PREROUTING ACCEPT [1502:275921] :POSTROUTING ACCEPT [406:45653] :OUTPUT ACCEPT [406:45653] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [12:1247] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [7:511] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [0:0] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 -j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [0:0] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT 4) Now I delete the conntract entry using my utility (written using libnetfilter_conntrack-0.0.31) [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# ./delete_conntrack udp 85.141.210.22 9000 204.147.182.200 18298 TEST 6: delete conntrack (0) The utility succeeds 5) Looking into the NAT counters again: [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:58:19 2006 *nat :PREROUTING ACCEPT [1523:278443] :POSTROUTING ACCEPT [409:45846] :OUTPUT ACCEPT [409:45846] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [13:1320] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [8:584] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [1:73] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 - j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [1:73] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT # Completed on Mon Aug 7 06:58:19 2006 Excellent, iptables NATed 1 packet of 73 bytes. 6) The traffic from 85.141.210.22:9000 keeps coming in, but the counters in NAT table do not change: [root@ast-mv ~/Work/AsteriskPilot/asterisk/cpp/tests]# /sbin/iptables-save -c - t nat # Generated by iptables-save v1.3.5 on Mon Aug 7 06:58:22 2006 *nat :PREROUTING ACCEPT [1528:279437] :POSTROUTING ACCEPT [412:46074] :OUTPUT ACCEPT [412:46074] :pbxpilot_postrouting - [0:0] :pbxpilot_prerouting - [0:0] [13:1320] -A PREROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_prerouting [8:584] -A POSTROUTING -p udp -m udp --dport 16384:32766 -j pbxpilot_postrouting [1:73] -A pbxpilot_postrouting -d 212.113.111.225 -p udp -m udp --dport 21650 - j SNAT --to-source 204.147.182.200:18056 [0:0] -A pbxpilot_postrouting -d 85.141.210.22 -p udp -m udp --dport 9000 -j SNAT --to-source 204.147.182.200:18298 [1:73] -A pbxpilot_prerouting -s 85.141.210.22 -p udp -m udp --sport 9000 -j DNAT --to-destination 212.113.111.225:21650 [0:0] -A pbxpilot_prerouting -s 212.113.111.225 -p udp -m udp --sport 21650 -j DNAT --to-destination 85.141.210.22:9000 COMMIT Now if I delete the conntract entry again, NAT table packet counter will increment again but I need to setup iptables so that *all* packets from 85.141.210.22:9000 are NATed, not only the first one opening the conntrack entry. Is there a way to do this with iptables? If not then what is the purpose of NAT table? What is the right way to use it? Thanks in advance for your patience and help? -c -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-07 17:55 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From netfilter@linuxace.com 2006-08-07 17:55 MET -------> Now if I delete the conntract entry again, NAT table packet counter will > increment again but I need to setup iptables so that *all* packets from > 85.141.210.22:9000 are NATed, not only the first one opening the > conntrack entry.Only NEW sessions enter the NAT table, and thus only the first packet increments the counter. All future packets will continue to be NATed, however -- view /proc/net/ip_conntrack to confirm this. Please ask any further questions on the netfilter user mailing list, thanks. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-07 17:55 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From netfilter@linuxace.com 2006-08-07 17:55 MET -------> Now if I delete the conntract entry again, NAT table packet counter will > increment again but I need to setup iptables so that *all* packets from > 85.141.210.22:9000 are NATed, not only the first one opening the > conntrack entry.Only NEW sessions enter the NAT table, and thus only the first packet increments the counter. All future packets will continue to be NATed, however -- view /proc/net/ip_conntrack to confirm this. Please ask any further questions on the netfilter user mailing list, thanks. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
bugzilla-daemon@bugzilla.netfilter.org
2006-Aug-07 17:55 UTC
[Bug 498] RTP packets are not hitting NAT table
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=498 ------- Additional Comments From netfilter@linuxace.com 2006-08-07 17:55 MET -------> Now if I delete the conntract entry again, NAT table packet counter will > increment again but I need to setup iptables so that *all* packets from > 85.141.210.22:9000 are NATed, not only the first one opening the > conntrack entry.Only NEW sessions enter the NAT table, and thus only the first packet increments the counter. All future packets will continue to be NATed, however -- view /proc/net/ip_conntrack to confirm this. Please ask any further questions on the netfilter user mailing list, thanks. -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. You are on the CC list for the bug, or are watching someone who is.