Confirm.
The rules are very restrictive and cause this error message.
This means the issue is not related to any functional issue of Shorewall and therefore this can be considered as solved.
Gesendet: Dienstag, 05. April 2016 um 16:14 Uhr
Von: "Tom Eastep" <teas...@shorewall.net>
An: shorewall-users@lists.sourceforge.net
Betreff: Re: [Shorewall-users] IPv6 issues (Was: Configuration - appropriate configuration with 2 default gateways)
Von: "Tom Eastep" <teas...@shorewall.net>
An: shorewall-users@lists.sourceforge.net
Betreff: Re: [Shorewall-users] IPv6 issues (Was: Configuration - appropriate configuration with 2 default gateways)
On 04/05/2016 03:39 AM, Simon Hobson wrote:
>
> On 5 Apr 2016, at 06:42, Thomas Schneider <c.mo...@web.de> wrote:
>
>> This is the output:
>> root@vm103-db:~# ip -f inet6 addr show
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
>> inet6 ::1/128 scope host
>> valid_lft forever preferred_lft forever
>> 9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>> inet6 fe80::3065:65ff:fe39:3035/64 scope link
>> valid_lft forever preferred_lft forever
>> root@vm103-db:~# ip -f inet6 route show
>> fe80::/64 dev eth0 proto kernel metric 256
>> root@vm103-db:~# ip -f inet6 neigh show
>> root@vm103-db:~#
>
> Indeed it does.
> I think you may be seeing a known bug (that's 3 1/2 years old) :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684407
>
> It's off topic for this list, I suggest you go and enquire of the maintainers since apt is definitely not acting correctly here.
>
> There is a message there that apt will try the first address, and if a connection fails then it'll try the other addresses in turn. This would explain why it downloads some packages (connects OK via IPv4) but then fails - if a connection fails over IPv4 then it'll cycle round and try an IPv6 address - and then it reports a misleading error* when that fails. It should not, IMO, be trying IPv6 addresses if the system isn't configured with routable addresses.
>
> * The error should really be "couldn't connect to any address" rather than "couldn't connect to ${last_address_tried}".
I suspect, Thomas, that if you do as I suggested a week or more ago and
add logging to your dmz->net and loc->net policies, you might find that
your restrictive ruleset is causing the IPv4 connection failures.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
> On 5 Apr 2016, at 06:42, Thomas Schneider <c.mo...@web.de> wrote:
>
>> This is the output:
>> root@vm103-db:~# ip -f inet6 addr show
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
>> inet6 ::1/128 scope host
>> valid_lft forever preferred_lft forever
>> 9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>> inet6 fe80::3065:65ff:fe39:3035/64 scope link
>> valid_lft forever preferred_lft forever
>> root@vm103-db:~# ip -f inet6 route show
>> fe80::/64 dev eth0 proto kernel metric 256
>> root@vm103-db:~# ip -f inet6 neigh show
>> root@vm103-db:~#
>
> Indeed it does.
> I think you may be seeing a known bug (that's 3 1/2 years old) :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684407
>
> It's off topic for this list, I suggest you go and enquire of the maintainers since apt is definitely not acting correctly here.
>
> There is a message there that apt will try the first address, and if a connection fails then it'll try the other addresses in turn. This would explain why it downloads some packages (connects OK via IPv4) but then fails - if a connection fails over IPv4 then it'll cycle round and try an IPv6 address - and then it reports a misleading error* when that fails. It should not, IMO, be trying IPv6 addresses if the system isn't configured with routable addresses.
>
> * The error should really be "couldn't connect to any address" rather than "couldn't connect to ${last_address_tried}".
I suspect, Thomas, that if you do as I suggested a week or more ago and
add logging to your dmz->net and loc->net policies, you might find that
your restrictive ruleset is causing the IPv4 connection failures.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
