3

I used to configure iptables to forward packages between different network interfaces on a muli-network-interface-server.

So long, it worked fine until I updated my server to Ubuntu 1604.

Ubuntu 1604 comes with the new kernal, which rename networkinterfaces(Predictable Network Interface Names)

Let's say, this server connects two sub-networks together:

  • Interface enp3s0 with ip 192.168.1.155, connects to the network 192.168.1.0/24,
  • Interface enxa0cec80f64f3 with ip 10.1.1.1 connects to the network 10.1.1.0/24.

As bellow.

               Terminal1(10.1.1.2/24, gateway10.1.1.1)
                                 ||
                                 ||
                                 \/
                   +---------------------------+
                   | enxa0cec80f64f3(10.1.1.1) |
                   |                           |
                   |           Server          |
                   |                           |
                   |   enp3s0(192.168.1.155)   |
                   +---------------------------+
                                 /\
                                 ||
                                 ||
    Host1(192.168.1.111/24, route to 10.1.1.0/24 via 192.168.1.155)

To enable hosts in the 2 networks talk to each other freely, iptables on the server is configured as

$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.1.1.0/24 -d 192.168.1.0/24 -i enxa0cec80f64f3 -o enp3s0 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 10.1.1.0/24 -i enp3s0 -o enxa0cec80f64f3 -m conntrack --ctstate NEW -j ACCEPT

The forwording does not work properly.

  • Host1 ping 192.168.1.155, SUCCEED;
  • Host1 ping 10.1.1.1, SUCCEED;
  • Host1 ping Terminal1(10.1.1.2), FAILED;
  • Server ping Terminal1, SUCCEED

As i checked on the server with tcpdump, the packets from enp3s0 side was not forwarded on. (For some reason, I can not just check the packets from the other side)

Maybe iptables does not works with long-named network interfaces like enxa0cec80f64f3?

Galaxy
  • 133
  • 3
  • 1
    That firewall does not actually block anything. The problem lies elsewhere. – Michael Hampton Mar 22 '17 at 06:38
  • 1
    What Michael says. The correct test for whether forwarding is working is *whether you can see packets coming in one interface and going out of another*, with something like `tcpdump -n -n -i enxa0cec80f64f3 icmp`. What happens after that might be a problem, but it's not a forwarding problem. Just to catch an obvious gotcha, `cat /proc/sys/net/ipv4/ip_forward` returns `1`, yes? – MadHatter Mar 22 '17 at 06:40
  • @MadHatter I checked, with tcpdump and Wireshark. Server got ICMP from Host1(with desination Terminal1), but did not forward them. – Galaxy Mar 22 '17 at 06:46
  • @MadHatter It turns out I did not enable forwarding after the system installation, thanks for noticing. Please post your comment as an anwser. – Galaxy Mar 22 '17 at 06:48
  • @hxpax done, so that you may accept it! Glad we could help. (Don't feel bad, I've been setting up Linux routers for 20 years, and *still* once a year or so I forget to turn on the Big Forwarding Switch. It's easily done.) – MadHatter Mar 22 '17 at 07:13

1 Answers1

4

The right test for forwarding is whether packets that present at one interface with a destination that would be accessed via another appear also on that other interface, and the right way to test that is something like tcpdump. Here is forwarding happening properly; traffic on the internal interface:

[me@router ~]$ sudo tcpdump -n -n -i em2 icmp 
[...]
07:03:55.490295 IP 178.18.x.139 > 178.18.123.145: ICMP echo request, id 56423, seq 1, length 64
07:03:56.491899 IP 178.18.x.139 > 178.18.123.145: ICMP echo request, id 56423, seq 2, length 64

and at the same time on the external:

[me@router ~]$ sudo tcpdump -n -n -i em1 icmp
[...]
07:03:55.490588 IP 178.18.x.139 > 178.18.123.145: ICMP echo request, id 56423, seq 1, length 64
07:03:56.492255 IP 178.18.x.139 > 178.18.123.145: ICMP echo request, id 56423, seq 2, length 64

If you don't see that, which in you case you do not, the first thing to check is iptables. But as Michael Hampton has pointed out, your rules have nothing but ACCEPTs in them, so that can't be the problem. You have also been advised to check the Big Kernel Forwarding Switch

[me@router ~]$ cat /proc/sys/net/ipv4/ip_forward
1

which in your case returned 0 - meaning that no forwarding was enabled. Correcting this, presumably by changing the relevant line in /etc/sysctl.conf and running sysctl -p, has fixed the problem.

MadHatter
  • 78,442
  • 20
  • 178
  • 229