Closed dledford closed 1 year ago
If people are curious, this is the actual log of the push message the server sends:
2023-01-23 13:45:13 PUSH: Received control message: 'PUSH_REPLY,route 10.12.0.0 255.255.0.0,route-ipv6 2606:4100:3880:3101::0/64,route-ipv6 2606:4100:3880:3102::0/64,redirect-privat e,dhcp-option DNS 10.8.2.1,dhcp-option DOMAIN ofa.iol.unh.edu,tun-ipv6,route-gateway 10.8.2.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 fd30:a947:ab4a:a7c2::1007/64 fd3 0:a947:ab4a:a7c2::1,ifconfig 10.8.2.9 255.255.255.0,peer-id 2,cipher AES-256-GCM'
I suspect redirect-private can be removed from the options. I know Lincoln had talked about certain systems you have to go in and disable default route munging when you bring up the vpn. That is likely due to the redirect-private command. The docs are a little vague on redirect-private, only saying "Like --redirect-gateway, but omit actually changing the default gateway. Useful when pushing private subnets." Unfortunately, there are three different steps in changing the default gateway, and it's not clear that this means "don't do any of the three" or "don't delete the original default route", in which case a conflicting default route could be created by the third step. I suspect that this option is not needed at all, as it's really there to allow things like "redirect-private !ipv4 ipv6" where you need the ability to pass the flags that are valid for redirect-gateway without also changing the default route. In our case, we only have to worry about two routes (per ipv4 and per ipv6): one for the subnet we are on, which is automatically created when we config the IP interface, and one for the routed IP subnet, which is pushed manually. Since those two routes are already created, both redirect-gateway and redirect-local are redundant/unnecessary as long as you don't need any of the optional flags those two options support.
It's like the client config file was out of date, i.e. generated quite a while ago, from an older template. Newest template, already had the following set.
auth SHA256 cipher AES-256-GCM
I did drop the nobind from the "nobind" option from the template, as well as the "redirect-private" from the server config, but have not kicked it yet for a restart.
Other issues were not in the current files.
Issue resolved, new server/client configs in place and tested
I got the vpn up and working again, but there are some needed changes in the config files you give to users:
1) Need to drop comp-lzo from the config file. It's considered unsafe, the server side isn't using it, and it causes failure to recv messages on the client side. When it's enabled, you get this config warning:
2023-01-23 13:44:09 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
followed by all incoming packets being dropped with this error:
2023-01-23 13:44:20 Bad LZO decompression header byte: 42
2) The connection won't come up if you remove the auth SHA256 line from the config. However, with the line in place, we do get this warning on startup:
2023-01-23 13:44:09 WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth [null-digest]'
I would guess that maybe the server should be set to auth SHA256 too? I don't know how to set the client to [null-digest] as that's not a valid config option.
3) I suggest removing "cipher AES-256-CBC". It's an outdated config option (replaced by data-ciphers instead, which is supposed to be a list), an outdated cipher, and it's not what the server actually wants to use, which is AES-256-GCM instead. When you remove that line, the connection properly autonegotiates the best cipher.
4) Suggest dropping nobind from the config. For people that need to make a firewall rule to allow the traffic, it's easier when both ends bind their ports.
With these changes, my connection is running smooth again.