Since the last update i can’t reach OSMC devices from my bridged VPN. I am able to ping all other devices in the network but not the two OSMC’s (a vero2 and a raspberry2).
Did you change some policy for remote network devices?
Cheers
Bendsch
I don’t think so. And as OSMC doesn’t come with a firewall the only place could be /etc/hosts.allow or /etc/hosts.deny so maybe check that as I can confirm on my system that is empty (besides comments)
thank you for the answer! my hosts.allow/deny files are empty as well.
really strange, in my router i have no special rules activated for the two devices whatsoever.
i can not explain myself this behavior : /
If you have any other devices on the remote network that you can SSH to, log on to one and try to ping (or even SSH to) an OSMC device.
already tried that - i am able to ping both of the devices.
Are you sure you haven’t added any iptables rules to your OSMC boxes?
You can see who’s pinging an OSMC box with:
sudo iptables -I INPUT -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j LOG --log-level=1 --log-prefix "ICMP Ping "
so even if the return path is failing, for whatever reason, you should still see some details in the system journal.
no iptables. its really strange, also it also worked before august update, and i did not change manually anything in my system since then.
cheers bendsch
Did you try the spiffy iptables command I gave you? Does anything get to the box?
hello again
spiffy command indeed! apparently the osmc-box sees that someone is trying to ping:
Oct 16 09:08:22 B2RASP2 kernel: ICMP Ping IN=eth0 OUT= MAC=b8:27:eb:b0:21:6f:00:08:9b:8b:f8:44:08:00:45:00:00:54:9a:11:00:00:3f:01:13:b7 SRC=10.8.0.6 DST=192.168.3.43 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=39441 PROTO=ICMP TYPE=8 CODE=0 ID=20240 SEQ=2
Oct 16 09:08:23 B2RASP2 kernel: ICMP Ping IN=eth0 OUT= MAC=b8:27:eb:b0:21:6f:00:08:9b:8b:f8:44:08:00:45:00:00:54:c8:34:00:00:3f:01:e5:93 SRC=10.8.0.6 DST=192.168.3.43 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=51252 PROTO=ICMP TYPE=8 CODE=0 ID=20240 SEQ=3
this means, that in general the vpn seems to work fine and that the “problem” is somewhere on the osmc-boxes right?
What is the ip ro out put on the OSMC box?
Also instead of using the specific iptables command you could also use tcpdump -i any icmp than you will see all in and out icmp packages.
osmc@B2RASP2:~$ ip ro
0.0.0.0/1 via 192.168.11.5 dev tun0
default via 192.168.3.1 dev eth0
128.0.0.0/1 via 192.168.11.5 dev tun0
185.36.220.38 via 192.168.3.1 dev eth0
192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.43
192.168.3.1 dev eth0 scope link
192.168.11.0/24 via 192.168.11.5 dev tun0
192.168.11.5 dev tun0 proto kernel scope link src 192.168.11.6
oh yes, tcpdump works great as well for that purpose. thanx for the advice!
osmc@B2RASP2:~$ sudo tcpdump -i any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
09:24:57.591158 IP 10.8.0.6 > B2RASP2: ICMP echo request, id 64528, seq 154, length 64
09:24:57.591673 IP B2RASP2 > 10.8.0.6: ICMP echo reply, id 64528, seq 154, length 64
09:24:58.595187 IP 10.8.0.6 > B2RASP2: ICMP echo request, id 64528, seq 155, length 64
Well this proves OSMC sent’s the answer.
Just question is if it is with on the right interface. So maybe check
tcpdump -n -i tun0 icmp
osmc@B2RASP2:~$ sudo tcpdump -n -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
09:32:59.502386 IP 192.168.3.43 > 10.8.0.6: ICMP echo reply, id 23825, seq 0, length 64
09:33:00.505018 IP 192.168.3.43 > 10.8.0.6: ICMP echo reply, id 23825, seq 1, length 64
09:33:01.509781 IP 192.168.3.43 > 10.8.0.6: ICMP echo reply, id 23825, seq 2, length 64
BTW this also looks strange as my openvpn connected box shows>
default via 10.11.0.14 dev tun0 proto static metric 50 default via 192.168.87.1 dev enx00e04c124032 proto static metric 100
Ok, see my other response, I think you have your route wrongly setup.
Not sure if you want your default route back via tun0 or at least the ones to the networks that are behind your tunnel.
ok thanks for you support!
i think i found the problem. the route of my vpn on the osmc-box (it acts as a openvpn-client to another network destination itself) seem to be set up incorrectly:
0.0.0.0/1 via 192.168.11.5 dev tun0
The route was pushed by the server and that explains why it suddenly did not work without a change on my side.
sorry, i really expected it to be an issue with osmc because the update was the only thing i changed myself.
cheers
bendsch
More likely, that route was pushed by an openvpn client running on the OSMC box, since that’s just what I’d expect to see. The first and third lines are added by openvpn and take precedence over the middle line (the original default route) when the kernel decides its routing. So your pings were being returned via a different VPN tunnel – and lost.
the route was created by the client (of course) but it was not in the clients config file. so i suppose the openvpn-server pushed the route to the client ( How To Guide: Set Up & Configure OpenVPN Client/server VPN | OpenVPN ).
thanx for your explenation though, i did not fully understand what was happening - just that the openvpn-client was somehow interefering with my home-servers vpn …
An openvpn client will create a new default gateway through the tun0 tunnel, so that all external traffic goes via the VPN, and not via the usual route. To override the default gateway, it adds those two new routes.
Since traffic coming from the VPN server has an IP address of 10.8.x.x, if you want to keep the VPN client running on OSMC, you can add a line to your routing table so that return traffic from 10.8.x.x addresses is sent via eth0, rather than tun0. Something like sudo ip ro add 10.8.0.0/16 dev eth0 should probably work.