7:31 a.m.
I'm trying to setup kdeconnect between my Android phone
and my Fedora-23/KDE laptop.
I see that I have to open ports 1714-1764, TCP and UDP.
I'm running firewalld on the laptop.
I give the command "firewall-config" and authenticate.
Clicking on zone "internal" I see that kde-connect is ticked.
And when I go to Ports I see that ports 1714-1764 are listed, TCP and UDP.
And all this remains set if I reboot.
But I am not able to establish a connection under kdeconnect.
Neither device sees the other.
Also "sudo nmap -sT -O localhost" on the laptop does not show
these ports to be open.
If I run "sudo systemctl stop firewalld"
then I am able to establish the connection.
It seems that these firewalld commands
to not open the specified ports, as I would expect.
Could some firewalld expert please elucidate.
Incidentall, I tried the alternative firewall service some time ago,
and that seemed to open the ports OK.
--
Timothy Murphy
gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin
8 a.m.
On Tue, Feb 23, 2016 at 7:31 AM, Timothy Murphy <gayleard(a)eircom.net> wrote:
I see that I have to open ports 1714-1764, TCP and UDP.
I'm running firewalld on the laptop.
I give the command "firewall-config" and authenticate.
Clicking on zone "internal" I see that kde-connect is ticked.
And when I go to Ports I see that ports 1714-1764 are listed, TCP and UDP.
And all this remains set if I reboot.
Let's try the simple stuff first... Is your default zone for your network
connection also "internal"?
Thanks,
Richard
8:06 a.m.
try to use the public zone, which is the zone normally activ...
suomi
On 02/23/2016 02:31 PM, Timothy Murphy wrote:
I'm trying to setup kdeconnect between my Android phone
and my Fedora-23/KDE laptop.
I see that I have to open ports 1714-1764, TCP and UDP.
I'm running firewalld on the laptop.
I give the command "firewall-config" and authenticate.
Clicking on zone "internal" I see that kde-connect is ticked.
And when I go to Ports I see that ports 1714-1764 are listed, TCP and UDP.
And all this remains set if I reboot.
But I am not able to establish a connection under kdeconnect.
Neither device sees the other.
Also "sudo nmap -sT -O localhost" on the laptop does not show
these ports to be open.
If I run "sudo systemctl stop firewalld"
then I am able to establish the connection.
It seems that these firewalld commands
to not open the specified ports, as I would expect.
Could some firewalld expert please elucidate.
Incidentall, I tried the alternative firewall service some time ago,
and that seemed to open the ports OK.
9:23 a.m.
On 23 February 2016 at 14:06, fedora <fedora(a)ayni.com> wrote:
try to use the public zone, which is the zone normally activ...
Not on Fedora which uses FedoraWorkstation as the default zone.
OP you may want to include in your response for troubleshooting the output
of firewall-cmd --list-all-zones
Nothing is actually forbidden against localhost so if it is a connection on
localhost it should work ...
9:31 a.m.
On 2/23/2016 9:00 AM, Richard Shaw wrote:
Let's try the simple stuff first... Is your default zone for your
network connection also "internal"?
That's the first thing I thought of as well. In case you aren't sure
which zone is your active zone, Tim, just look at the bottom right of
the "Firewall Configuration" window. Mine says, "Default Zone: external
Lockdown: disabled Panic Mode: disabled." That means if I want to
adjust the current settings, I need to edit the "external" zone.
If you put your firewall exceptions in a zone other than the active one,
then that might be your problem.
Tom
5:48 a.m.
Richard Shaw wrote:
On Tue, Feb 23, 2016 at 7:31 AM, Timothy Murphy
<gayleard(a)eircom.net>
wrote:
> I see that I have to open ports 1714-1764, TCP and UDP.
> I'm running firewalld on the laptop.
> I give the command "firewall-config" and authenticate.
> Clicking on zone "internal" I see that kde-connect is ticked.
> And when I go to Ports I see that ports 1714-1764 are listed, TCP and
> UDP. And all this remains set if I reboot.
Let's try the simple stuff first... Is your default zone for your
network
connection also "internal"?
Thank you very much.
That was indeed the issue.
After changing the default zone to "internal" everything works fine.
But I don't understand the reasoning behind this.
This use of the term "zone" seems to me misleading and bizarre.
I run shorewall on my home server, and there the "zone"
can be "net", "local", etc.
Any changes made to a particular zone come into effect
on restarting shorewall.
It would not make sense in this context to choose a "default zone".
Incidentally, restarting firewalld does not seem to me to work properly,
as a window comes up asking for authentication.
I don't recall any other service requiring this,
and it would seem to prevent remote restarting.
--
Timothy Murphy
gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin
6:52 a.m.
On Thu, 2016-02-25 at 11:48 +0000, Timothy Murphy wrote:
After changing the default zone to "internal" everything
works fine.
But I don't understand the reasoning behind this.
This use of the term "zone" seems to me misleading and bizarre.
I run shorewall on my home server, and there the "zone"
can be "net", "local", etc.
Security zones can be considered thus:
You have a gateway machine that connects directly to the internet, and
it is the link between the WWW and your LAN. Since it straddles both
sides, it would have an external set of rules and an internal set of
rules. The external rules apply to the traffic between it and the WWW,
the internal rules apply to the traffic between it and your LAN. The
external rules would, usually, be more stringent than the internal ones.
Both rules sets are always in action.
You have another computer that is inside your LAN, you'd set up an
internal rule set for this. Or you could use some other name for it,
it's just a name for a set of rules that makes sense to you. You could
call it LAN.
You have a laptop that sometimes is inside your LAN, sometimes you take
it to public networks. You may have two sets of rules, a *home* set for
where you trust the rest of your network, and an *away* set where you do
not trust anything. Only one set of rules are used at a time, so you
can set one as the default, but change it when needed.
What kind of differences might there be between external and internal
rules? You might all NFS or SMB inside, but block it externally.
Likewise for other services. You may block some things internally, you
might block nothing internally.
--
tim@localhost ~]$ uname -rsvp
Linux 3.19.8-100.fc20.i686 #1 SMP Tue May 12 17:42:35 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
7:26 a.m.
On 25 February 2016 at 11:48, Timothy Murphy <gayleard(a)eircom.net> wrote:
Richard Shaw wrote:
> On Tue, Feb 23, 2016 at 7:31 AM, Timothy Murphy <gayleard(a)eircom.net>
> wrote:
>
>> I see that I have to open ports 1714-1764, TCP and UDP.
>> I'm running firewalld on the laptop.
>> I give the command "firewall-config" and authenticate.
>> Clicking on zone "internal" I see that kde-connect is ticked.
>> And when I go to Ports I see that ports 1714-1764 are listed, TCP and
>> UDP. And all this remains set if I reboot.
> Let's try the simple stuff first... Is your default zone for your network
> connection also "internal"?
Thank you very much.
That was indeed the issue.
After changing the default zone to "internal" everything works fine.
I'm still curious about this ... if you look at the underlying iptables
rules with iptables -vnL you'll see traffic on localhost is ALLOW before
any zone stuff is checked:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
134K 104M ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
5 300 ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
679 201K INPUT_direct all -- * * 0.0.0.0/0
0.0.0.0/0
679 201K INPUT_ZONES_SOURCE all -- * * 0.0.0.0/0
0.0.0.0/0
679 201K INPUT_ZONES all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0
1 40 DROP all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID
498 158K REJECT all -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-prohibited
In fact if you firewall-cmd --list-interfaces you'll see that lo is not
bound to any zone (which is sensible given the policy above... otherwise
it'd be misleading as zone would never be jumped to for it).
But I don't understand the reasoning behind this.
This use of the term "zone" seems to me misleading and bizarre.
I run shorewall on my home server, and there the "zone"
can be "net", "local", etc.
Any changes made to a particular zone come into effect
on restarting shorewall.
It would not make sense in this context to choose a "default zone".
I've always hated the term "zone" in firewalld - it's very
misleading given
how it's used elsewhere and the default zones that you can't remove make it
worse.
I did go into detail on it here though that may help:
https://www.hogarthuk.com/?q=node/9
The short of it is the zone name is a label and most of the zones are not
in use and will rarely if ever be in use in most installs.
You can apply rules to that label (and they will not be persistent unless
--permanent is used, in which case runtime won't be affected, or the
runtime is persisted with --runtime-to-permanent) and that label can be
bound to an interface or to a source network address.
In addition NetworkManager can be configured to apply a zone to a
connection profile so you could have work always use the 'work' and $cafe
use 'public' based on their different connection profiles (based on SSID).
The 'default' zone is just the rules used if no other zones have
configurations that match that interface or source network.
Incidentally, restarting firewalld does not seem to me to work
properly,
as a window comes up asking for authentication.
I don't recall any other service requiring this,
and it would seem to prevent remote restarting.
This is the polkit configuration for it. Again I go into detail on the blog
article but the default configuration is that if not root it requests admin
credentials to reload (or even view some stuff).
Keep in mind the polkit policy for firewall-cmd --reload behaviour is
distinct and separate from a systemd polkit policy limiting systemctl
<action> <unit> to admin users.
In terms of remote restarting polkit will only use a GUI prompt if a
display is detected, otherwise it'll have a text based authentication
interaction.. and again this is only if not root.
7:36 a.m.
On Thu, Feb 25, 2016 at 5:48 AM, Timothy Murphy <gayleard(a)eircom.net> wrote:
Richard Shaw wrote:
> On Tue, Feb 23, 2016 at 7:31 AM, Timothy Murphy <gayleard(a)eircom.net>
> wrote:
>
>> I see that I have to open ports 1714-1764, TCP and UDP.
>> I'm running firewalld on the laptop.
>> I give the command "firewall-config" and authenticate.
>> Clicking on zone "internal" I see that kde-connect is ticked.
>> And when I go to Ports I see that ports 1714-1764 are listed, TCP and
>> UDP. And all this remains set if I reboot.
> Let's try the simple stuff first... Is your default zone for your network
> connection also "internal"?
Thank you very much.
That was indeed the issue.
After changing the default zone to "internal" everything works fine.
But I don't understand the reasoning behind this.
This use of the term "zone" seems to me misleading and bizarre.
I run shorewall on my home server, and there the "zone"
can be "net", "local", etc.
Any changes made to a particular zone come into effect
on restarting shorewall.
It would not make sense in this context to choose a "default zone".
Based on my limited understanding, each network interface can be associated
with a different zone, so in the case of a typical home user, you'll only
ever use one zone so you need to change the rules for the zone your one
network interface is associated with.
Incidentally, restarting firewalld does not seem to me to work
properly,
as a window comes up asking for authentication.
I don't recall any other service requiring this,
and it would seem to prevent remote restarting.
I assume you're doing this from the gui interface as a normal user? In that
case yes, it wants to make sure you are some one in the "wheel" group so
it's a gui equivalent to sudo.
Thanks,
Richard
2995
days inactive
2997
days old
8 comments
6 participants
participants (6)
-
fedora -
James Hogarth -
Richard Shaw -
Tim -
Timothy Murphy -
Tom Rivers