Raspberry Pi 400 + Surfshark VPN = almost there

Hi Everybody! I have spent approximately 20 hours trying to get things work here but I'm at the point where I'm just confused and cannot find a solution. I'm not an IT guy.

Here's what I am trying to achieve, my setup (simply to work from another location and avoid detection):
Internet <-> Fiberoptic router <-> Raspberry pi on OpenWRT with Surfshark VPN <-> work laptop

Most of the things seem to be working now except correct routing via Surfshark. I am able to connect to the wireless network and the Internet, enabled by the RP.
Luci is also showing that my VPN connection is enabled, running UDP, on port 1194 BUT in the Network/ Devices tab it's showing an " Error:** Network device is not present"

Here are my config files

Network:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd0e:46f0:408f::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option ipaddr '192.168.18.9'
	option gateway '192.168.18.1'

config interface 'surfsharktun'
	option proto 'none'
	option device 'tun0'

config interface 'wan'
	option force_link '1'
	option proto 'dhcp'
	option peerdns '0'
	list dns '162.252.172.57'
	list dns '149.154.159.92'
	option device 'eth0.2'

Firewall

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config zone
	option name 'vpnfirewall'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'surfsharktun'

config forwarding
	option src 'lan'
	option dest 'vpnfirewall'

I'm confused what you're trying to do, since a consumer VPN like Surfshark will only pass your Internet access through different public IP, it doesn't allow access to work networks. For that you would need to connect to a VPN server run by the company.

Is this OpenVPN based? OpenVPN creates the "tun0" device only after successful connection to the server. Network device not present generally means that the OpenVPN client process was unable to connect to the VPN server. Reading the System Log will usually tell why.

Hi,

No, my goal isn't to connect to my company's vpn at all. I just want to work from another country without detection. It's the same case as wanting to have access to the American Netflix in France. Nothing more than that.

I already have this setup running on a cheap Asus router but 8mbps is barely cutting it for me.

And yes, I have installed OpenVPN. I'll check with logread

Is that Asus router running OpenWrt?
Does Surfshark offer Wireguard as an option? It is much higher performance that OpenVPN on the same hardware, and therefore should give you much better throughput.

With respect to your OpenVPN configuration, can you post that please (redact all personally identifiable information).

Nope, Asus router is running its own stock firmware with only OpenVPN support.

Surfshark does offer Wireguard but that's only if I can figure our how to use OpenWRT on RPi

logread does point to the problem with resolving the connection to Surfshark's servers but I am using the same .opvn file and credentials on the Asus.


  19:03:53 2022 daemon.notice openvpn(surfshark)[1692]: UDP link local: (not bound)
  19:03:53 2022 daemon.notice openvpn(surfshark)[1692]: UDP link remote: [AF_INET]138.199.XX.XXX:1194
  19:03:53 2022 daemon.notice openvpn(surfshark)[1692]: Network unreachable, restarting
  19:03:53 2022 daemon.notice openvpn(surfshark)[1692]: SIGUSR1[soft,network-unreachable] received, process restarting
  19:03:53 2022 daemon.notice openvpn(surfshark)[1692]: Restart pause, 5 second(s)
  19:03:58 2022 daemon.warn openvpn(surfshark)[1692]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
  19:03:58 2022 daemon.warn openvpn(surfshark)[1692]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
  19:03:58 2022 daemon.notice openvpn(surfshark)[1692]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
  19:03:58 2022 daemon.notice openvpn(surfshark)[1692]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
  19:03:58 2022 daemon.notice openvpn(surfshark)[1692]: TCP/UDP: Preserving recently used remote address: [AF_INET]138.199.XX.XXX:1194
  19:03:58 2022 daemon.notice openvpn(surfshark)[1692]: Socket Buffers: R=[212992->212992] S=[212992->212992]
  19:03:58 2022 daemon.notice openvpn(surfshark)[1692]: UDP link local: (not bound)
  19:03:58 2022 daemon.notice openvpn(surfshark)[1692]: UDP link remote: [AF_INET]138.199.17.137:1194
  19:03:58 2022 daemon.notice openvpn(surfshark)[1692]: Network unreachable, restarting
  19:03:58 2022 daemon.notice openvpn(surfshark)[1692]: SIGUSR1[soft,network-unreachable] received, process restarting
  19:03:58 2022 daemon.notice openvpn(surfshark)[1692]: Restart pause, 5 second(s)
  19:04:03 2022 daemon.warn openvpn(surfshark)[1692]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
  19:04:03 2022 daemon.warn openvpn(surfshark)[1692]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
  19:04:03 2022 daemon.notice openvpn(surfshark)[1692]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
  19:04:03 2022 daemon.notice openvpn(surfshark)[1692]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
  19:04:03 2022 daemon.notice openvpn(surfshark)[1692]: TCP/UDP: Preserving recently used remote address: [AF_INET]45.134.XXX.XXX:1194
  19:04:03 2022 daemon.notice openvpn(surfshark)[1692]: Socket Buffers: R=[212992->212992] S=[212992->212992]
  19:04:03 2022 daemon.notice openvpn(surfshark)[1692]: UDP link local: (not bound)
  19:04:03 2022 daemon.notice openvpn(surfshark)[1692]: UDP link remote: [AF_INET]45.134.XXX.XXX:1194
  19:04:03 2022 daemon.notice openvpn(surfshark)[1692]: Network unreachable, restarting
  19:04:03 2022 daemon.notice openvpn(surfshark)[1692]: SIGUSR1[soft,network-unreachable] received, process restarting
  19:04:03 2022 daemon.notice openvpn(surfshark)[1692]: Restart pause, 10 second(s)
  19:04:11 2022 authpriv.info dropbear[2244]: Child connection from 192.168.18.6:62610
  19:04:13 2022 daemon.warn openvpn(surfshark)[1692]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
  19:04:13 2022 daemon.warn openvpn(surfshark)[1692]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
  19:04:13 2022 daemon.notice openvpn(surfshark)[1692]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
  19:04:13 2022 daemon.notice openvpn(surfshark)[1692]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
  


I have xxx'ed out the IP portions. To be sure I even uploaded the .opvn file and credentials to openwrt once again

Is your Asus still online? If so, make sure that OpenVPN is disconnected there before you start the connection on the Pi.

1 Like

For a moment I felt really silly but I closed the connection on the Asus, rebooted OpenWRT and still the same. No luck.


When it comes to the openvpn config there's not much there.

config openvpn 'surfshark'
	option config '/etc/openvpn/surfshark.ovpn'
	option enabled '1'

I followed the guide on Surfshark's webpage (considering I had to do some things differently). The only difference is that I'm connecting my openwrt device to another router (fiberoptic - 192.168.18.1). This is the guide that I followed:

let's see the contents of this file.

This is the link you need to set up Surfshark Wireguard on Openwrt. You linked to their VPN product, not their Wireguard product.

You might find some setup hints here as well.

2 Likes

It appears that the OP is using OpenVPN. Wireguard is probably a better option, so it's good that you have posted the relevant link for that, if the OP would like to change protocols (I personally prefer Wireguard).

That said, the OpenVPN option should be resolvable. I'm hoping they will post the OpenVPN configuration file so that we can verify that it is setup properly.

Here's the surfshark.ovpn file with some things just xx'ed out by me now.


client
dev tun
proto udp
remote xx-xx.prod.surfshark.com 1194
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0

remote-cert-tls server

auth-user-pass /etc/openvpn/surfshark.auth

#comp-lzo
verb 3
pull
fast-io
cipher AES-256-CBC

auth SHA512

<ca>
-----BEGIN CERTIFICATE-----
key removed by OP
-----END CERTIFICATE-----
</ca>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
key removed by OP
-----END OpenVPN Static key V1-----
</tls-auth>

/etc/openvpn/surfshark.auth contains my username and password simply pasted one under another

I'll try WireGuard tomorrow.

This should theoretically translate to tun0 when it comes up, but you can specify it as tun0 to make it explicit.

As long as the file is there and properly formatted, this should work.

What do the logs say when you attempt to connect?

I think you'll actually prefer WireGuard -- it is higher performance and easier to configure. If you have trouble, you can ask for help here, too.

OK, the best results I have got can open tunnel to the VPN servers but there's no routing.

I loaded the best config I had with OpenVPN and the VPN interface was shown as active but it wouldn't route me through it.

I followed Wireguard tutorial and I get an identical result. The wg0 is showing active but not sending much back and forth. However when I check my IP, I'm exposed.

Looks like OpenWRT is connecting to the VPN servers in both cases but not routing my devices through them - the only complication or difference from those tutorials is that I have is an additional router because I have fiberoptic.

That's because you're not routing. The PC has to be on a different interface and a different subnet than the rest of the network. Otherwise the PC is going to just switch through direct to the ISP line without seeing the VPN at all.

Does the 400 have two Ethernet ports?

No, the Pi400 has a single ethernet port. There is wifi (but we all know that wifi on the Pi devices is terrible as an AP).

There are the following solutions based on your current situation:

  1. Connect via wifi to the Pi (with the Wifi setup as a different subnet than the LAN and routing to the VPN). See my point above, though, as this is not going to be a great experience

  2. Make another network on the Pi and tie it to the ethernet port via VLAN/802.1q. You will need to use use a managed switch (could be the built-in switch of a wifi router running OpenWrt, for example) in order to deal with these networks properly. From there, you would probably want to connect a dumb AP for your wireless devices.

2b) instead of a managed switch, you can get a USB-ethernet adapter such as the UE300 and assign the new network to this ethernet port. Your lan devices would then connect to that ethernet directly or using a dumb switch, and/or an AP connected to that port.

  1. Change the DHCP server of your main router to point to the Pi as the router/gateway. This will tell all devices on your network to use Pi which will in turn tunnel the traffic through to your VPN provider.

3b) manually specify the IP address information for each of your hosts on your LAN that should use the VPN. This means setting those devices as static IPs, which is a bit of a pain, but will allow you to specify the desired router/gateway. The advantage of this (compared to 3 above) is that you don't necessarily have to send all devices through the VPN.

1 Like
  1. Connect via wifi to the Pi (with the Wifi setup as a different subnet than the LAN and routing to the VPN). See my point above, though, as this is not going to be a great experience

That's fine. The Pi will just stay in the home office. It is in fact connected to the main router with a cable - just like the current Asus running OpenVPN.

So what I need to do is;

  • Create a new Interface with the wifi selected as the device, set static IP (192.168.2.1) and netmask
  • Create a Firewall zone Wifi => VPN?
    Correct?

Yes, that should work. Obviously you also need to link the new network interface to the radio, set up the SSID and password for the wifi, enable the radio. Don't forget that you'll probably also want an DHCP server on that network.

1 Like

Thank you, psherman, mk24 and RuralRoots.

It worked and I'm getting nearly 100mbps instead of 8. That's a massive difference. I may need to tweak some thing later but the most important thing is working and I think I know what I was missing.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.