1

I am an iptables newbie. While I had tried to learn as much as I can over the past few days, this problem beats me!

First of all, the environment is a VMWare (CentOS7) running on a Fedora 30 host. In the VM, there's a libvirt running OCP.

Local ethernet interface = ens33 libvirt bridge = virbr0 OCP bridge = crc [danielyeap@localhost dnsmasq.d]$ ifconfig crc: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.130.1 netmask 255.255.255.0 broadcast 192.168.130.255 ether 52:54:00:fd:be:d0 txqueuelen 1000 (Ethernet) docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:f4:2b:9f:8c txqueuelen 0 (Ethernet) ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.125 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::a7ec:bc4d:3bae:8902 prefixlen 64 scopeid 0x20<link> ether 00:0c:29:2d:54:83 txqueuelen 1000 (Ethernet) lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 52:54:00:c0:c1:92 txqueuelen 1000 (Ethernet) vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::fcfd:fcff:fe07:2182 prefixlen 64 scopeid 0x20<link> ether fe:fd:fc:07:21:82 txqueuelen 1000 (Ethernet) [root@localhost docker]# brctl show bridge name bridge id STP enabled interfaces crc 8000.525400fdbed0 yes crc-nic vnet0 docker0 8000.0242f42b9f8c no virbr0 8000.525400c0c192 yes virbr0-nic [root@localhost docker]#

For learning purposes, I decided to add ICMP reject on the first line of both the "FORWARD" and "INPUT" chains:

[root@localhost ~]# iptables -I FORWARD 1 -p icmp --icmp-type echo-request -j REJECT [root@localhost ~]# iptables -I INPUT 1 -p icmp --icmp-type echo-request -j REJECT [root@localhost ~]# [FORWARD CHAIN] Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 REJECT icmp -- any any anywhere anywhere icmp echo-request reject-with icmp-port-unreachable 2 240K 70M DOCKER-USER all -- any any anywhere anywhere 3 240K 70M DOCKER-ISOLATION-STAGE-1 all -- any any anywhere anywhere 4 0 0 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED 5 0 0 DOCKER all -- any docker0 anywhere anywhere 6 0 0 ACCEPT all -- docker0 !docker0 anywhere anywhere 7 0 0 ACCEPT all -- docker0 docker0 anywhere anywhere 8 0 0 ACCEPT all -- any virbr0 anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED 9 0 0 ACCEPT all -- virbr0 any 192.168.122.0/24 anywhere 10 0 0 ACCEPT all -- virbr0 virbr0 anywhere anywhere 11 0 0 REJECT all -- any virbr0 anywhere anywhere reject-with icmp-port-unreachable 12 0 0 REJECT all -- virbr0 any anywhere anywhere reject-with icmp-port-unreachable 13 125K 56M ACCEPT all -- any crc anywhere 192.168.130.0/24 ctstate RELATED,ESTABLISHED 14 116K 14M ACCEPT all -- crc any 192.168.130.0/24 anywhere 15 0 0 ACCEPT all -- crc crc anywhere anywhere 16 180 14160 REJECT all -- any crc anywhere anywhere reject-with icmp-port-unreachable 17 0 0 REJECT all -- crc any anywhere anywhere reject-with icmp-port-unreachable 18 0 0 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 19 0 0 ACCEPT all -- lo any anywhere anywhere 20 0 0 FORWARD_direct all -- any any anywhere anywhere 21 0 0 FORWARD_IN_ZONES_SOURCE all -- any any anywhere anywhere 22 0 0 FORWARD_IN_ZONES all -- any any anywhere anywhere 23 0 0 FORWARD_OUT_ZONES_SOURCE all -- any any anywhere anywhere 24 0 0 FORWARD_OUT_ZONES all -- any any anywhere anywhere 25 0 0 DROP all -- any any anywhere anywhere ctstate INVALID 26 0 0 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited [INPUT CHAIN] Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 REJECT icmp -- any any anywhere anywhere icmp echo-request reject-with icmp-port-unre achable 2 0 0 ACCEPT udp -- virbr0 any anywhere anywhere udp dpt:domain 3 0 0 ACCEPT tcp -- virbr0 any anywhere anywhere tcp dpt:domain 4 0 0 ACCEPT udp -- virbr0 any anywhere anywhere udp dpt:bootps 5 0 0 ACCEPT tcp -- virbr0 any anywhere anywhere tcp dpt:bootps 6 330 18782 ACCEPT udp -- crc any anywhere anywhere udp dpt:domain 7 0 0 ACCEPT tcp -- crc any anywhere anywhere tcp dpt:domain 8 26 8430 ACCEPT udp -- crc any anywhere anywhere udp dpt:bootps 9 0 0 REJECT icmp -- any any anywhere anywhere icmp echo-request reject-with icmp-port-unre achable 10 0 0 ACCEPT tcp -- crc any anywhere anywhere tcp dpt:bootps 11 737K 232M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 12 357K 26M ACCEPT all -- lo any anywhere anywhere 13 1400 168K INPUT_direct all -- any any anywhere anywhere 14 1400 168K INPUT_ZONES_SOURCE all -- any any anywhere anywhere 15 1400 168K INPUT_ZONES all -- any any anywhere anywhere 16 0 0 DROP all -- any any anywhere anywhere ctstate INVALID 17 1395 168K REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited

From my best understanding, my ping to 192.168.130.0/24 should be blocked entirely. For 192.168.130.1 (crc interface), the packet should end up in the INPUT chain because kernel will treat the traffic as its own. For 192.168.130.11 (an OCP router), the packet should be picked up by the FORWARD chain.

However, the result is out of my expectation. While the traffic for 192.168.130.1 was handled properly by INPUT chain, the traffic for 192.168.130.11 does not seem to be picked up by INPUT and FORWARD chains.

[root@localhost ~]# ping 192.168.130.11 PING 192.168.130.11 (192.168.130.11) 56(84) bytes of data. 64 bytes from 192.168.130.11: icmp_seq=1 ttl=64 time=0.218 ms 64 bytes from 192.168.130.11: icmp_seq=2 ttl=64 time=0.227 ms 64 bytes from 192.168.130.11: icmp_seq=3 ttl=64 time=0.183 ms 64 bytes from 192.168.130.11: icmp_seq=4 ttl=64 time=0.971 ms 64 bytes from 192.168.130.11: icmp_seq=5 ttl=64 time=0.180 ms 64 bytes from 192.168.130.11: icmp_seq=6 ttl=64 time=0.171 ms 64 bytes from 192.168.130.11: icmp_seq=7 ttl=64 time=0.238 ms ... [root@localhost ~]# ping 192.168.130.1 PING 192.168.130.1 (192.168.130.1) 56(84) bytes of data. From 192.168.130.1 icmp_seq=1 Destination Port Unreachable From 192.168.130.1 icmp_seq=2 Destination Port Unreachable From 192.168.130.1 icmp_seq=3 Destination Port Unreachable From 192.168.130.1 icmp_seq=4 Destination Port Unreachable From 192.168.130.1 icmp_seq=5 Destination Port Unreachable From 192.168.130.1 icmp_seq=6 Destination Port Unreachable

Any idea why?

Thanks.

Improve this question
0

1 Answer 1

Reset to default
0

You blocked ICMP for INPUT (incoming traffic) FORWARD (forwarded, ie routed traffic) but didn't block ICMP for OUTPUT (locally generated outgoing traffic). So your ICMP echo-request is not blocked to leave the system. The answer (echo-reply) has no rule blocking it either: ping works.

To block the ping locally issued you should also add this rule:

iptables -I OUTPUT 1 -p icmp --icmp-type echo-request -j REJECT

To test the FORWARD rule, the ping must be done from an other, routed, host.

Improve this answer
5
  • Thanks for the answer. It helps me to better understanding networking! One more question, if you don't mind, I need the host machine (where the VM is running) to be able to connect to the "crc" bridge. Both the host and VM are on the same network. Is there a quick way to do it? Thanks. Commented Nov 8, 2019 at 9:04
  • I don't understand well your question. The host provides the bridge named crc. Can you explain further? Commented Nov 8, 2019 at 9:16
  • The data provided in the original post was taken from a VMWare. It is where the "virbr0" and "crc" reside. What I wish to do now is the have the host machine (where the VMWare is running) to connect to the "crc" interface, so that it can interact with the resources (basically Openshift) running there. Eg. "crc" = 192.168.130.1 and Openshift router = 192.168.130.11 Commented Nov 8, 2019 at 10:09
  • rewrote completely my answer (since it was accepted I couldn't delete it, so I put the correct answer instead...) Commented Nov 8, 2019 at 10:40
  • for the vmware part, I don't know enough to help. YOu should ask a separate question Commented Nov 8, 2019 at 10:41

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.