> On 10 Nov 2016, at 15:41, Ken Teh <[log in to unmask]> 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 <[log in to unmask]> 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.
>>> 
>>> <iptables.fails><iptables.works>
>>