Hi guys,
i have there a OpenWrt 18.06.0 system running, which sends out ICMP redirects with a gateway address from an OpenVPN tunnel which does not work for some reason.
The device D1 which I ping responds to the first ping and then it looks it applies the ICMP Redirect from the Router R1 and it stops responding then until I issue a restart of D1.
D1 is a small unit with a microcontroller to send out alarms to the operators.
I have also there in this network a PC with a Windows 10 running (PC1) and a ping to this one works without problems. Does Windows 10 maybe ignore this ICMP redirect?
Layout:
D1 <-> R1 <-> S1 <-> U1
D1 = device to ping (10.1.139.90)
R1 = router with OpenVPN client (10.1.139.254 and tun1 interface with variable IP)
S1 = server with OpenVPN server
U1 = user with OpenVPN client, ping to D1 from there
PC1 = Windows 10 PC (10.1.139.50)
PLC1 = industrial programable logical controller (10.1.139.1)
PC1 and PLC1 are in the same network as D1.
R1:
br-lan Link encap:Ethernet HWaddr 18:D6:C7:51:93:0E
inet addr:10.1.139.254 Bcast:10.1.139.255 Mask:255.255.255.0
inet6 addr: fd17:4a35:ac50::1/60 Scope:Global
inet6 addr: fe80::1ad6:c7ff:fe51:930e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:47166 errors:0 dropped:0 overruns:0 frame:0
TX packets:30841 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:12357073 (11.7 MiB) TX bytes:2046759 (1.9 MiB)
eth0 Link encap:Ethernet HWaddr 18:D6:C7:51:93:0E
inet6 addr: fe80::1ad6:c7ff:fe51:930e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81993 errors:0 dropped:0 overruns:0 frame:0
TX packets:84986 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17570664 (16.7 MiB) TX bytes:19152950 (18.2 MiB)
Interrupt:4
eth0.1 Link encap:Ethernet HWaddr 18:D6:C7:51:93:0E
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:47168 errors:0 dropped:2 overruns:0 frame:0
TX packets:30841 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:12357165 (11.7 MiB) TX bytes:2046759 (1.9 MiB)
eth0.2 Link encap:Ethernet HWaddr 18:D6:C7:51:93:0F
inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::1ad6:c7ff:fe51:930f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34822 errors:0 dropped:0 overruns:0 frame:0
TX packets:54131 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3737445 (3.5 MiB) TX bytes:16764887 (15.9 MiB)
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.102.0.54 P-t-P:10.102.0.53 Mask:255.255.255.255
inet6 addr: fe80::c7de:cef8:9a9a:c422/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:33971 errors:0 dropped:0 overruns:0 frame:0
TX packets:53147 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1642981 (1.5 MiB) TX bytes:12894678 (12.2 MiB)
r1:~# tcpdump -nni br-lan icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
17:07:28.853747 IP 10.102.0.202 > 10.1.139.90: ICMP echo request, id 1, seq 1722, length 40
17:07:28.854300 IP 10.1.139.90 > 10.102.0.202: ICMP echo reply, id 1, seq 1722, length 40
17:07:28.866178 IP 10.102.0.1 > 10.1.139.90: ICMP redirect 10.102.0.202 to host 10.102.0.2, length 68
17:07:29.856465 IP 10.102.0.202 > 10.1.139.90: ICMP echo request, id 1, seq 1723, length 40
17:07:31.898741 IP 10.102.0.1 > 10.1.139.1: ICMP redirect 10.102.0.210 to host 10.102.0.2, length 56
17:07:31.947219 IP 10.102.0.1 > 10.1.139.1: ICMP redirect 10.102.0.210 to host 10.102.0.2, length 48
17:07:32.028836 IP 10.102.0.1 > 10.1.139.1: ICMP redirect 10.102.0.210 to host 10.102.0.2, length 108
17:07:32.193018 IP 10.102.0.1 > 10.1.139.1: ICMP redirect 10.102.0.210 to host 10.102.0.2, length 108
17:07:32.516707 IP 10.102.0.1 > 10.1.139.1: ICMP redirect 10.102.0.210 to host 10.102.0.2, length 108
17:07:33.263995 IP 10.102.0.1 > 10.1.139.1: ICMP redirect 10.102.0.210 to host 10.102.0.2, length 48
17:07:34.444097 IP 10.102.0.202 > 10.1.139.90: ICMP echo request, id 1, seq 1724, length 40
17:07:34.548045 IP 10.102.0.1 > 10.1.139.1: ICMP redirect 10.102.0.210 to host 10.102.0.2, length 108
17:07:37.443843 IP 10.102.0.1 > 10.1.139.1: ICMP redirect 10.102.0.210 to host 10.102.0.2, length 48
17:07:39.443427 IP 10.102.0.202 > 10.1.139.90: ICMP echo request, id 1, seq 1725, length 40
17:07:42.743511 IP 10.102.0.1 > 10.1.139.1: ICMP redirect 10.102.0.210 to host 10.102.0.2, length 48
S1:
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.102.0.1 P-t-P:10.102.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:3213349 errors:0 dropped:0 overruns:0 frame:0
TX packets:3203681 errors:0 dropped:26 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:833731811 (795.1 MiB) TX bytes:869302880 (829.0 MiB)
The TUN IP address of R1 is 10.102.0.54 and the TUN address of S1 is 10.102.0.1, but the ICMP redirect shows the IP address 10.102.0.2 as gateway.
I am wondering if this is correct. Is it in general required to send out an ICMP redirect in this situation?
Can I disable the sending of the ICMP redirects somehow?
I have already tried to add "net.ipv4.conf.all.send_redirects=0" to "/etc/sysctl.d/10-default.conf" and issued "sysctl -p", but it is still sending these requests.
Any ideas?