I’m hoping someone can help me troubleshoot a VPN issue I’m having.
I have a VPN router that I’ve built using a Tinker Board (small single board computer), it’s been up and running fine for the best part of 18 months now.
I intended this to be use as a double hop VPN, so I could gain access to my network (via OpenVPN) from outside my home and any data leaving would also be encrypted but I’ve never managed to get both the incoming & outgoing connections working at the same time.
In an effort to troubleshoot this I’ve used 2 different dynamic dns services for the incoming connection and also separated the devices that both the connections are running on. I’ve tried using different ports & the result is still the same.
At the moment I have one single board computer running the outgoing connection (working fine) and a completely separate single board computer running the incoming connection (which also works fine).
The issue is, in order to be able to VPN into my network, I need to stop the outgoing connection, it just times out if the other connection is running.
If I connect using the incoming connection & then start the outgoing connection, all data on the incoming connection stops?
I’m thinking that, with both connections being on completely separate SBC’s and (for the most part) working ok, the issue only happens when both incoming & outgoing VPN’s are active.
Is it possible TalkTalk are limiting the connections?
I tried to contact support over the phone only to be told that it’s basically my problem & that Talk talk don’t offer support for third party applications, I’ve had a good read through the forum and didn’t find anyone else who has had this issue.
I have the TalkTalk Wi-Fi Hub, I also tried using the older router that from when I first joined Talk Talk & the results are the same.
I can’t pinpoint the issue, I’m guessing it’s out of my control, either the Talk Talk network or possible the router is stopping the client connecting to the server.
Any help would be greatly appreciated.
I think the first stage of anything like this is to prove if your service works correctly with the WiFi hub only, totally forgetting this router you have built. If it does not work via the hub, only then would TalkTalk investigate it.
Many thanks for your reply.
I still use the Talk Talk WiFi hub, this is used as the main (edge) router. This is in place at it’s generic internal IP address.
The VPN router is on its own static internal IP. If I want to use the VPN, I simply point said device to the internal IP of the VPN router, this handles the bulk of traffic, things like smart home tech, general browsing etc. After encryption, it then uses the default gateway (Talk Talk’s WiFi Hub) to gain access to the internet.
I hope this help to give a bit more detail on how the setup is configured.
I think to be investigating a problem such as this would require a Wireshark trace, I can analyse this for you.
Hi Keith, thanks great, many thanks for your help.
I’m familiar with Wireshark but I’ve never used it. I’m guessing I’d just capture the data and send it via private message in a file??
Is there anything I’d need to simulate, as in the incoming VPN trying to connect, but unable to due to the outgoing connection running?
Just a capture of what you are trying to do. Please can you also give me a simple net diagram, or is it a totally flat L2 network?
I’ll draw up diagram showing the critical information, it’s quite a simple network to be honest, utilising an additional switch, no vlans or anything like that in use at the moment.
I have had a very quick look at the trace:-
trying to connect to incoming vpn with outgoping vpnn runing.pcapng
I can see the UDP traffic from the OpenVPN Client to your incoming VPN server on port 6827 flowing both ways without issue, but should it be onward routing to another device on your network?
Just started looking at the trace:-
trying to connect to incoming vpn (from within my wireless network) with outging vpn connect running.pcapng
Please can you identify these two MAC addresses for me, one would seem to be a Raspberry (b8:27:eb:e3:b4:c3) & the other an Asustek (0c:9d:92:0c:39:d2). What are their functions in your network?
One of the problems, when a capture takes place on a Linux machine, is that a Linux interpretation of the standard Ethernet header is used. This is called a "Linux Cooked Capture". Unlike the standard Ethernet header, this only shows the source address at L2 & not the destination one.
Many thanks for having a look at this for me.
I forgot to mention, that I had to move the position of the .8 device and plug this into the Talk Talk Wifi hub at its default IP address.
(The only way to get Wireshark working was to change the Linux distribution and have it connected directly to a display).
It's odd there is traffic flowing (trying to connect to incoming vpn with outgoping vpnn runing.pcapng) as it doesn't connect. When the outgoing VPN is running & I try to establish the incoming connection it just times out & quits.
(I'm wondering if I've named the file correctly)??
In an ideal world, any data that is requested from the incoming VPN connection should be bounced off .3, (for encryption as its leaving my home network).
The .8 device uses the .3 for its gateway, so let's say I'm connected to the .8 device from outside my home network and I visit ipinfo.io, it "should" say I'm connected to PIA servers in London (for example).
The .3 device uses the Talk Talk Wifi Hub as its gateway.
The broadcasts from .7, this is a media server so it's probably advertising its position, waiting/hoping for devices to connect to it.
I'll need to confirm the MAC address with you later this evening as they are not on my spreadsheet with most of the other smart home tech.
If the Linx captures are not up to spec, I have an old windows PC in the cupboard, if I get that out and plug .3 & .8 into the Talk Talk Wifi Hub, along with the windows machine, and redo the captures would that work better?
(I'd imagine that would help to cut out the chatter from other devices that are not relevant)
There would be a simple solution to some of this if you were using the WiFi hub as the gateway for both the outgoing & the incoming VPNs. Traffic going out from the hub to the internet & back in again is blocked. These routers class this as loopback traffic & consider this a security risk. However, that is not your case as your diagram shows two different internet connections.
Please can you explain in more detail how the internet connection used by the openVpn clients get to the server?
I'll have another look at the traces tomorrow now.
I changed the gateway of the .8 device to use the Talk Talk WiFi Hub as its gateway & both VPN’s were able to connect at the same time.
This is great because it’s a step in the right direction but unfortunately, this isn’t exactly what I was hoping to achieve. I was hoping to have a “double hop” VPN (as detailed in this tutorial https://www.comparitech.com/blog/vpn-privacy/raspberry-pi-vpn/), so all data was encrypted.
At least we now know the issue is on my side, possibly configuration of the devices, I’d lean towards the IP Tables being wrong, but to tell the truth, I don’t know how to read IP Tables to spot what’s actually wrong.
Many thanks for all your help so far Keith.
I haven't tested the routing protocols available on the WiFi hub, I assume it offers OSPF & RIP V2. A gotcha with static routes is that you need one in the reverse direction as well. Cisco routing tables are easy enough to read, but I have no idea about this router you built. No TalkTalk router is really envisaged to work like your scenario, although it should. They must have routing tables, but it is just that they are impossible to see.
Let me know if I can help anymore.
Do you happen to know much about IP Tables?
These are the IP tables I’m using in the .3 device at the moment:
sudo iptables -A INPUT -i lo -m comment --comment "loopback" -j ACCEPT
sudo iptables -A OUTPUT -o lo -m comment --comment "loopback" -j ACCEPT
sudo iptables -I INPUT -i eth0 -m comment --comment "In from LAN" -j ACCEPT
sudo iptables -I OUTPUT -o tun+ -m comment --comment "Out to VPN" -j ACCEPT
sudo iptables -A OUTPUT -o eth0 -p udp --dport 1198 -m comment --comment "openvpn" -j ACCEPT
sudo iptables -A OUTPUT -o eth0 -p udp --dport 123 -m comment --comment "ntp" -j ACCEPT
sudo iptables -A OUTPUT -p UDP --dport 67:68 -m comment --comment "dhcp" -j ACCEPT
sudo iptables -A OUTPUT -o eth0 -p udp --dport 53 -m comment --comment "dns" -j ACCEPT
sudo iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun+ -m comment --comment "LAN out to VPN" -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE
I'm guessing that’s were the issue is, but I’m just not skilled enough to spot what’s wrong, I’d have to sit a networking/computer science class to get to grips with them.
The tutorial I linked above has a different set that I could never get working, these seem to work fine for the outgoing VPN, just not too well for the incoming (but it should still let me point another device to it and send traffic, that’s all I’m doing with my other devices).
With words like "accept" this is much more like Access Control Lists, which is not the same as a routing table. A routing table displays the networks that the router knows about, it tells you how to get to a particular network. It gives the next hop address (the next router that the packet will be sent to, which interface the packet must route out on to get to that network & any "cost" involved.
Have a look at this:-
Yes those tables are somewhat different aren’t they.
I don’t suppose you know a way to achieve what I’m looking for, perhaps with additional networking equipment?
Many thanks for all all your help, at least we have narrowed down the issue.