LinuxQuestions.org - SIP packets mysteriously disappearing when iptables-nat activated

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - SIP packets mysteriously disappearing when iptables-nat activated (https://www.linuxquestions.org/questions/linux-networking-3/sip-packets-mysteriously-disappearing-when-iptables-nat-activated-831451/)

SIP packets mysteriously disappearing when iptables-nat activated

Hi fellows,

I have a very weird case in my firewall.

I have an asterisk server and some phones and between them there is a linux firewall based on iptables.

With basic rules on iptables everything works ok, but when I put a single nat rule (no matter what rule I use) some packets from some phones misteriously disappear from interfase to interfase.

Clearer:
The firewall has two interfases: eth0 (pointing to phones) and eth2 (pointing to asterisk).

One problematic phone is 192.168.3.242, so I use tcpdump this way.

Code:

[prompt@server] tcpdump -i eth0 src 192.168.3.242

15:30:42.882384 IP 192.168.3.242.sip > 192.168.60.101.sip: SIP, length: 626

15:30:43.881547 IP 192.168.3.242.sip > 192.168.60.101.sip: SIP, length: 626

15:30:45.881193 IP 192.168.3.242.sip > 192.168.60.101.sip: SIP, length: 626

Using -vvv I can see it is a SIP udp REGISTER request to the asterisk server (192.168.60.101).

With no nat in the firewall I use "-i eth2" and I can see the packet, so the packet reach the server and works ok. But when there is nat present in the firewall I can not see the packet on eth2.

The packet is always present in eth0.
The nat I use has nothing to do with the ips or ports involved, even only empty nat accept rules like the following is enough to make the packets disappear:

Code:

*nat

:PREROUTING ACCEPT [351972:20012909]

:POSTROUTING ACCEPT [271654:13563320]

:OUTPUT ACCEPT [23093:1426014]

COMMIT

I log everything denied and nothing appears.
I've trying logging state INVALID and there was not there either.

I have no clue where to find the packet or why is gone.

Could it be a netfilter conntrack issue?
Could it be a hardware issue?

I'm not expert in SIP protocol but packet looks ok... and travels fine when nat is gone so I suppose the phone is ok.

Please help me with this, or advise me please where to post this.

Thanks in advance!

Juan M.

PD: I think is the same issue from a previous thread posted by me:
http://www.linuxquestions.org/questi...terisk-812339/
This problem was gone when asterisk staff changed replace sip protocol with iax between servers.

What kind of "single nat rule" have you added?

Thnx for replaying,

iptables -t nat -P PREROUTING ACCEPT

Just adding this rule, the packets start to disappear. Pretty frustrating.

From web manual of iptables:
...All connection tracking is handled in the PREROUTING chain, except locally generated packets which are handled in the OUTPUT chain. What this means is that iptables will do all recalculation of states and so on within the PREROUTING chain. If we send the initial packet in a stream, the state gets set to NEW within the OUTPUT chain, and when we receive a return packet, the state gets changed in the PREROUTING chain to ESTABLISHED, and so on. If the first packet is not originated by ourself, the NEW state is set within the PREROUTING chain of course. So, all state changes and calculations are done within the PREROUTING and OUTPUT chains of the nat table...

It looks like you enabled it, and it start to do its job.

But may I ask, what did you want to do?

OK, the question has a lot of sense of course.

The firewall needs to have nat because it is used to share internet to the Internal network.

Quote:

Originally Posted by juan10dan (Post 4096430)

OK, the question has a lot of sense of course.

The firewall needs to have nat because it is used to share internet to the Internal network.

In this case you have to give to the NAT full configuration: for VoIP and internet sharing. I mean also port mapping for incoming connection.

nimull22 I think the problem for him occurs even when he doesn't have any rules beyond those ACCEPT rules

juan10dan if you run tcpdump on the asterisk box what kind of packets do you see. It'd be interesting to have it running with the rules off and turn the rules on and capture the change

That's right estabroo, the problem appears even when accepting all.

The only thing the firewall has to do with the sip packet is forwarding according to the linux routing table, there is no need to nat anything related. The nat present in the firewall is needed for other purposes.

And if I run tcpdump after nat, the packet incoming is the same, but there is no packet outgoing.

and nat is the only thing that changed? No changes in the FORWARD chain?

Yes, nat is the only changed. Nothing in the FORWARD chain.

The forwarding should keep on being doing it by SO no?? just like if no nat were active and using so's routing table?? That's what I think at least.

What's your policy default on the FORWARD chain?

Well...

For testing purposes the default is DROP but the states RELATED, ESTABLISHED and NEW are accepted in the only two rules in FORWARD chain (in filter table). The iptables-save output for filter table is:

Code:

*filter

:INPUT DROP [0:0]

:FORWARD DROP [0:0]

:OUTPUT DROP [0:0]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -m state --state NEW -j ACCEPT

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD -m state --state NEW -j ACCEPT

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -m state --state NEW -j ACCEPT

I've logged INVALID state looking for the sip udp packets, but nothing appears.

I don't know any other way to log possible dropped packets than logging INVALID state.

Based on what you've said I just don't see why it would be dropping those packets, this is really bizarre. I run sip packets through nat here just fine. Add a log rule to then end of FORWARD and see if it gets any hits

Check ip_conntrack_sip module loaded on your firewall machine. you can check it with lsmod comannd.

This is the output of "lsmod |grep conntrack"

Code:

xt_conntrack            6593  0 

x_tables              17349  7 xt_multiport,ipt_LOG,xt_tcpudp,xt_state,iptable_nat,ip_tables,xt_conntrack

ip_conntrack_amanda    8901  1 ip_nat_amanda

ip_conntrack_irc      10545  1 ip_nat_irc

ip_conntrack_tftp      8249  1 ip_nat_tftp

ip_conntrack_h323      51421  1 ip_nat_h323

ip_conntrack_proto_sctp    12485  0 

ip_conntrack_netlink    28737  0 

ip_nat                21101  9 ip_nat_tftp,ip_nat_ftp,ip_nat_sip,ip_nat_amanda,ip_nat_pptp,iptable_nat,ip_nat_h323,ip_nat_irc,ip_conntrack_netlink

ip_conntrack_pptp      15441  1 ip_nat_pptp

ip_conntrack_sip      11313  1 ip_nat_sip

ip_conntrack_netbios_ns    6977  0 

ip_conntrack_ftp      11569  1 ip_nat_ftp

ip_conntrack          53281  22 xt_state,ip_nat_tftp,ip_nat_ftp,ip_nat_sip,ip_nat_amanda,ip_nat_snmp_basic,ip_nat_pptp,iptable_nat,ip_nat_h323,ip_nat_irc,xt_conntrack,ip_conntrack_amanda,ip_conntrack_irc,ip_conntrack_tftp,ip_conntrack_h323,ip_conntrack_proto_sctp,ip_conntrack_netlink,ip_nat,ip_conntrack_pptp,ip_conntrack_sip,ip_conntrack_netbios_ns,ip_conntrack_ftp

nfnetlink              10713  3 ip_conntrack_netlink,ip_nat,ip_conntrack