Re: firewalld help

[Ken Teh]

Ok.  I see the problem now.  Default routes have always been a bit of a mystery 
to me.  Based on your reply, I manually deleted the default route for enp3s0 to 
confirm it works.  Then, I edited the connection with nmcli to remove the 
default permanently across reboots.

For everyone's benefit, the property setting is ipv4.never-default in nmcli.



On 11/10/2016 09:02 AM, Stephan Wiesand wrote:



On 10 Nov 2016, at 15:41, Ken Teh  wrote:

Default routes on the failing system.


[root@saudade ~]# ip --details route
unicast default via 192.168.203.1 dev enp3s0  proto static  scope global  
metric 100
unicast default via 146.139.198.1 dev enp4s0  proto static  scope global  
metric 101
unicast 146.139.198.0/23 dev enp4s0  proto kernel  scope link  src 
146.139.198.23  metric 100
unicast 192.168.203.0/24 dev enp3s0  proto kernel  scope link  src 
192.168.203.39  metric 100


This suggests tat saudade will send the response packages through enp3s0, unless the 
request originates from "the same subnet" (146.139.198.0/23). Is that expected 
to work?

You could check this with tcpdump.


On 11/10/2016 08:27 AM, Stephan Wiesand wrote:



On 10 Nov 2016, at 15:09, Ken Teh  wrote:

I'm trying to isolate a network problem and I need some debugging help.  
Frustrating when I am not fluent in the new sys admin tools.

Symptom is as follows:  I have a machine running Fedora 24 with its firewall 
zone set to work.  I cannot ping the machine except from the same subnet.  I 
don't have this problem with a second machine running the same OS/rev with the 
same firewall setup.  I'm not sure where to look.

I've dumped out both machines iptables.  See attachment.  I did a diff -y and they look 
almost identical.  The machine that does not work has 2 nics, one which is connected to a 
192.168 network.  It has additional rules in the various chains but they are all 
"from anywhere to anywhere".  I'm assuming the additional rules come from the 
second interface.

I've put a query to my networking folks to see if the problem is further 
upstream.  But I thought I'd ask if I have missed something obvious.


What's the default route on the "failing" system?


I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.

Re: firewalld help

[Stephan Wiesand]

> On 10 Nov 2016, at 15:41, Ken Teh  wrote:
> 
> Default routes on the failing system.
> 
>> [root@saudade ~]# ip --details route
>> unicast default via 192.168.203.1 dev enp3s0  proto static  scope global  
>> metric 100
>> unicast default via 146.139.198.1 dev enp4s0  proto static  scope global  
>> metric 101
>> unicast 146.139.198.0/23 dev enp4s0  proto kernel  scope link  src 
>> 146.139.198.23  metric 100
>> unicast 192.168.203.0/24 dev enp3s0  proto kernel  scope link  src 
>> 192.168.203.39  metric 100

This suggests tat saudade will send the response packages through enp3s0, 
unless the request originates from "the same subnet" (146.139.198.0/23). Is 
that expected to work?

You could check this with tcpdump.

> On 11/10/2016 08:27 AM, Stephan Wiesand wrote:
>> 
>>> On 10 Nov 2016, at 15:09, Ken Teh  wrote:
>>> 
>>> I'm trying to isolate a network problem and I need some debugging help.  
>>> Frustrating when I am not fluent in the new sys admin tools.
>>> 
>>> Symptom is as follows:  I have a machine running Fedora 24 with its 
>>> firewall zone set to work.  I cannot ping the machine except from the same 
>>> subnet.  I don't have this problem with a second machine running the same 
>>> OS/rev with the same firewall setup.  I'm not sure where to look.
>>> 
>>> I've dumped out both machines iptables.  See attachment.  I did a diff -y 
>>> and they look almost identical.  The machine that does not work has 2 nics, 
>>> one which is connected to a 192.168 network.  It has additional rules in 
>>> the various chains but they are all "from anywhere to anywhere".  I'm 
>>> assuming the additional rules come from the second interface.
>>> 
>>> I've put a query to my networking folks to see if the problem is further 
>>> upstream.  But I thought I'd ask if I have missed something obvious.
>> 
>> What's the default route on the "failing" system?
>> 
>>> I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.
>>> 
>>> 
>> 

Re: firewalld help

[Ken Teh]

Default routes on the failing system.


[root@saudade ~]# ip --details route
unicast default via 192.168.203.1 dev enp3s0  proto static  scope global  
metric 100
unicast default via 146.139.198.1 dev enp4s0  proto static  scope global  
metric 101
unicast 146.139.198.0/23 dev enp4s0  proto kernel  scope link  src 
146.139.198.23  metric 100
unicast 192.168.203.0/24 dev enp3s0  proto kernel  scope link  src 
192.168.203.39  metric 100



On 11/10/2016 08:27 AM, Stephan Wiesand wrote:



On 10 Nov 2016, at 15:09, Ken Teh  wrote:

I'm trying to isolate a network problem and I need some debugging help.  
Frustrating when I am not fluent in the new sys admin tools.

Symptom is as follows:  I have a machine running Fedora 24 with its firewall 
zone set to work.  I cannot ping the machine except from the same subnet.  I 
don't have this problem with a second machine running the same OS/rev with the 
same firewall setup.  I'm not sure where to look.

I've dumped out both machines iptables.  See attachment.  I did a diff -y and they look 
almost identical.  The machine that does not work has 2 nics, one which is connected to a 
192.168 network.  It has additional rules in the various chains but they are all 
"from anywhere to anywhere".  I'm assuming the additional rules come from the 
second interface.

I've put a query to my networking folks to see if the problem is further 
upstream.  But I thought I'd ask if I have missed something obvious.


What's the default route on the "failing" system?


I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.

Re: firewalld help

[Sebastian Luna Valero]

Hi Ken,

I have been recently learning about firewalld. Please run the commands
below on your hosts to see whether they look the same or not.

I hope it helps.

Best regards,
Sebastian

* General:

firewall-cmd --state

# Sometimes you need to reload the firewall to get the configuration
actually applied
firewall-cmd --reload

* Services:

firewall-cmd --get-services

firewall-cmd --permanent --get-services

firewall-cmd --info-service=smtp

​* Zones:

firewall-cmd --get-zones

firewall-cmd --get-default-zone

firewall-cmd --get-active-zones

firewall-cmd --get-zone-of-interface=em1

firewall-cmd --zone=work --list-interfaces

firewall-cmd --zone=work --list-all

firewall-cmd --zone=work --add-interface=em1

firewall-cmd --set-default-zone=internal

firewall-cmd --set-default-zone=public

firewall-cmd --get-default-zone

firewall-cmd --zone=work --list-rich-rules

firewall-cmd --permanent --zone=work --list-rich-rules

* Adding Ports

firewall-cmd --permanent --zone=work --add-port=80/tcp

# remember to:
firewall-cmd --reload

# check status:
firewall-cmd --zone=work --list-ports

* Removing Ports

firewall-cmd --zone=work --remove-port=80/tcp

* Adding Services

firewall-cmd --zone=work --add-service=ftp

* Removing Services

firewall-cmd --zone=work --remove-service=ftp

* Configure IP Address Masquerading

firewall-cmd --zone=external --query-masquerade

firewall-cmd --permanent --zone=external --add-masquerade

firewall-cmd --zone=external --remove-masquerade

Re: firewalld help

[Stephan Wiesand]

> On 10 Nov 2016, at 15:09, Ken Teh  wrote:
> 
> I'm trying to isolate a network problem and I need some debugging help.  
> Frustrating when I am not fluent in the new sys admin tools.
> 
> Symptom is as follows:  I have a machine running Fedora 24 with its firewall 
> zone set to work.  I cannot ping the machine except from the same subnet.  I 
> don't have this problem with a second machine running the same OS/rev with 
> the same firewall setup.  I'm not sure where to look.
> 
> I've dumped out both machines iptables.  See attachment.  I did a diff -y and 
> they look almost identical.  The machine that does not work has 2 nics, one 
> which is connected to a 192.168 network.  It has additional rules in the 
> various chains but they are all "from anywhere to anywhere".  I'm assuming 
> the additional rules come from the second interface.
> 
> I've put a query to my networking folks to see if the problem is further 
> upstream.  But I thought I'd ask if I have missed something obvious.

What's the default route on the "failing" system?

> I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.
> 
> 

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany

firewalld help

[Ken Teh]

I'm trying to isolate a network problem and I need some debugging help.  
Frustrating when I am not fluent in the new sys admin tools.

Symptom is as follows:  I have a machine running Fedora 24 with its firewall 
zone set to work.  I cannot ping the machine except from the same subnet.  I 
don't have this problem with a second machine running the same OS/rev with the 
same firewall setup.  I'm not sure where to look.

I've dumped out both machines iptables.  See attachment.  I did a diff -y and they look 
almost identical.  The machine that does not work has 2 nics, one which is connected to a 
192.168 network.  It has additional rules in the various chains but they are all 
"from anywhere to anywhere".  I'm assuming the additional rules come from the 
second interface.

I've put a query to my networking folks to see if the problem is further 
upstream.  But I thought I'd ask if I have missed something obvious.

I know it's not SL7 but they use the same tools:  nmcli and firewall-cmd.

Chain INPUT (policy ACCEPT)
target prot opt source   destination 
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ACCEPT all  --  anywhere anywhere
INPUT_direct  all  --  anywhere anywhere
INPUT_ZONES_SOURCE  all  --  anywhere anywhere
INPUT_ZONES  all  --  anywhere anywhere
DROP   all  --  anywhere anywhere ctstate INVALID
REJECT all  --  anywhere anywhere reject-with 
icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target prot opt source   destination 
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ACCEPT all  --  anywhere anywhere
FORWARD_direct  all  --  anywhere anywhere
FORWARD_IN_ZONES_SOURCE  all  --  anywhere anywhere
FORWARD_IN_ZONES  all  --  anywhere anywhere
FORWARD_OUT_ZONES_SOURCE  all  --  anywhere anywhere
FORWARD_OUT_ZONES  all  --  anywhere anywhere
DROP   all  --  anywhere anywhere ctstate INVALID
REJECT all  --  anywhere anywhere reject-with 
icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination 
OUTPUT_direct  all  --  anywhere anywhere

Chain FORWARD_IN_ZONES (1 references)
target prot opt source   destination 
FWDI_work  all  --  anywhere anywhere[goto] 
FWDI_work  all  --  anywhere anywhere[goto] 
FWDI_work  all  --  anywhere anywhere[goto] 

Chain FORWARD_IN_ZONES_SOURCE (1 references)
target prot opt source   destination 

Chain FORWARD_OUT_ZONES (1 references)
target prot opt source   destination 
FWDO_work  all  --  anywhere anywhere[goto] 
FWDO_work  all  --  anywhere anywhere[goto] 
FWDO_work  all  --  anywhere anywhere[goto] 

Chain FORWARD_OUT_ZONES_SOURCE (1 references)
target prot opt source   destination 

Chain FORWARD_direct (1 references)
target prot opt source   destination 

Chain FWDI_work (3 references)
target prot opt source   destination 
FWDI_work_log  all  --  anywhere anywhere
FWDI_work_deny  all  --  anywhere anywhere
FWDI_work_allow  all  --  anywhere anywhere
ACCEPT icmp --  anywhere anywhere

Chain FWDI_work_allow (1 references)
target prot opt source   destination 

Chain FWDI_work_deny (1 references)
target prot opt source   destination 

Chain FWDI_work_log (1 references)
target prot opt source   destination 

Chain FWDO_work (3 references)
target prot opt source   destination 
FWDO_work_log  all  --  anywhere anywhere
FWDO_work_deny  all  --  anywhere anywhere
FWDO_work_allow  all  --  anywhere anywhere

Chain FWDO_work_allow (1 references)
target prot opt source   destination 

Chain FWDO_work_deny (1 references)
target prot opt source   destination 

Chain FWDO_work_log (1 references)
target prot opt source   destination 

Chain INPUT_ZONES (1 references)
target prot opt source   destination 
IN_workall  --  anywhere anywhere[goto] 
IN_workall  --  anywhere anywhere[goto] 
IN_workall  --  anywhere