Iptables rules, how to allow another server IPs

Question

I have 5 ips

1.1.1.1
1.1.1.2
1.1.1.3
1.1.1.4
1.1.1.5

i already install openvz & openvz webpanel in main ip then create a vps with ip 1.1.1.2

i cant open 1.1.1.2, but if i disable iptables firewall, i can open it

service iptables save
service iptables stop
chkconfig iptables off

so i need to enable iptables firewall, what is the rule so i can to allow the server additional ips (1.1.1.2-1.1.1.5) in /etc/sysconfig/iptables ?

i tried these but still not right

-A INPUT -s 1.1.1.2 -j ACCEPT
-A INPUT -s 1.1.1.2 -d 1.1.1.5 -p tcp -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --s 1.1.1.2 -j ACCEPT
-A INPUT -i eth0 -m iprange --src-range 1.1.1.2-1.1.1.5 -j ACCEPT

please help guys

this is output of iptables -L -n -v, if needed

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 
    0     0 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           source IP range 1.1.1.2-1.1.1.6
 9243 1597K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    2    92 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0   
 1318 70268 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0   
    1    60 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
  197 17722 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 
   67  3375 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 10660 packets, 1713K bytes)
 pkts bytes target     prot opt in     out     source               destination

this is output of ip a sh, if needed

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 36:40:b5:86:c5:6f brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 34:40:b5:86:c5:6c brd ff:ff:ff:ff:ff:ff
    inet 1.1.1.1/29 brd 1.1.1.7 scope global eth0
    inet6 fe80::3640:b5ff:fe86:c56c/64 scope link
       valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 34:40:b5:86:c5:6d brd ff:ff:ff:ff:ff:ff
5: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/void
    inet6 fe80::1/128 scope link
       valid_lft forever preferred_lft forever

`iptables` rules can't be examined in isolation, as (like houses) they lean on one another. Please cut-and-paste the output of `iptables -L -n -v` into your question. I also can't quite understand what kind of traffic you're looking to allow, and from where to where - could you maybe clarify that? — MadHatter, Nov 15 '15 at 12:23
its the server additional ip 1.1.1.2, I cant open it in browser address or ssh, but if disable iptables firewall, I can open it in browser address or ssh. So what is the rules to allow the server additional ip 1.1.1.2 ? — michaelmore, Nov 15 '15 at 12:30
I don't know, and won't know, until you give the output asked for. — MadHatter, Nov 15 '15 at 12:31
Thanks. Could you try `iptables -I INPUT 1 -m iprange --dst-range 1.1.1.2-1.1.1.5 -j ACCEPT`? If that doesn't work, could you add the output of `ip a sh`? I'm not entirely sure where these extra adresses are. — MadHatter, Nov 15 '15 at 12:51
looks like not working. added ip a sh output in question above again, thank you for your help before — michaelmore, Nov 15 '15 at 12:59
Your NIC doesn't have these addresses. I don't see any evidence of a bridge. The networking here seems somewhat confused. As a last attempt on my part, you could try `iptables -F FORWARD`, and see if they're being forwarded. — MadHatter, Nov 15 '15 at 13:30
hmm looks like the problem is solved, I just need flush the iptables, is this right? how can I give thanks? gbu man — michaelmore, Nov 15 '15 at 15:38
The best way to thank me is to accept the summary answer I wrote, so that this question doesn't float around forever like a querulous albatross. — MadHatter, Nov 17 '15 at 09:27

score 0 · Answer 1 · answered Nov 17 '15 at 09:25

It would be good to formalise the investigations done in comments into an answer, so I'll do so.

The other IP addresses (which you show as 1.1.1.2 to 1.1.1.5, which incidentally isn't following best-practice in obfuscating public IP addresses) aren't assigned to your containerisation host's NIC, but to containerised guest images, though it's not quite clear how.

This means that packets to those addresses don't count as INPUT traffic, as they're being routed/bridged through the host, and therefore pass through the FORWARD chain.

You have only one rule in your FORWARD chain, and it rejects everything, so the ACCEPT policy on the chain is no help. When we clear the FORWARD rule by flushing the chain (iptables -F FORWARD), the ACCEPT policy comes into play, and traffic starts to flow.

If you would like a little more security on FORWARDed traffic, you could try rules similar to the ones you post, but put them in the FORWARD chain, make sure you correctly differentiate between source and destination addresses, and don't forget to change the chain policy to something other than ACCEPT once you have them working.

Iptables rules, how to allow another server IPs

1 Answers1