[tedm]

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.

[egc]

With LAN2LAN are you referring to a site-to-site setup?

[tedm]

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.

See

https://www.urbandictionary.com/define.php?term=Precision%20of%20language

[egc]

I just wanted to make sure

I am running that now with server on 47915 and client on 47976.

I am running it with udp4 so I switched to tcp4 and ... no connection.
After a change you have to reboot the router or from CLI: restart firewall

Not really convenient but the firewall rules are in the firewall not my choice but it is what it is (I will spare you the details)

If the firewall is not restarted or the router not rebooted that rule you are referring to is not made

Furthermore make sure the CVE mitigation is disabled otherwise you cannot reach your LAN clients

When doing that I have no problem and both sides can see each other and clients from both sides can use each others drives

[tedm]

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.

[egc]

No need to do that, I will add that text in the upcoming update.

It is clearly stated in the manual though, sometimes reading the manual does help

(I know real man do not read manuals )


Edit: this is not from the recent changes this is already from much longer ago

[tedm]

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.

[kernel-panic69]

@egc: I suggest let some dust settle, check current ovpn tix. Then see if BS can implement a fix, unless you can submit a patch. I am sure folks would prefer to have "apply" functionality here.

[egc]

I can supply a fix no problem, just have to factor in the pro's and cons

[kernel-panic69]

Add a "reboot router" button at bottom of the page...

[egc]

Certainly an option

TBC

[Per Yngve Berg]

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

[tedm]

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.