SCIENTIFIC-LINUX-USERS Archives

March 2018

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Andrew C Aitchison <[log in to unmask]>
Reply To:
Andrew C Aitchison <[log in to unmask]>
Date:
Wed, 21 Mar 2018 20:43:10 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
On Wed, 21 Mar 2018, Sean A wrote:

> Hello,
>
> We have just encountered a strange scenario with firewalld and ipv6.  We are running SL 7.4, with kernel 3.10.0-693.21.1.el7.x86_64 and firewalld-0.4.4.4-6, but this situation has existed for nearly a year, if not longer.
> For a long time, I have thought our infrastructure team just didn't have 
> IPv6 Routing or Boundary Firewall rules setup right because I have not 
> been able to ping6 sites like google.com.... (site info scrubbed) -

> Its a strange thing, but the first few successful pings after stopping 
> firewalld take a long time.  When I start firewalld, the pings will 
> continue to succeed for a period of time, then the network will become 
> unreachable again at some point later.
>
> From a ruleset perspective, we do not filter outbound packets.
> We do use the drop zone as default, but both my system and my colleague's have
> different input filtering.  e.g. My system is a desktop, the system my 
> colleague was working on is a dns server.

Could the problem be that the firewall is blocking some sort of routing reply
(somethng like arp or dns, but not necessarily either of those) so that 
the system doesn't know where to send the outgoing packets.

When the firewall is turned on again I guess that packets continue to 
be sent until the system realises that they aren't being 
acknowledged...

-- 
Andrew C. Aitchison					Cambridge, UK
 			[log in to unmask]

ATOM RSS1 RSS2