Join Log in
Score:0
Neppomuk avatar Server

iptables: IP forwarding restricted to pings. Why?

am flag
Neppomuk

After reinstalling OpenSuSE Leap 15.5 on a SOHO server, which acts AS a Firewall, the machines on the internal network (169.254.164.0/24) can't reach any hosts on the internet save for pings. But no meaningful Traffic, not even DNS, works.

One of the server's NICs (eth0) hangs on a DSL Router, whereas eth1 is connected to the switch of the internal network. Ipv4 forwarding is switched on: net.ipv4.ip_forward = 1

Here' s the network config of the server:

valen:~ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN grou
p default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP gr
oup default qlen 1000
    link/ether 14:dd:a9:d4:1e:70 brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet 192.168.178.41/24 brd 192.168.178.255 scope global eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP gr
oup default qlen 1000
    link/ether 14:dd:a9:d4:1e:71 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 169.254.164.1/24 brd 169.254.164.255 scope global eth1
       valid_lft forever preferred_lft forever

valen:~ # ip route show
default via 192.168.178.1 dev eth0 proto dhcp
169.254.164.0/24 dev eth1 proto kernel scope link src 169.254.164.1
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.41

valen:~ # iptables -t nat -nv -L >> netconfig.txt
Chain PREROUTING (policy ACCEPT 41 packets, 2456 bytes)
 pkts bytes target prot opt in out source dest
ination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source dest
ination

Chain OUTPUT (policy ACCEPT 12 packets, 909 bytes)
 pkts bytes target prot opt in out source dest
ination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source dest
ination
   12 909 MASQUERADE all -- * eth0 0.0.0.0/0 0.0
.0.0/0
    0 0 LOG all -- * eth0 0.0.0.0/0 0.0.
0.0/0 LOG flags 0 level 7 prefix "MASQUERADE: "

valen:~ # iptables -L -v
Chain INPUT (policy ACCEPT 496 packets, 40562 bytes)
 pkts bytes target prot opt in out source dest
ination

Chain FORWARD (policy ACCEPT 36 packets, 2276 bytes)
 pkts bytes target prot opt in out source dest
ination
    0 0 LOG all -- eth0 any anywhere anyw
here LOG level debug prefix "FORWARD: "
   36 2276 LOG all -- eth1 any anywhere anyw
here LOG level debug prefix "FORWARD: "

Chain OUTPUT (policy ACCEPT 307 packets, 43133 bytes)
 pkts bytes target prot opt in out source dest
ination

valen:~ # dmesg | grep MASQUERADE | tail -25
[ 5040.328157] x_tables: ip_tables: MASQUERADE target: used from hooks P
REROUTING, but only usable from POSTROUTING

valen:~ # iptables-save -c
# Generated by iptables-save v1.8.7 on Sun Jul 30 22:21:59 2023
*nat
:PREROUTING ACCEPT [271:12228]
:INPUT ACCEPT [3:180]
:OUTPUT ACCEPT [188:13601]
:POSTROUTING ACCEPT [0:0]
[188:13601] -A POSTROUTING -o eth0 -j MASQUERADE
[0:0] -A POSTROUTING -o eth0 -j LOG --log-prefix "MASQUERADE: " --log-le
vel 7
COMMIT
# Completed on Sun Jul 30 22:21:59 2023
# Generated by iptables-save v1.8.7 on Sun Jul 30 22:21:59 2023
*mangle
:PREROUTING ACCEPT [1055426:82517132]
:INPUT ACCEPT [1055140:82499096]
:FORWARD ACCEPT [286:18036]
:OUTPUT ACCEPT [197144:2649496105]
:POSTROUTING ACCEPT [197178:2649498961]
COMMIT
# Completed on Sun Jul 30 22:21:59 2023
# Generated by iptables-save v1.8.7 on Sun Jul 30 22:21:59 2023
*raw
:PREROUTING ACCEPT [1055426:82517132]
:OUTPUT ACCEPT [197145:2649496485]
COMMIT
# Completed on Sun Jul 30 22:21:59 2023
# Generated by iptables-save v1.8.7 on Sun Jul 30 22:21:59 2023
*security
:INPUT ACCEPT [1054928:82491464]
:FORWARD ACCEPT [34:2856]
:OUTPUT ACCEPT [197146:2649496917]
COMMIT
# Completed on Sun Jul 30 22:21:59 2023
# Generated by iptables-save v1.8.7 on Sun Jul 30 22:21:59 2023
*filter
:INPUT ACCEPT [129181:24309644]
:FORWARD ACCEPT [96:5856]
:OUTPUT ACCEPT [95693:121943383]
[0:0] -A FORWARD -i eth0 -j LOG --log-prefix "FORWARD: " --log-level 7
[96:5856] -A FORWARD -i eth1 -j LOG --log-prefix "FORWARD: " --log-level
 7
COMMIT
# Completed on Sun Jul 30 22:21:59 2023

And this ist how one of the clients is set up:

╭─jacek@epica ~
╰─➤ ip addr show
                                  2 ↵
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN grou
p default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast sta
te UP group default qlen 1000
    link/ether b4:2e:99:c6:e9:9f brd ff:ff:ff:ff:ff:ff
    altname enp7s0
    inet 169.254.164.5/24 brd 169.254.164.255 scope global eth0
       valid_lft forever preferred_lft forever
╭─jacek@epica ~
╰─➤ ip route show
default via 169.254.164.1 dev eth0
169.254.164.0/24 dev eth0 proto kernel scope link src 169.254.164.5

I can ping any external host (say, 8.8.8.8) from the client, but anything beyond is not working, not even DNS queries. The syslog on the server then displays outgoing traffic, but nothing ingoing:

[12810.381486] FORWARD: IN=eth1 OUT=eth0 MAC=14:dd:a9:d4:1e:71:b4:2e:99:
c6:e9:9f:08:00 SRC=169.254.164.5 DST=8.8.8.8 LEN=57 TOS=0x00 PREC=0x00 T
TL=63 ID=47287 DF PROTO=UDP SPT=51059 DPT=53 LEN=37
[12810.381551] FORWARD: IN=eth1 OUT=eth0 MAC=14:dd:a9:d4:1e:71:b4:2e:99:
c6:e9:9f:08:00 SRC=169.254.164.5 DST=8.8.4.4 LEN=57 TOS=0x00 PREC=0x00 T
TL=63 ID=31354 DF PROTO=UDP SPT=42060 DPT=53 LEN=37

What's wrong here?

UPDATE: The tcpdump tool shows normal traffic when pinging 8.8.8.8, but when trying to give a hostname like www.nwzonline.de as a target, I can't see any response from the DNS server:

valen:~ # tcpdump -v -ni eth1 'ip host 8.8.8.8' and icmp
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length
 262144 bytes
22:14:57.356849 IP (tos 0x0, ttl 64, id 63021, offset 0, flags [DF], pro
to ICMP (1), length 84)
    169.254.164.5 > 8.8.8.8: ICMP echo request, id 1, seq 1, length 64
22:14:57.370168 IP (tos 0x0, ttl 57, id 0, offset 0, flags [none], proto
 ICMP (1), length 84)
    8.8.8.8 > 169.254.164.5: ICMP echo reply, id 1, seq 1, length 64
22:14:58.358802 IP (tos 0x0, ttl 64, id 63032, offset 0, flags [DF], pro
to ICMP (1), length 84)
    169.254.164.5 > 8.8.8.8: ICMP echo request, id 1, seq 2, length 64
22:14:58.372195 IP (tos 0x0, ttl 57, id 0, offset 0, flags [none], proto
 ICMP (1), length 84)
    8.8.8.8 > 169.254.164.5: ICMP echo reply, id 1, seq 2, length 64
22:14:59.360447 IP (tos 0x0, ttl 64, id 63211, offset 0, flags [DF], pro
to ICMP (1), length 84)
    169.254.164.5 > 8.8.8.8: ICMP echo request, id 1, seq 3, length 64
22:14:59.373668 IP (tos 0x0, ttl 57, id 0, offset 0, flags [none], proto
 ICMP (1), length 84)
    8.8.8.8 > 169.254.164.5: ICMP echo reply, id 1, seq 3, length 64
22:15:00.362346 IP (tos 0x0, ttl 64, id 63238, offset 0, flags [DF], pro
to ICMP (1), length 84)
    169.254.164.5 > 8.8.8.8: ICMP echo request, id 1, seq 4, length 64
22:15:00.375229 IP (tos 0x0, ttl 57, id 0, offset 0, flags [none], proto
 ICMP (1), length 84)
    8.8.8.8 > 169.254.164.5: ICMP echo reply, id 1, seq 4, length 64
22:15:01.364456 IP (tos 0x0, ttl 64, id 63472, offset 0, flags [DF], pro
to ICMP (1), length 84)
    169.254.164.5 > 8.8.8.8: ICMP echo request, id 1, seq 5, length 64
22:15:01.377348 IP (tos 0x0, ttl 57, id 0, offset 0, flags [none], proto
 ICMP (1), length 84)
    8.8.8.8 > 169.254.164.5: ICMP echo reply, id 1, seq 5, length 64
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

valen:~ # tcpdump -v -ni eth1 'ip host 8.8.8.8'
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length
 262144 bytes
22:17:33.070802 IP (tos 0x0, ttl 64, id 10602, offset 0, flags [DF], pro
to UDP (17), length 62)
    169.254.164.5.33703 > 8.8.8.8.53: 8530+ A? www.nwzonline.de. (34)
22:17:33.070803 IP (tos 0x0, ttl 64, id 10603, offset 0, flags [DF], pro
to UDP (17), length 62)
    169.254.164.5.33703 > 8.8.8.8.53: 63569+ AAAA? www.nwzonline.de. (34
)
22:17:33.071009 IP (tos 0x0, ttl 64, id 61652, offset 0, flags [DF], pro
to UDP (17), length 62)
    169.254.164.5.34979 > 8.8.8.8.53: 8530+ A? www.nwzonline.de. (34)
22:17:33.071010 IP (tos 0x0, ttl 64, id 61653, offset 0, flags [DF], pro
to UDP (17), length 62)
    169.254.164.5.34979 > 8.8.8.8.53: 63569+ AAAA? www.nwzonline.de. (34
)
22:17:38.076881 IP (tos 0x0, ttl 64, id 18807, offset 0, flags [DF], pro
to UDP (17), length 62)
    169.254.164.5.42033 > 8.8.8.8.53: 14966+ A? www.nwzonline.de. (34)
22:17:38.076881 IP (tos 0x0, ttl 64, id 18808, offset 0, flags [DF], pro
to UDP (17), length 62)
    169.254.164.5.42033 > 8.8.8.8.53: 6003+ AAAA? www.nwzonline.de. (34)
22:17:38.077121 IP (tos 0x0, ttl 64, id 1207, offset 0, flags [DF], prot
o UDP (17), length 62)
    169.254.164.5.40930 > 8.8.8.8.53: 14966+ A? www.nwzonline.de. (34)
22:17:38.077122 IP (tos 0x0, ttl 64, id 1208, offset 0, flags [DF], prot
o UDP (17), length 62)
    169.254.164.5.40930 > 8.8.8.8.53: 6003+ AAAA? www.nwzonline.de. (34)
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Setting net.netfilter.nf_conntrack_helper = 1 does not help, either.

88
2 + 0
Score:1
HeCSa avatar Server
cn flag
HeCSa

I use for this kind of things, the shorewall package, which makes very easy to create rules.
The I create the interfaces, policy, masq, rules files, and modify the shorewall.conf to have ip_forward=1. And everything works like a charm, with the same network configuration you provided.
Give it a try. Best regards,
HeCSa.

Edit:

Hi again!
Let me show you an example, based on a configuration I have.
I have two network interfaces, one facinf the Internet, other the internal network. ip a outputs something like this:

root@bastion:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:32:55:0c brd ff:ff:ff:ff:ff:ff inet 192.168.0.20/24 brd 192.168.0.255 scope global ens3 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe32:550c/64 scope link valid_lft forever preferred_lft forever 3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:93:6e:49 brd ff:ff:ff:ff:ff:ff inet 10.100.119.1/24 brd 10.100.119.255 scope global ens9 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe93:6e49/64 scope link valid_lft forever preferred_lft forever
ens3 faces the internet, ens9 the internal network.

Installed the shorewall package. All configuration files are in /etc/shorewall
policy:
fw all ACCEPT info wan all DROP info lan all ACCEPT info
zones:
fw firewall wan ipv4 lan ipv4
shorewall.conf (only changed the following line):
IP_FORWARDING=Yes
interfaces:
wan ens3 lan ens9
masq:
ens3:0.0.0.0/0 10.100.119.0/0 rules:
ACCEPT wan fw tcp 22 - - # External SSH if needed ACCEPT lan wan icmp 8 - - # ping ACCEPT lan fw icmp 8 - - # ping ACCEPT lan wan udp 53 - - # dns queries ACCEPT lan wan tcp 80 - - # http ACCEPT lan wan tcp 443 - - # https
Then enabled and started shorewall:
systemctl enable shorewall systemctl start shorewall
And after rebooting, everything worked just fine.
Hope it helps!
Best regards,
HeCSa.

+ 6
Neppomuk avatar
am flag
Neppomuk
Im gonna give it a try and tell you about the results.
0
Reply
HeCSa avatar
cn flag
HeCSa
Hi again! Let me show you an example, based on a configuration I have.
0
Reply
HeCSa avatar
cn flag
HeCSa
Check my edit, there you have a fully funtional example ;-)
0
Reply
Neppomuk avatar
am flag
Neppomuk
Aaah, this looks much simpler than the iptables config.
0
Reply
HeCSa avatar
cn flag
HeCSa
Give it a try. If it works for you, don't forget to mark mine as a correct answer ;-)
0
Reply
Neppomuk avatar
am flag
Neppomuk
For an NFS server running on the same machine as Shorewall, I'd have to add the following rule, I suppose: `ACCEPT lan $FW tcp 2049`
0
Reply
Score:1
Anton Danilov avatar Server
cn flag
Anton Danilov

Try to follow these steps:

  • Check the correctness of routing with command ip route get 8.8.8.8 from 169.254.164.1 iif eth0 on the gateway. It should show you some valid route via eth0 interface.
  • Please use the iptables-save -c and paste it into the question. It really will help to understand your rule set.
  • At very strange issue run the tcpdump. Try tcpdump -ni eth1 'ip host 8.8.8.8' and icmp - I think it will show you something interesting.
  • After changes of nat rules restart ping command on client. It relates with the conntrack and the nat table passing specifics.
+ 2
Neppomuk avatar
am flag
Neppomuk
`valen:~ # ip route get 8.8.8.8 from 169.254.164.1 iif eth0 RTNETLINK answers: Invalid argument`
0
Reply
Neppomuk avatar
am flag
Neppomuk
Added the info you requested in my original question.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.