I SSH into my dietpi raspberry pi via eth0 (connection with mac os terminal works). Then I plugged in a usb-eth-adapter to connect the device to the router to get internet access. ip addr shows eth0 and eth1 but the internet access doesn’t work. How can I gain internet access? Thank you!
error message:
root@DietPi:~# apt update
Fehl:1 http://raspbian.raspberrypi.org/raspbian stretch InRelease
»raspbian.raspberrypi.org« konnte nicht aufgelöst werden.
Fehl:2 https://archive.raspberrypi.org/debian stretch InRelease
Could not resolve host: archive.raspberrypi.org
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Alle Pakete sind aktuell.
W: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/dists/stretch/InRelease »raspbian.raspberrypi.org« konnte nicht aufgelöst werden.
W: Fehlschlag beim Holen von https://archive.raspberrypi.org/debian/dists/stretch/InRelease Could not resolve host: archive.raspberrypi.org
W: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.
Interfaces file:
#/etc/network/interfaces
#Please use DietPi-Config to modify network settings.
# Local
auto lo
iface lo inet loopback
# Ethernet 1
allow-hotplug eth0
iface eth0 inet dhcp
# address 192.168.178.127/32
# Ethernet 2
allow-hotplug eth1
iface eth1 inet dhcp
# address 192.168.178.34/24
# gateway 192.168.178.1
# dns-nameservers 192.168.178.1
# Wifi
#allow-hotplug wlan0
#iface wlan0 inet dhcp
#address 192.168.0.100
#netmask 255.255.255.0
#gateway 192.168.0.1
#wireless-power off
#wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#dns-nameservers 8.8.8.8 8.8.4.4
ip addr:
root@DietPi:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group 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 pfifo_fast state UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.2.3/24 brd 192.168.2.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.178.26/24 brd 192.168.178.255 scope global eth1
valid_lft forever preferred_lft forever
May I ask why you use two network adapters? Why not leave the Pi connected to the router via internal adapter/eth0 and connect from Mac via local network?
If you for some reason want to block permanent internet, I guess you can configure this is the router as well, which would be easier than always plugging on and off an additional network adapter + configure/de-configure the interface each time.
The issue is the following:
Since eth0 is connected by default, it is taken as primary network adapter, so I guess DNS resolving and all regular requests are attempted to do via eth0 which then fails if the Mac (or whatever network eth0 is) does not forward these requests.
If you really need two separate adapters/interfaces active for different purpose, you need to set up a routing table to tell the system which requests to send via which interface.
To check current routes, please paste: ip r
To check which DNS server is currently attempted for resolving, please paste: cat /etc/resolv.conf
Hi Micha, thank you for answering! This setup is part of a small project. I would like to use the pi as a kind of a vpn-client between the internet-network (i.e. public wifi on airports or hotels) and the laptop (or other devices i.e. tablet via wifi) to use it in unsecure environments.
The problem:
As you wrote it was a routing problem. I fixed it with
sudo route add default gw 192.168.178.1 eth1
Result:
root@DietPi:~# ip r
default via 192.168.178.1 dev eth1
default via 192.168.2.1 dev eth0
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.3
192.168.178.0/24 dev eth1 proto kernel scope link src 192.168.178.28
Further steps:
smartphone usb tethering w pi
make these connections permanent
setup of vpn-client
somehow bridging eth0 with vpn-client and eth1 or smartphone (no idea?!?!)
I’m a novice. Therefore every hint/ link/ etc. is welcome.
Hmm, why not simply setting up the Pi as VPN server at home with related VPN clients on laptop, phone etc? With this only one network adapter is required and allows permanent hardware/software setup on the Pi.
You can install WireGuard or OpenVPN via dietpi-software. In both cases client configs are created that can be further adjusted according to which traffic to tunnel. There are clients for both VPN servers available for all relevant OS (Android/iOS/macOS/Windows/Linux of course).
If you need the final outgoing traffic to be encrypted/private as well, then you need a public VPN provider anyway which should then be used by the laptop/phone directly instead of having the Pi in the middle.
However maybe I did not yet fully understand your aim . Great that the route helped. If you want to stay with this setup, to make the route permanent, you could do:
echo -e '#!/bin/sh\nip r add default via 192.168.178.1 dev eth1' > /etc/network/if-up.d/route
chmod +x /etc/network/if-up.d/route
Note I used the modern ip command set here instead of deprecated net-tools commands (ifconfig, route, netstat etc).
Thank you once again! For me there are some difficulties to use the Pi as VPN server at home (even though I appreciate the possibility of an easy installation with DietPi a lot) and to have a client on the devices itself: 1. At home is not my personal network. 2. The upload and download bandwidth is by far too low to use it. Poor network expansion in the region. 3. Public wifis don’t support login with an activated vpn connection. I suppose this could be a security problem. This is why I prefer the pi between public wifi and my laptop/phone.
Thanks to your support I made the connection permanent (without using net-tools) and I did the setup of a public VPN provider. The next step was much more difficult. I tried something but it didn’t work:
First thing I tried was to establish a bridge between the laptop (eth0) and the vpn (tun0) which didn’t work because the layers are not compatible (I’ve read after some searching). Then I created a bridge between laptop (eth0) and the “internet” (eth1) which only worked with a deactivated vpn (tun0). In addition, there was the problem that I then lost the SSH connection to the pi. That makes me doubt that bridging is the right way to realise a connection to the internet via pi and vpn.
Second thing I tried was routing with iptables. I found a tutorial that seemed suitable for my purpose and adapted it a little bit. But it still doesn’t work. What’s the mistake? What am I missing?
sysctl -w net.ipv4.ip_forward=1
# Allow traffic initiated from VPN to access LAN
iptables -I FORWARD -i tun0 -o eth0 \
-s 11.7.3.0/24 -d 192.168.2.0/24 \
-m conntrack --ctstate NEW -j ACCEPT
# Allow traffic initiated from VPN to access "the world"
iptables -I FORWARD -i tun0 -o eth1 \
-s 11.7.3.0/24 -m conntrack --ctstate NEW -j ACCEPT
# Allow traffic initiated from LAN to access "the world"
iptables -I FORWARD -i eth0 -o eth1 \
-s 192.168.2.0/24 -m conntrack --ctstate NEW -j ACCEPT
# Allow established traffic to pass back and forth
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
-j ACCEPT
# Notice that -I is used, so when listing it (iptables -vxnL) it
# will be reversed. This is intentional in this demonstration.
# Masquerade traffic from VPN to "the world" -- done in the nat table
iptables -t nat -I POSTROUTING -o eth1 \
-s 11.7.3.0/24 -j MASQUERADE
# Masquerade traffic from LAN to "the world"
iptables -t nat -I POSTROUTING -o eth1 \
-s 192.168.2.0/24 -j MASQUERADE
root@DietPi:~# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group 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 pfifo_fast state UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.2.3/24 brd 192.168.2.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.178.28/24 brd 192.168.178.255 scope global eth1
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 11.7.3.10/24 brd 11.7.3.255 scope global tun0
valid_lft forever preferred_lft forever
Hmm, as far as my understanding reaches, it looks good. But indeed your rules are quite strict. Did you try it with less filtered rule set?
E.g.
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
So simply allow forwarding of all requests from VPN and LAN and masquerade everything that leaves eth1 into “the world”.
Then define the routes that everything leaves the correct interface:
ip r add default via 192.168.178.1 dev eth1 # Respectively leave this to DHCP enabled on eth1 should work as well.
ip r add 192.168.2.0/24 dev eth0
# The tun0 route should be added by the OpenVPN service, but otherwise:
ip r add 11.7.3.0/24 dev tun0
In case you need to remove active routes first via: ip r delete …
And check: ip r
There should be indeed then show cleanly three routes about to forward LAN IP range requests to eth0, VPN IP range requests to tun0 and everything else to eth1.
If that works, you can step by step add more filtering to the rules e.g. to enhance security and things.
Yes, I tried it with less filtered rules and with your (more less ) filtered rules. But it didn’t work. Do you have any idea?
I’m able to ping from the PI to Macbook on 192.168.2.100 (Netmask 255.255.255.0, Router/Gateway 192.168.2.3) and from Macbook to PI on 192.168.2.3 (eth0).
root@DietPi:~# iptables -vxnL
Chain INPUT (policy ACCEPT 92 packets, 7664 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 47 packets, 7644 bytes)
pkts bytes target prot opt in out source destination
root@DietPi:~# ip r
default via 192.168.178.1 dev eth1
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.3
192.168.178.0/24 dev eth1 proto kernel scope link src 192.168.178.34
root@DietPi:~# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group 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 state UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.2.3/24 brd 192.168.2.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::ba27:ebff:feb7:9b95/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.178.34/24 brd 192.168.178.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::20a:cdff:fe32:a0a9/64 scope link
valid_lft forever preferred_lft forever
root@DietPi:~# arp -a
? (192.168.178.1) auf xx:xx:xx:xx:xx:xx [ether] auf eth1
? (192.168.2.1) auf xx:xx:xx:xx:xx:xx [ether] auf eth0
? (192.168.2.100) auf xx:xx:xx:xx:xx:xx [ether] auf eth0
For me there are some difficulties to use the Pi as VPN server at home (even though I appreciate the possibility of an easy installation with DietPi a lot) and to have a client on the devices itself: 1. At home is not my personal network. 2. The upload and download bandwidth is by far too low to use it. Poor network expansion in the region. 3. Public wifis don’t support login with an activated vpn connection. I suppose this could be a security problem. This is why I prefer the pi between public wifi and my laptop/phone.
) filtered rules. But it didn’t work. Do you have any idea?