Posted: Sat Jan 08, 2022 17:37 Post subject: tcp4 broken in latest openvpn builds
Earlier this week I setup a set of routers for a customer with a LAN2LAN vpn using OpenVPN.
I used the latest December 2021 firmware and duplicated the OpenVPN configuration I use on my own personal interconnection.
No way no how could I get the tunnel to come up. It worked when setting the protocol to udp4 but not tcp4.
When I backreved both devices to the 10-28-2021 dd-wrt firmware the tunnel came up fine. On the newer code I did get a partial vpn to work by adding the line
iptables -I INPUT 1 -p tcp --dport 1194 -j ACCEPT
into the "server" side of the VPN router (that is, I was able to ping from one of the networks to the tun interface of the other router on the other end of the VPN link) but I could not get traffic to pass from lan to lan subnet until reverting to the older firmware
I can see from the logs that there's been a newer version of OpenVPN added into the code as well as some more options added into the GUI.
As I'm suspicious that other things may have been broken due to this modification I left it at the older code.
Devices are a Linksys EA6300 and Netgear R6400v1 however I also tried different router models on both sides to see if it would make a difference, it did not.
LAN2LAN (sometimes referred to as gateway 2 gateway) means:
1) I have control over both ends of the VPN and the devices each end terminates into
2) There are lans behind each VPN router/termination device that need to send traffic to each other
3) The lans are different subnets
4) Essentially the devices on each LAN need to be completely unaware they are sending traffic through a VPN tunnel vs any other routed WAN connection.
I say LAN2LAN in these posts because the majority of people running VPN's are doing it client-to-server meaning a PC client running some VPN client software connecting into a dd-wrt router that's a VPN server (aka vpn concentrator) or a dd-wrt router setup as a vpn client going to some commercial vpn provider.
When they say "I'm running a VPN" what they mean is they are running a VPN _CLIENT_
When they say "I'm running a tunnel" what they also mean is they are running a VPN client.
If I was running a dd-wrt router as a VPN client to a commercial service I would call it "VPN client to server" connection as that's the proper description.
OK then IMHO there's a bug that was introduced in the GUI by the recent changes. The "Apply Settings" button on the VPN page should restart both the firewall and openvpn process not just restart the openvpn process since now we have a dependency in there on restarting the firewall. Either that, or there needs to be a statement next to the VPN protocol option saying to reboot the router after making the changes. If you agree I'll file a bug.
Thanks! I wouldn't have been caught by it if this was a first time install because I would have been rebooting a lot more frequently. You tend to do that on the first iteration of something. Or if I had already done 20 duplicates of this kind of installation. This is one of those ones that bites you when you know enough to be dangerous.
Joined: 13 Aug 2013 Posts: 6779 Location: Romerike, Norway
Posted: Sun Jan 09, 2022 10:15 Post subject:
I just wonder why you want to use tcp.
tcp does not work as good as udp because it will introduce double end-to-end control. A missing packet will be resent by tcp, but before it will arrive at the vpn stack, a resend is already issued and the packet resent by tcp is discarded
I don't, not on this setup. The customer has 2 Comcast links and the packets probably aren't even leaving Comcast's network plus most of the traffic is likely TCP. I noticed it when troubleshooting what I thought was a problem in the VPN that turned out to actually be something else.
However, I have a different VPN setup where it's required, because I have VoIP registration traffic over that setup and it is not reliable over UDP. That is understandable because one of the giant holes in VoIP standards large enough to drive a truck through is making UDP the default registration protocol for SIP. The IETF assumed, apparently, that there would be no such thing as a VoIP extension that would be located hundreds of miles away from the phone system that the extension registered into.
It's understandable to make the SIP traffic carrying the actual voice UDP. But they decided that UDP would be "good enough" for SIP line registration traffic. That's a OK assumption when the phone itself is 2 floors from the PBX. It's not then the phone isn't.
You cannot depend on UDP being tunneled over UDP. Since nothing is reliable in that setup, if the 2 hosts communicating (the extension and the PBX) assume the connection is highly reliable (like a corporate ethernet network) then they won't tolerate a lot of drops of packets that would happen over a VPN over the Internet..
Modern VoIP phones allow you to select tcp for SIP registration but some phones won't register to some PBXes over tcp as it's less standard.
In this case the customer doesn't have anything like that, fortunately. What irked me the most about the setup was the 2 buildings involved are literally a stones throw from each other. I was pushing them to just lay cable and be done with it. $1500 would have dropped a PVC pipe and cable on the surface of the groups maybe $3k for a shallow trench. Then they would have got a gigabit. But they would rather spend $180 a month for God-knows how long, probably the next decade or more. It's enough to piss off an idiot.