start > Linux > iptables > Forwarding Problem

Forwarding Problem

Created by dave. Last edited by dave, 16 years and 48 days ago. Viewed 4,801 times. #7

[diff] [history] [edit] [rdf]

labels

attachments

Problem

I have a common network, 10.126.0.0/24, and customer networks 10.126.x.0/24.

The idea is that customer networks can see the common networks, but can not see each other. The router that does this is a CentOS 4 box with IP addresses

10.126.0.254 (common)
10.126.1.253 (customer 1)
10.126.2.254 (customer 2)

Note that the customer networks are all VLANs on one physical interface (in the example above: eth1.201 and eth1.202)

I have some iptables rule that looks like so (/etc/sysconfig/iptables):

-A FORWARD -d 10.126.0.0/24 -j ACCEPT
-A FORWARD -s 10.126.0.0/24 -j ACCEPT
-A FORWARD -s 10.126.0.0/16 -d 10.126.0.0/16 -j DROP

…which show up in the iptables –nL as so:

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            10.126.0.0/24
ACCEPT     all  --  10.126.0.0/24        0.0.0.0/0
DROP       all  --  10.126.0.0/16        10.126.0.0/16

…but despite this, 10.126.1.10 can ping 10.126.2.254, which is not what I expect.

Now I've added a second, real host: 10.126.2.10. My results:

10.126.1.10 cannot interact with 10.126.2.10 ( <-- good! )
10.126.1.10 can still ping and interact with 10.126.2.254 ( <-- unexpected! )

The entire current configuration:

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -d 10.126.0.0/24 -j ACCEPT
-A FORWARD -s 10.126.0.0/24 -j ACCEPT
-A FORWARD -s 10.126.0.0/16 -d 10.126.0.0/16 -j DROP
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

The result:

# iptables -nL Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 10.126.0.0/24 ACCEPT all -- 10.126.0.0/24 0.0.0.0/0 DROP all -- 10.126.0.0/16 10.126.0.0/16

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Chain RH-Firewall-1-INPUT (1 references) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255 ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0 ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Conclusion

10.126.1.10 cannot interact with 10.126.2.10 ( <-- good! )
10.126.1.10 can still ping and interact with 10.126.2.254 ( <-- unexpected! )

So while I'm not entirely convinced that it is correct, it does appear to be working.

I'm not sure at this point if this is a side-effect of the fact that the router arms are on the same computer; or if it is because the router arms are VLANs on the same physical interface; or if iptables just works this way.

Update

Courtesy of IRC (#iptables on Freenode):

<sekhmet> xdroop: Packets to the IP that your router is bound to would be handled by INPUT, not FORWARD
<sekhmet> FORWARD is for packets going *through* the box, to other destinations
<sekhmet> INPUT is for packets headed to the box itself
<xdroop> Even if they are crossing interfaces?  ie in on eth1.201, destination eth1.202?
<sekhmet> Your router is bound to 10.126.1.253 and 10.126.2.254, so any packets to those IPs will be handled by INPUT
<sekhmet> Since it's an inbound, non-forwarding packet
<xdroop> ahh
<sekhmet> Correct
<xdroop> thank you
<sekhmet> Should've noticed that earlier and saved you some time.
<sekhmet> :)
<sekhmet> No prob

no comments | post comment

see also:
Linux	snipsnap-index	Forward...	Linux
snipsnap-search	snipsnap-index	linux	Hands To Remembe...
NTP+Configuration	Netscreen	VLAN definition	Replacing a fa...
Juniper	Boot+Block	snow	DNS check fails...
Video Resol...	linux	Network ...

Forwarding Problem

Problem

Conclusion

Update

Virtual Dave Megaplex:

Useful: