> On 10 Nov 2016, at 15:41, Ken Teh <t...@anl.gov> 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 <t...@anl.gov> 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> >>
