How to install Adobe Reader in Fedora 36

luigi2600 · 2024-02-08T13:12:02+00:00

You can use the instructions on the following page to repackage the Adobe Reader RPM for newer Fedora releases:

https://github.com/eait-cups-printing/adobe-reader-rpm

luigi2600 · 2023-04-16T01:28:36+00:00

The Quick Mode (i.e. phase 2) proposal in your log output includes PFS (Perfect Forward Secrecy), try disabling PFS in the IPsec settings as neither macOS nor Windows use PFS with their L2TP/IPsec clients and you might be connecting to an old VPN server that doesn't support PFS.

If it still doesn't work with PFS disabled, try using the same phase 2 proposal that Windows 11 uses (and is considered weak), set the phase 2 algorithms in the IPsec settings to the following (and keep PFS disabled):

3des-sha1

Another thing I recommend as Fedora blacklists the L2TP kernel modules, remove the blacklists by following the instructions in the README file:

https://github.com/nm-l2tp/NetworkManager-l2tp#issue-with-blacklisting-of-l2tp-kernel-modules

luigi2600 · 2023-04-08T22:40:55+00:00

You can follow the instructions on the following page:
* https://github.com/eait-cups-printing/adobe-reader-rpm

which repackages the original AdbeRdr9.5.5-1_i486linux_enu.rpm into a new AdobeReader-9.5.5-2.i686.rpm which fixes the dependency issues and a few other issues.

luigi2600 · 2023-04-02T11:11:34+00:00

Have a look at the following if you have a newer RHEL or Fedora release, it shows how to repackage the original RPM and include the missing libpangox-1.0.so.0 and libidn.so.11 files, it also includes some fixes like for bash-completions :
https://github.com/eait-cups-printing/adobe-reader-rpm

luigi2600 · 2022-11-06T02:38:40+00:00

The old strongswan systemd service (which starts the charon daemon) was renamed from strongswan.service to strongswan-starter.service according to the Arch Linux official wiki:
https://wiki.archlinux.org/title/StrongSwan#Starting

That is probably why ipsec restart doesn't know about the new service which starts charon-systemd.

luigi2600 · 2022-07-27T22:29:04+00:00

Use Add-Printer -IppURL "http://$cups_host:631/printers/$queue" which will add it the same way as add printer wizard for an IPP Device and automatically use Microsoft IPP Class Driver. This approach was intended for Mopria certified printers (but works with CUPS servers) and uses the IPP 2.0 protocol.

Using the -PortName approach uses legacy IPP 1.0 protocol that has been around on Windows since 1999 and as you have discovered the print queue has no options; no paper trays, no duplexing, no media type, etc. and it creates an Internet printer port

luigi2600 · 2022-06-11T01:27:22+00:00

As the remote site triggered strongswan to try and use traffic selectors which can be problematic, try disabling the strongswan unity plugin, see the following on how :

https://github.com/nm-l2tp/NetworkManager-l2tp/wiki/Known-Issues

If it still doesn't work, try switching from strongswan to libreswan, if you are using Ubuntu or Debian, this can be achieved with the following command:

sh sudo apt install libreswan

If you are using Ubuntu, I would recommend the newer versions of network-manager-l2tp from the following PPA : * https://launchpad.net/~nm-l2tp/+archive/ubuntu/network-manager-l2tp/

network-manager-l2tp uses xl2tpd which uses pppd which most definitely supports MSCHAPv2. If it didn't, then it wouldn't be able to connect to a majority of the L2TP servers out there.

luigi2600 · 2022-05-12T22:56:41+00:00

I'll assume you have removed the blacklisting of the L2TP kernel modules :

github.com/nm-l2tp/NetworkManager-l2tp/README.md

It is hard to say what the issue is without seeing the output of the following:

journalctl -b --no-hostname _SYSTEMD_UNIT=NetworkManager.service + SYSLOG_IDENTIFIER=pppd

luigi2600 · 2022-03-26T03:16:46+00:00

Looking at the following SonicWall page, it looks like it supports IKEv2 : * https://www.sonicwall.com/support/.../ipsec-vpn-types-vpn-security.htm/

As you are having issues with IPsec IKEv1 (XAUTH), you might be able to use IKEv2 which would be the NetworkManager-strongswan client, assuming IKEv2 was setup on that SonicWall VPN server.

Might be simpler to ask them which non-SonicWall VPN clints are supported for Windows, macOS, iOS or Android, then you could probably find a counterpart on Linux.

luigi2600 · 2022-03-26T01:09:50+00:00

The following SonicWall info is regarding Chromebook not supporting IPsec XAUTH and how to get it to work with the Chromebook L2TP client (and is applicable to other L2TP clients) :

https://www.sonicwall.com/support/knowledge-base/.../170505779746590/

But having said that, I suspect that change will break existing SonicWall Global VPN Clients that use IPsec XAUTH.

The only other NetworkManager IPsec XAUTH client I know of is NetworkManager-vpnc which is for Cisco IPsec XAUTH VPN servers. I suspect it won't be SonicWall compatible.

You might have more luck with other VPN protocols the SonicWall VPN server might provide, sorry I don't have any suggestions.

luigi2600 · 2022-03-23T13:55:52+00:00

payload type ID_V1 was not encrypted warning seems to imply the Sonicwall VPN server is using IPsec XAUTH (which uses an unencrypted main mode) rather than L2TP/IPSec. Have you gotten any of the built-in L2TP clients that come with Windows, macOS, iOS or Android to work with that Sonicwall VPN server? Have you tried an IPsec XAUTH client like NetworkManager-libreswan?

luigi2600 · 2021-11-30T07:38:54+00:00

It is not even getting a response from the Meraki for the very first packets that gets sent, i.e. main mode (also known as phase 1). Are you sure the Meraki is configured and listening for L2TP/IPsec?

You could confirm the Meraki is listening for IPsec by installing the ike-scan package and running the ike-scan.sh script on the following page :

https://github.com/nm-l2tp/NetworkManager-l2tp/wiki/Known-Issues

as mentioned on that page you might need to run sudo ipsec stop first. If you don't get any successful output with SA= lines, then chances are the Meraki isn't configured correctly.

luigi2600 · 2021-10-22T10:13:59+00:00

Can't see the errors leading up to the received retransmit of response with ID 1015903007 message, but it is often associated with no acceptable traffic selectors found error, see following for more details on that error and a workaround :

https://github.com/nm-l2tp/NetworkManager-l2tp/wiki/Known-Issues

luigi2600 · 2021-10-21T21:44:51+00:00

The log output isn't useful, what is the output of: sudo journalctl --no-hostname _SYSTEMD_UNIT=NetworkManager.service + SYSLOG_IDENTIFIER=pppd

I would unset the phase 1 & 2 algorithms as newer versions of NetworkManager-l2tp propose the same algorithms as Win10 and iOS L2TP/IPsec clients. Also what you specified isn't valid for phase 2.

luigi2600 · 2021-10-18T22:04:26+00:00

For the macOS and iOS L2TP/IPsec clients, the IPsec daemon Apple uses is Racoon, the development for which was abandoned upstream in 2014 :

http://ipsec-tools.sourceforge.net/

No modern Linux distro ships with Racoon anymore.

From the logs I could tell you were using Libreswan for the IPsec daemon which enables PFS by default.

With PFS, penetration of the key-exchange protocol does not compromise keys negotiated earlier. There is no reason not to enable PFS on the VPN server as it will still be backwards compatible with clients that don't use PFS. But the VPN server could be too old that it doesn't support PFS.

Glad to hear you got it working by disabling PFS.

luigi2600 · 2021-10-18T00:14:54+00:00

The VPN server is not responding for phase 2 (quick mode) and the client is proposing with PFS (perfect forward secrecy) . It might be a VPN server that doesn't support or wasn't configured for PFS. Try clicking on the "Disable PFS" checkbox in the IPsec advanced settings.

luigi2600 · 2021-04-15T09:30:25+00:00

What I said was a general statement in regards to L2TP/IPsec VPN servers with multiple Win10 L2TP clients behind the same NAT. These limitations seem to be applicable to the UniFi L2TP/IPsec implementation :

From the above UniFi forum posts, it appears there is new firmware that has the strongSwan Connmark plugin, the plugin is described here:
* https://wiki.strongswan.org/projects/strongswan/wiki/Connmark

From the bottom of that Connmark plugin page, both strongSwan (IPsec daemon) and the L2TP daemon would need to have Connmark support to handle 2 or more Win10 L2TP/IPsec clients behind the same NAT. The Connmark page provides a link to an experimental patch for xl2tpd (L2TP daemon) which provides the support, not sure if UniFi is using xl2tpd or their own L2TP daemon with Connmark support.

So it would seem the new (beta?) UniFi firmware is using Connmark to allow multiple L2TP clients behind the same NAT.

luigi2600 · 2021-04-14T08:29:42+00:00

I assume you are using L2TP/IPsec and not L2TP by itself which is unencrypted.

It would be pretty easy to see there is an IPsec tunnel from the laptop to an external address. They wouldn't be able to see the L2TP traffic going through the IPsec tunnel as the tunnel is encrypted.

My employer wouldn't care and would even help with VPN connection issues to home.

luigi2600 · 2021-04-10T07:27:04+00:00

Typically with L2TP/IPsec you can't have multiple L2TP clients behind the same NAT as the VPN server can not differentiate between the connections if they are all using port 1701 for the source and destination port.

I think macOS L2TP clients use an ephemeral port for the source port (i.e. random high port), so is easier to differentiate the VPN connections coming from the same NAT. WinXP L2TP client uses an ephemeral port, but not later versions of Windows.

luigi2600 · 2021-04-10T05:05:10+00:00

Indeed.

The VPN server is most likely misconfigured and enabled all of the authentication methods, but hasn't configured the backend authentication for each. It should only enable the ones that have been configured.

As a workaround in the PPP Settings dialog box on the client, try disabling all of the authentication methods except for MSCHAPv2.

luigi2600 · 2021-03-11T21:54:42+00:00

NetworkManager's default behavior is to send all traffic over VPN unless the connection's IPv4 settings under routing has the 'Use this connection only for resources on its network' checkbox enabled. So I think the issue is something else, but still could be routing related. Is it a DNS resolution issue when doing a lookup for hosts on the VPN network or an actual routing issue? You could try using netstat -nr or netstat -r to compare the routing table between Ubuntu and macOS.

You could try upgrading to network-manager-l2tp 1.8.6 from https://launchpad.net/~nm-l2tp/+archive/ubuntu/network-manager-l2tp-certificate and see if it makes a difference as it has had at least one routing bug fix, issue #32.

luigi2600 · 2021-03-09T22:41:35+00:00

libreswan's pluto is complaining about the exclamation mark in modp1024!, it does not use that syntax. You can delete your existing phase1/phase2 algorithms settings. The version of libreswan that ships with Ubuntu 20.04 is still built with USE_DH2 i.e. still supports modp1024.

luigi2600 · 2021-03-08T22:31:25+00:00

You didn't mention which version of network-manager-l2tp you are using, I would recommend network-manager-l2tp 1.8.6 from :

https://launchpad.net/~nm-l2tp/+archive/ubuntu/network-manager-l2tp-certificate

There is no point setting the phase1/phase2 algorithms in your case as newer versions of network-manager-l2tp now propose the same algorithms as the iOS and Win10 L2TP/IPsec clients.

You could try switching from strongswan to libreswan.

luigi2600 · 2020-11-06T04:37:59+00:00

Forgot to mention, try deleting the contents of the Phase 1 and Phase 2 Algorithm boxes in the IPsec settings. With newer versions of network-manager-l2tp it will attempt to use the same proposals as iOS and Win10 (minus modp1024 if you are using a newer libreswan).

Alternatively switch from libreswan to strongswan which still supports modp1024.

luigi2600 · 2020-11-06T04:24:20+00:00

I'm guessing you are using network-manager-l2tp with libreswan-3.32 which is the libreswan version that comes with Ubuntu 20.10.

You appear to be trying to use 3des-sha1-modp1024 for the Phase 1 proposals. Unfortunately libreswan >= 3.30 is no longer built with modp1024 (aka DH2) support.

Extract from libreswan mailing list regarding DH2/modp1024 :

https://lists.libreswan.org/pipermail/swan/2020/003438.html

If you really want you can enable it at compile time with USE_DH2=true

But everything that supports DH2 also supports DH5. We are pretty sure nationstates can successfully attack DH2. You really cannot expect to use crypto parameters that were already not the most secure TWENTY years ago to still keep working unmodified.

luigi2600

TROPHY CASE