Hello,
Cliff Stanford a écrit :
I have just built a Linux (Fedora 7) box to act as an ADSL router and
NAT for two private (10.0.0.0) networks.
The problem I have is that I have a PBX running Asterisk behind the
router which must connect using iax2 to a box outside of the network.
Similarly, the remote switchboard must be able to connect using iax2 to
my nat'ed PBX.
My entire iptables setup at he moment looks like this:
[root@gw ~]# iptables -L --line-numbers
Note : Input and output interfaces are not shown. Use the "-v" option or
- better IMHO - use iptables-save which displays all the tables in a
single command in a more readable format.
I would expect all NEW UDP packets coming in on port 4569 (iax) to be
redirected to 10.20.30.14 after being logged as NAT: and subsequent
packets to be redirected via conntrack but not to be logged.
So would I.
In practice, I am getting a continual stream of the INPUT: log messages:
Oct 7 18:48:35 gw kernel: INPUT (NEW): IN=atm0 OUT=
MAC=aa:aa:03:00:00:00:08:00 SRC=194.70.36.201 DST=217.125.3.73 LEN=40
TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP SPT=4569 DPT=4569 LEN=20
Oct 7 18:49:15 gw last message repeated 4 times
Oct 7 18:50:16 gw last message repeated 7 times
Oct 7 18:51:35 gw last message repeated 7 times
The output from conntrack is:
[root@gw ~]# conntrack -L -s 194.70.36.201
udp 17 23 src=194.70.36.201 dst=217.125.3.73 sport=4569 dport=4569
packets=1332 bytes=53280 [UNREPLIED] src=217.125.3.73 dst=194.70.36.201
sport=4569 dport=4569 packets=0 bytes=0 mark=0 use=1
[root@gw ~]# conntrack -L -d 194.70.36.201 -s 10.20.30.14
udp 17 122 src=10.20.30.14 dst=194.70.36.201 sport=4569 dport=4569
packets=701 bytes=36932 src=194.70.36.201 dst=217.125.3.73 sport=4569
dport=1024 packets=491 bytes=28742 [ASSURED] mark=0 use=1
The second row is the outbound IAX which is working fine. So it
definitely seems that this rule is not working:
iptables -A PREROUTING -p udp -m udp --dport 4569 -j DNAT
- --to-destination 10.20.30.14
I think it is a bit more complicated. The incoming packets logged in the
INPUT chain are dropped by REJECT, so they should not create a conntrack
entry.
A possible explanation may be the following.
The remote box sends a continuous stream of UDP packets. The first
packet was received before the ruleset was installed but after the
conntrack was loaded, so a conntrack entry was created with no NAT, and
does not expire because of the continuous stream.
Anyway this happened before your Asterisk sent the first packet, because
you can see that the outgoing SNATed stream has an implicit source port
NAT (original source port 4569 is replaced with 1024) in order to avoid
a clash with an existing conntrack entry, actually the one related to
the incoming stream.
Clear the conntrack table by any means and see what happens.
-
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
