Re: NM 1.4.4 and hotspot problem
Hi Dan, added xt_conntrack and all iptables passed ;). I also fixed dnsmasq problem. It looks like it conflicts with named so by disabling named I can successfuly run hotspot. Thanks for all support. Marek On Thu, Feb 22, 2018 at 8:13 PM, Belisko Marek wrote: > Hi Dan, > > On Thu, Feb 22, 2018 at 6:06 PM, Dan Williams wrote: >> On Thu, 2018-02-22 at 08:37 +0100, Belisko Marek wrote: >>> Hi Dan, >>> >>> On Wed, Feb 21, 2018 at 11:45 PM, Dan Williams >>> wrote: >>> > On Wed, 2018-02-21 at 22:46 +0100, Belisko Marek wrote: >>> > > Hi Dan, >>> > > >>> > > On Tue, Feb 20, 2018 at 11:53 PM, Dan Williams >>> > > wrote: >>> > > > On Tue, 2018-02-20 at 22:47 +0100, Belisko Marek wrote: >>> > > > > Hi Dan, >>> > > > > >>> > > > > On Tue, Feb 20, 2018 at 10:11 PM, Dan Williams >> > > > > om> >>> > > > > wrote: >>> > > > > > On Tue, 2018-02-20 at 21:00 +0100, Belisko Marek wrote: >>> > > > > > > Hi, >>> > > > > > > >>> > > > > > > I'm trying to configure hotspot by using this command: >>> > > > > > > nmcli dev wifi hotspot ifname wlan0 ssid test password >>> > > > > > > "test1234" >>> > > > > > > >>> > > > > > > on orangepi which is using realtek wifi (out of tree >>> > > > > > > driver). >>> > > > > > > When >>> > > > > > > want to setup simple hotspot it looks like there are soe >>> > > > > > > mtroubles >>> > > > > > > with iptbles + dnsmasq. Any ideas what can cause this >>> > > > > > > issue? >>> > > > > > > Thanks >>> > > > > > >>> > > > > > Your analysis looks correct. What happens when you run the >>> > > > > > iptables >>> > > > > > command manually? >>> > > > > > >>> > > > > > /usr/sbin/iptables --table nat \ >>> > > > > >--insert POSTROUTING --source 10.42.0.0/255.255.255.0 \ >>> > > > > >! --destination 10.42.0.0/255.255.255.0 --jump >>> > > > > > MASQUERADE >>> > > > > > >>> > > > > > does /usr/sbin/iptables exist? >>> > > > > > >>> > > > > > does your kernel have the ipt_MASQUERADE, iptable_nat, >>> > > > > > nf_conntrack, >>> > > > > > iptable_mangle, and other modules like that available? >>> > > > > >>> > > > > I've nmcli c up Hotspot >>> > > > >>> > > > What does your 'iptables-save' output look like on this >>> > > > machine? >>> > > >>> > > It looks like this: >>> > > >>> > > iptables-save >>> > > # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018 >>> > > *filter >>> > > :INPUT ACCEPT [61:11807] >>> > > :FORWARD ACCEPT [0:0] >>> > > :OUTPUT ACCEPT [42:7785] >>> > > COMMIT >>> > > # Completed on Wed Feb 21 21:42:54 2018 >>> > > # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018 >>> > > *nat >>> > > :PREROUTING ACCEPT [0:0] >>> > > :INPUT ACCEPT [0:0] >>> > > :OUTPUT ACCEPT [0:0] >>> > > :POSTROUTING ACCEPT [0:0] >>> > > COMMIT >>> > > # Completed on Wed Feb 21 21:42:54 2018 >>> > > root@orange-pi-pc-plus:~# lsmod >>> > > Module Size Used by >>> > > ipt_REJECT 16384 -2 >>> > > ipt_MASQUERADE 16384 -2 >>> > > xt_tcpudp 16384 -2 >>> > > iptable_filter 16384 -2 >>> > > iptable_nat16384 -2 >>> > > ip_tables 20480 -2 >>> > > x_tables 20480 -2 >>> > > mali 208896 -2 >>> > > 8189fs 1224704 -2 >>> > > >>> > > >>> > > I've added more kernel modules (according : >>> > > https://wiki.gentoo.org/wiki/Iptables#Kernel) and output look >>> > > much >>> > > better (unfortunately there are still some problems): >>> > >>> > Ok, so the issue with iptables is solved (at least I think?), but >>> > now >>> > it's dnsmasq. There was a problem in Debian a while back, where >>> > just >>> > installing dnsmasq set up a configuration that did this, which >>> > meant >>> > that NM could not run its own interface-specific dnsmasq. >>> >>> Issue with iptables remains (I think last one): >>> Feb 21 21:39:28 orange-pi-pc-plus user.info NetworkManager[765]: >>> [1519249168.1555] Executing: /usr/sbin/iptables --table >>> filter >>> --insert FORWARD --destination 10.42.0.0/255.255.255.0 --out- >>> interface >>> wlan0 --match state --state ESTA >>> BLISHED,RELATED --jump ACCEPT >>> Feb 21 21:39:28 orange-pi-pc-plus user.warn NetworkManager[765]: >>> [1519249168.1786] ** Command returned exit status 1. >> >> Ok, for the "--state" extension you need the conntrack kernel module. > I have already those present: > CONFIG_NF_CONNTRACK=y > CONFIG_NF_CONNTRACK_MARK=y > # CONFIG_NF_CONNTRACK_PROCFS is not set > # CONFIG_NF_CONNTRACK_EVENTS is not set > # CONFIG_NF_CONNTRACK_TIMEOUT is not set > # CONFIG_NF_CONNTRACK_TIMESTAMP is not set > # CONFIG_NF_CONNTRACK_AMANDA is not set > CONFIG_NF_CONNTRACK_FTP=y > CONFIG_NF_CONNTRACK_H323=y > CONFIG_NF_CONNTRACK_IRC=y > CONFIG_NF_CONNTRACK_BROADCAST=y > CONFIG_NF_CONNTRACK_NETBIOS_NS=y > CONFIG_NF_CONNTRACK_SNMP=y > CONFIG_NF_CONNTRACK_PPTP=y > # CONFIG_NF_CONNTRACK_SANE is not set > CONFIG_NF_CONNTRACK_SIP=y > CONFIG_NF_CONNTRACK_TFTP=y > CONFIG_NF_CONNTRACK_IPV4=y > CONFIG_NF_CONNTRACK_IPV6=y > > Thanks. > > Marek >>
Re: nmcli can't astablish connection to radius server with wpa eap tls
Hi,That EAP-TLS isn't supporting passwords maybe the case.I configure my freeradius server without passwords and set in nmcli the password-flag to 4 (no password required).I got the same error as if I had before.nmcli device connect wlan0 Passwords or encryption keys are required to access the wireless network 'Linksys02355'. Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli cannot ask without '--ask' option. Error: Connection activation failed: (7) Secrets were required, but not providedAlthough my radius server tells me that it accepts the authentication send from nmcli.Is there something else that I'm missing?IrisAm 21.02.2018 09:24 schrieb Beniamino Galvani :On Mon, Feb 19, 2018 at 12:59:04PM +0100, Iris Fiedler wrote: Hi, > freeRADIUS: 3.0.15 (on a different PC with OpenSuse 42.3) > Konfigured as wpa-eap tls with identity and password. EAP-TLS doesn't support passwords AFAIK. Perhaps you mean EAP-TTLS? > radius-tls.log > (35) Invalid user: [testUser1/] (from client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) > (35) Rejected in post-auth: [testUser1/] (from client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) > (35) Login incorrect: [testUser1/] (from client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) > > As you can see the User-Password attribute is missing. Although the password in nmcli was set. > > This is what nmcli is responding with: > nmcli device connect wlan0 > Passwords or encryption keys are required to access the wireless network 'Linksys02355'. > Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli cannot ask without '--ask' option. > Error: Connection activation failed: (7) Secrets were required, but not provided. > > nmcli -a device connect wlan0 > Passwords or encryption keys are required to access the wireless network 'Linksys02355'. > Identity (802-1x.identity): testUser1 > Passwords or encryption keys are required to access the wireless network 'Linksys02355'. > Private key password (802-1x.private-key-password): > Passwords or encryption keys are required to access the wireless network 'Linksys02355'. > Identity (802-1x.identity): testUser1 > > Even here no user password is asked!!! > > I created a new user without password. Although the radius server accepted the authentication no connection was established!!! > > It confused me so I checkt if a wpa eap ttls-pap would work. > After reconfiguration of nmcli and radius server it worked without problems. > So I think this is only a tls problem. Yes, EAP-TLS only uses certificates and not passwords. Beniamino ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 1.4.4 and hotspot problem
Hi Dan, On Thu, Feb 22, 2018 at 6:06 PM, Dan Williams wrote: > On Thu, 2018-02-22 at 08:37 +0100, Belisko Marek wrote: >> Hi Dan, >> >> On Wed, Feb 21, 2018 at 11:45 PM, Dan Williams >> wrote: >> > On Wed, 2018-02-21 at 22:46 +0100, Belisko Marek wrote: >> > > Hi Dan, >> > > >> > > On Tue, Feb 20, 2018 at 11:53 PM, Dan Williams >> > > wrote: >> > > > On Tue, 2018-02-20 at 22:47 +0100, Belisko Marek wrote: >> > > > > Hi Dan, >> > > > > >> > > > > On Tue, Feb 20, 2018 at 10:11 PM, Dan Williams > > > > > om> >> > > > > wrote: >> > > > > > On Tue, 2018-02-20 at 21:00 +0100, Belisko Marek wrote: >> > > > > > > Hi, >> > > > > > > >> > > > > > > I'm trying to configure hotspot by using this command: >> > > > > > > nmcli dev wifi hotspot ifname wlan0 ssid test password >> > > > > > > "test1234" >> > > > > > > >> > > > > > > on orangepi which is using realtek wifi (out of tree >> > > > > > > driver). >> > > > > > > When >> > > > > > > want to setup simple hotspot it looks like there are soe >> > > > > > > mtroubles >> > > > > > > with iptbles + dnsmasq. Any ideas what can cause this >> > > > > > > issue? >> > > > > > > Thanks >> > > > > > >> > > > > > Your analysis looks correct. What happens when you run the >> > > > > > iptables >> > > > > > command manually? >> > > > > > >> > > > > > /usr/sbin/iptables --table nat \ >> > > > > >--insert POSTROUTING --source 10.42.0.0/255.255.255.0 \ >> > > > > >! --destination 10.42.0.0/255.255.255.0 --jump >> > > > > > MASQUERADE >> > > > > > >> > > > > > does /usr/sbin/iptables exist? >> > > > > > >> > > > > > does your kernel have the ipt_MASQUERADE, iptable_nat, >> > > > > > nf_conntrack, >> > > > > > iptable_mangle, and other modules like that available? >> > > > > >> > > > > I've nmcli c up Hotspot >> > > > >> > > > What does your 'iptables-save' output look like on this >> > > > machine? >> > > >> > > It looks like this: >> > > >> > > iptables-save >> > > # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018 >> > > *filter >> > > :INPUT ACCEPT [61:11807] >> > > :FORWARD ACCEPT [0:0] >> > > :OUTPUT ACCEPT [42:7785] >> > > COMMIT >> > > # Completed on Wed Feb 21 21:42:54 2018 >> > > # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018 >> > > *nat >> > > :PREROUTING ACCEPT [0:0] >> > > :INPUT ACCEPT [0:0] >> > > :OUTPUT ACCEPT [0:0] >> > > :POSTROUTING ACCEPT [0:0] >> > > COMMIT >> > > # Completed on Wed Feb 21 21:42:54 2018 >> > > root@orange-pi-pc-plus:~# lsmod >> > > Module Size Used by >> > > ipt_REJECT 16384 -2 >> > > ipt_MASQUERADE 16384 -2 >> > > xt_tcpudp 16384 -2 >> > > iptable_filter 16384 -2 >> > > iptable_nat16384 -2 >> > > ip_tables 20480 -2 >> > > x_tables 20480 -2 >> > > mali 208896 -2 >> > > 8189fs 1224704 -2 >> > > >> > > >> > > I've added more kernel modules (according : >> > > https://wiki.gentoo.org/wiki/Iptables#Kernel) and output look >> > > much >> > > better (unfortunately there are still some problems): >> > >> > Ok, so the issue with iptables is solved (at least I think?), but >> > now >> > it's dnsmasq. There was a problem in Debian a while back, where >> > just >> > installing dnsmasq set up a configuration that did this, which >> > meant >> > that NM could not run its own interface-specific dnsmasq. >> >> Issue with iptables remains (I think last one): >> Feb 21 21:39:28 orange-pi-pc-plus user.info NetworkManager[765]: >> [1519249168.1555] Executing: /usr/sbin/iptables --table >> filter >> --insert FORWARD --destination 10.42.0.0/255.255.255.0 --out- >> interface >> wlan0 --match state --state ESTA >> BLISHED,RELATED --jump ACCEPT >> Feb 21 21:39:28 orange-pi-pc-plus user.warn NetworkManager[765]: >> [1519249168.1786] ** Command returned exit status 1. > > Ok, for the "--state" extension you need the conntrack kernel module. I have already those present: CONFIG_NF_CONNTRACK=y CONFIG_NF_CONNTRACK_MARK=y # CONFIG_NF_CONNTRACK_PROCFS is not set # CONFIG_NF_CONNTRACK_EVENTS is not set # CONFIG_NF_CONNTRACK_TIMEOUT is not set # CONFIG_NF_CONNTRACK_TIMESTAMP is not set # CONFIG_NF_CONNTRACK_AMANDA is not set CONFIG_NF_CONNTRACK_FTP=y CONFIG_NF_CONNTRACK_H323=y CONFIG_NF_CONNTRACK_IRC=y CONFIG_NF_CONNTRACK_BROADCAST=y CONFIG_NF_CONNTRACK_NETBIOS_NS=y CONFIG_NF_CONNTRACK_SNMP=y CONFIG_NF_CONNTRACK_PPTP=y # CONFIG_NF_CONNTRACK_SANE is not set CONFIG_NF_CONNTRACK_SIP=y CONFIG_NF_CONNTRACK_TFTP=y CONFIG_NF_CONNTRACK_IPV4=y CONFIG_NF_CONNTRACK_IPV6=y Thanks. Marek > > >> > This line: >> > >> > Feb 21 21:39:28 orange-pi-pc-plus daemon.info NetworkManager[765]: >> > dnsmasq: failed to create listening socket for 10.42.0.1: Address >> > already in use >> > Feb 21 21:39:28 orange-pi-pc-plus user.warn NetworkManager[765]: >> >[1519249168.4498] dnsmasq-manager: dnsmasq exited with >> > error: >> > Network access problem (address in use, permissions) (2) >> > >> > is likely the cu
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
Thomas Haller wrote: On Thu, 2018-02-22 at 11:43 -0500, David H. Durgee wrote: Thomas Haller wrote: On Wed, 2018-02-21 at 12:03 -0500, David H. Durgee wrote: Thomas Haller wrote: I will consider debug logging after you have a chance to inspect the connection show and let me know if it looks sane or is missing a crucial element. Hi, the settings don't look wrong, but whether the settings are correct depends very much on your server configuratoin. Enable debug logging and see why the connection failed. Since NM does not support the argument, you should investigate whether that argument is required in your setup. For example, (as you said, plain openvpn works) by running openvpn with the ovpn without the option. best, Thomas Per your suggestion I tried using openvpn with the edited file and as expected it fails to connect. So the appears to be required to initialize the connection. Now the question is how do I add them to the configuration? I manually added the contents of that element to a file ~/.certs/nm-openvpn/Ashburn-edited-extra-certs.pem along with the other elements, but that appears to be insufficient. I assume that I need to add the proper entry to /etc/NetworkManager/system-connections/Private Tunnel - Ashburn, but my question is what form does that entry take? In the [vpn] section I see various entries referencing the certificates, specifically: cert=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-cert.pem key=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-key.pem ca=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-ca.pem ta=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-tls-auth.pem So I assume I need a similar line for this one, but should it be "extra-certs=" or "ec=" there? I guess I could try both, but I would prefer to get it right the first time. Or is it perhaps something else entirely? Hi, Editing the connection of NetworkManager with a new option that is not supported by nm-openvpn plugin does not make it work. nm-openvpn plugin does not support this option (yet). See https://git.gnome.org/browse/network-manager-openvpn/commit/?id=master especially https://git.gnome.org/browse/network-manager-openvpn/tree/src/nm-openvpn-service.c?id=dd8868f8a020988a47b7d4d4b502a98531fdeee0 which constructs the command line arguments for openvpn binary. The proper solution is to add support for this option. Patches welcome. I doubt my programming skills are up to a patch for this. Is this one on the list somewhere of addition options to be supported? If not, can it be added? In either case, any idea of when it might be available? Is there a release schedule for the plugin? Possible work arounds are: - try to find a client configuration that does not require this option. Maybe reconfigure the server is feasable. Not in this case, this is not my server but a service provider. - use openvpn directly, without NetworkManager That is my current approach, I guess I can continue doing so while the option is added to the plugin. - replace the openvpn binary with a wrapper shell script, that hacks this option. Something like (totally untested!) #!/bin/bash EXTRA_ARGS= if [[ echo "$@" | grep -q '--remote MY.REMOTE.THAT.I.RECOGNIZE' ]]; then EXTRA_ARGS="--extra-certs /path/to/extra/certs" fi exec /path/to/real/openvpn "$@" $EXTRA_ARGS I guess that might work, but it is a bit messy. Given that I only need to use the service when taking my laptop out of the office I believe I can live with continuing to use openvpn directly until the plugin supports the option. I doubt that private tunnel is the only service using this option, so I suspect others are also encountering it and adding support to the plugin should be done at some point. Thanks again for your assistance in this matter. Dave ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
On Thu, 2018-02-22 at 11:43 -0500, David H. Durgee wrote: > Thomas Haller wrote: > > On Wed, 2018-02-21 at 12:03 -0500, David H. Durgee wrote: > > > Thomas Haller wrote: > > > > > > I will consider debug logging after you have a chance to inspect > > > the > > > connection show and let me know if it looks sane or is missing a > > > crucial > > > element. > > > > Hi, > > > > the settings don't look wrong, but whether the settings are > > correct > > depends very much on your server configuratoin. Enable debug > > logging > > and see why the connection failed. > > > > Since NM does not support the argument, you should > > investigate whether that argument is required in your setup. For > > example, (as you said, plain openvpn works) by running openvpn with > > the > > ovpn without the option. > > > > > > best, > > Thomas > > Per your suggestion I tried using openvpn with the edited file and > as > expected it fails to connect. So the appears to be > required to initialize the connection. Now the question is how do I > add > them to the configuration? I manually added the contents of that > element to a file ~/.certs/nm-openvpn/Ashburn-edited-extra-certs.pem > along with the other elements, but that appears to be insufficient. > > I assume that I need to add the proper entry to > /etc/NetworkManager/system-connections/Private Tunnel - Ashburn, but > my > question is what form does that entry take? In the [vpn] section I > see > various entries referencing the certificates, specifically: > > cert=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-cert.pem > key=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-key.pem > ca=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-ca.pem > ta=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-tls-auth.pem > > So I assume I need a similar line for this one, but should it be > "extra-certs=" or "ec=" there? I guess I could try both, but I > would > prefer to get it right the first time. Or is it perhaps something > else > entirely? Hi, Editing the connection of NetworkManager with a new option that is not supported by nm-openvpn plugin does not make it work. nm-openvpn plugin does not support this option (yet). See https://git.gnome.org/browse/network-manager-openvpn/commit/?id=master especially https://git.gnome.org/browse/network-manager-openvpn/tree/src/nm-openvpn-service.c?id=dd8868f8a020988a47b7d4d4b502a98531fdeee0 which constructs the command line arguments for openvpn binary. The proper solution is to add support for this option. Patches welcome. Possible work arounds are: - try to find a client configuration that does not require this option. Maybe reconfigure the server is feasable. - use openvpn directly, without NetworkManager - replace the openvpn binary with a wrapper shell script, that hacks this option. Something like (totally untested!) #!/bin/bash EXTRA_ARGS= if [[ echo "$@" | grep -q '--remote MY.REMOTE.THAT.I.RECOGNIZE' ]]; then EXTRA_ARGS="--extra-certs /path/to/extra/certs" fi exec /path/to/real/openvpn "$@" $EXTRA_ARGS best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 1.4.4 and hotspot problem
On Thu, 2018-02-22 at 08:37 +0100, Belisko Marek wrote: > Hi Dan, > > On Wed, Feb 21, 2018 at 11:45 PM, Dan Williams > wrote: > > On Wed, 2018-02-21 at 22:46 +0100, Belisko Marek wrote: > > > Hi Dan, > > > > > > On Tue, Feb 20, 2018 at 11:53 PM, Dan Williams > > > wrote: > > > > On Tue, 2018-02-20 at 22:47 +0100, Belisko Marek wrote: > > > > > Hi Dan, > > > > > > > > > > On Tue, Feb 20, 2018 at 10:11 PM, Dan Williams > > > > om> > > > > > wrote: > > > > > > On Tue, 2018-02-20 at 21:00 +0100, Belisko Marek wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm trying to configure hotspot by using this command: > > > > > > > nmcli dev wifi hotspot ifname wlan0 ssid test password > > > > > > > "test1234" > > > > > > > > > > > > > > on orangepi which is using realtek wifi (out of tree > > > > > > > driver). > > > > > > > When > > > > > > > want to setup simple hotspot it looks like there are soe > > > > > > > mtroubles > > > > > > > with iptbles + dnsmasq. Any ideas what can cause this > > > > > > > issue? > > > > > > > Thanks > > > > > > > > > > > > Your analysis looks correct. What happens when you run the > > > > > > iptables > > > > > > command manually? > > > > > > > > > > > > /usr/sbin/iptables --table nat \ > > > > > >--insert POSTROUTING --source 10.42.0.0/255.255.255.0 \ > > > > > >! --destination 10.42.0.0/255.255.255.0 --jump > > > > > > MASQUERADE > > > > > > > > > > > > does /usr/sbin/iptables exist? > > > > > > > > > > > > does your kernel have the ipt_MASQUERADE, iptable_nat, > > > > > > nf_conntrack, > > > > > > iptable_mangle, and other modules like that available? > > > > > > > > > > I've nmcli c up Hotspot > > > > > > > > What does your 'iptables-save' output look like on this > > > > machine? > > > > > > It looks like this: > > > > > > iptables-save > > > # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018 > > > *filter > > > :INPUT ACCEPT [61:11807] > > > :FORWARD ACCEPT [0:0] > > > :OUTPUT ACCEPT [42:7785] > > > COMMIT > > > # Completed on Wed Feb 21 21:42:54 2018 > > > # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018 > > > *nat > > > :PREROUTING ACCEPT [0:0] > > > :INPUT ACCEPT [0:0] > > > :OUTPUT ACCEPT [0:0] > > > :POSTROUTING ACCEPT [0:0] > > > COMMIT > > > # Completed on Wed Feb 21 21:42:54 2018 > > > root@orange-pi-pc-plus:~# lsmod > > > Module Size Used by > > > ipt_REJECT 16384 -2 > > > ipt_MASQUERADE 16384 -2 > > > xt_tcpudp 16384 -2 > > > iptable_filter 16384 -2 > > > iptable_nat16384 -2 > > > ip_tables 20480 -2 > > > x_tables 20480 -2 > > > mali 208896 -2 > > > 8189fs 1224704 -2 > > > > > > > > > I've added more kernel modules (according : > > > https://wiki.gentoo.org/wiki/Iptables#Kernel) and output look > > > much > > > better (unfortunately there are still some problems): > > > > Ok, so the issue with iptables is solved (at least I think?), but > > now > > it's dnsmasq. There was a problem in Debian a while back, where > > just > > installing dnsmasq set up a configuration that did this, which > > meant > > that NM could not run its own interface-specific dnsmasq. > > Issue with iptables remains (I think last one): > Feb 21 21:39:28 orange-pi-pc-plus user.info NetworkManager[765]: > [1519249168.1555] Executing: /usr/sbin/iptables --table > filter > --insert FORWARD --destination 10.42.0.0/255.255.255.0 --out- > interface > wlan0 --match state --state ESTA > BLISHED,RELATED --jump ACCEPT > Feb 21 21:39:28 orange-pi-pc-plus user.warn NetworkManager[765]: > [1519249168.1786] ** Command returned exit status 1. Ok, for the "--state" extension you need the conntrack kernel module. > > This line: > > > > Feb 21 21:39:28 orange-pi-pc-plus daemon.info NetworkManager[765]: > > dnsmasq: failed to create listening socket for 10.42.0.1: Address > > already in use > > Feb 21 21:39:28 orange-pi-pc-plus user.warn NetworkManager[765]: > >[1519249168.4498] dnsmasq-manager: dnsmasq exited with > > error: > > Network access problem (address in use, permissions) (2) > > > > is likely the current problem. Do you have an existing dnsmasq > > process > > running and what is the contents of /etc/dnsmasq.conf? If it has > > the > > "bind-interfaces" option enabled, that could be causing this issue. > > AFAIK dnsmasq is not running due to this: > Feb 20 21:40:11 orange-pi-pc-plus systemd[1]: Starting DNS forwarder Ok, lets make get the iptables stuff figured out, and then see about dnsmasq. But what do you get for "ps ax | grep dnsmasq" when you see the NM failure? Dan > > > and DHCP server... > > > Feb 20 21:40:11 orange-pi-pc-plus dnsmasq[290]: dnsmasq: syntax > > > check > > > OK. > > > Feb 20 21:40:11 orange-pi-pc-plus dnsmasq[293]: dnsmasq: > > > directory > > > /etc/resolv.conf for resolv-file is missing, cannot poll > > > Feb 20 21:40:11 orange-pi-pc-plus systemd[1]: > > > [
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
Thomas Haller wrote: On Wed, 2018-02-21 at 12:03 -0500, David H. Durgee wrote: Thomas Haller wrote: I will consider debug logging after you have a chance to inspect the connection show and let me know if it looks sane or is missing a crucial element. Hi, the settings don't look wrong, but whether the settings are correct depends very much on your server configuratoin. Enable debug logging and see why the connection failed. Since NM does not support the argument, you should investigate whether that argument is required in your setup. For example, (as you said, plain openvpn works) by running openvpn with the ovpn without the option. best, Thomas Per your suggestion I tried using openvpn with the edited file and as expected it fails to connect. So the appears to be required to initialize the connection. Now the question is how do I add them to the configuration? I manually added the contents of that element to a file ~/.certs/nm-openvpn/Ashburn-edited-extra-certs.pem along with the other elements, but that appears to be insufficient. I assume that I need to add the proper entry to /etc/NetworkManager/system-connections/Private Tunnel - Ashburn, but my question is what form does that entry take? In the [vpn] section I see various entries referencing the certificates, specifically: cert=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-cert.pem key=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-key.pem ca=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-ca.pem ta=/home/dhdurgee/.cert/nm-openvpn/Ashburn-edited-tls-auth.pem So I assume I need a similar line for this one, but should it be "extra-certs=" or "ec=" there? I guess I could try both, but I would prefer to get it right the first time. Or is it perhaps something else entirely? Dave ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem importing OpenVPN profile in Linux Mint 18.3 x64 cinnamon
On Wed, 2018-02-21 at 12:03 -0500, David H. Durgee wrote: > Thomas Haller wrote: > > I will consider debug logging after you have a chance to inspect the > connection show and let me know if it looks sane or is missing a > crucial > element. Hi, the settings don't look wrong, but whether the settings are correct depends very much on your server configuratoin. Enable debug logging and see why the connection failed. Since NM does not support the argument, you should investigate whether that argument is required in your setup. For example, (as you said, plain openvpn works) by running openvpn with the ovpn without the option. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list