Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a Centos server acting as a NAT in my network. This server has one external (later ext1) interface and three internal (later int1, int2 and int3). Egress traffic comes from users via int1 and after MASQUERADE goes via ext1. Ingress traffic comes from ext1, MASQUERADE, and goes via int2 or int3 according to static routes.

                       | ext1
                       | x.x.x.x/24
             |                                |
             |  Centos server  (NAT)          |
             |                                |
                 |      |               |
            int1 |      | int2          | int3 |      | |
                 ^      v               v |      |  |
             |   |      |               |     |
             |   |      v               v     |
             |   ^      -Traffic policer-     |
             |   |_____________ |             |
             |                  |             |

The problem: Egress traffic seems to be dropped after PREROUTING table. Packet counters are not changing on MASQUERADE rule in POSTROUTING. If I change the routes to clients causing the traffic go back via int1 - everything works perfectly.

current iptable configuration is very simple:

# cat /etc/sysconfig/iptables

-I INPUT 1 -i int1 -j ACCEPT



Can anyone point me what I'm missing? Thanks.

UPDATE: via dev int2  proto zebra # routes to clients ... via dev int3  proto zebra # ... I have a lot of them
x.x.x.0/24 dev ext1  proto kernel  scope link  src x.x.x.x dev int1  proto kernel  scope link  src dev int2  proto kernel  scope link  src dev int3  proto kernel  scope link  src dev ext1  scope link  metric 1003 dev int1  scope link  metric 1004 dev int2  scope link  metric 1005 dev int3  scope link  metric 1006 
default via x.x.x.y dev ext1  

Clients have as gateway, which is redirecting them to

share|improve this question
accept input from other internal interfaces or accept estabilished,related connections – Alan Kuras Mar 29 '12 at 10:51
@AlanKuras ACCEPT is firewall default policy in this configuration. – Shamanu4 Mar 29 '12 at 11:08
Youre saying outgoing traffic comes in from clients on the subnet, but you want the return traffic to go to the client's IP on the (or the .3) subnet? I'm assuming not, so could you provide a few more details on this? Thanks – Patrick Mar 29 '12 at 12:02
@Patrick 10.30.x.x are only addresses of interfaces. Clients addresses are different, for example from The main idea is to send outgoing and ingoing traffic by different routes. – Shamanu4 Mar 29 '12 at 12:38
@AlanKuras. If I'm not misunderstanding you (because I'm very new in iptables) DNAT is using for port forwarding or DMZ. – Shamanu4 Mar 29 '12 at 12:45

1 Answer 1

up vote 4 down vote accepted

I suspect you may be running into an issue with the reverse path filter. Which is designed to perform some checks to make sure that the packets received on a given interface actually belong to that interface.

# from linux-doc-nnn/Documentation/networking/ip-sysctl.txt
rp_filter - INTEGER
        0 - No source validation.
        1 - Strict mode as defined in RFC3704 Strict Reverse Path
            Each incoming packet is tested against the FIB and if the interface
            is not the best reverse path the packet check will fail.
            By default failed packets are discarded.
        2 - Loose mode as defined in RFC3704 Loose Reverse Path
            Each incoming packet's source address is also tested against the FIB
            and if the source address is not reachable via any interface
            the packet check will fail.

        Current recommended practice in RFC3704 is to enable strict mode
        to prevent IP spoofing from DDos attacks. If using asymmetric routing
        or other complicated routing, then loose mode is recommended.

        conf/all/rp_filter must also be set to non-zero to do source validation
        on the interface
share|improve this answer
Yes, it works! Thanks a lot. I've lost two days reading manuals for iptables with no result... – Shamanu4 Mar 29 '12 at 17:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.