SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0004199: Multiple red IPs appear to not always be correctly assisgned resulting in a variety of issues - MantisBT
MantisBT - Endian Firewall
View Issue Details
0004199Endian FirewallNetwork related (VPN, uplinks)public2011-10-25 02:272011-11-01 17:15
ron_e_e 
 
normalmajorsometimes
newopen 
2.4.1 
 
0004199: Multiple red IPs appear to not always be correctly assisgned resulting in a variety of issues
There are conditions where Endian will fail to apply IP aliases fully somehow. This is manifested by those IPs not being reachable across the network, both for system access and port forwarding rules. This has been discussed at various times, I have personally reproduced this on both ver 2.4.1 and 2.3.

Here is a post from another user that has reproduced the issue with additional details:

http://old.nabble.com/Re%3A-Port-forwarding-on-RED-multi-IP-p32703896.html [^]

I believe this can be reproduced especially when an alias is configured on a red IP at initial install.

Note that it is possible to reach these IPs from the efw console or ssh session. Such as telnetting to ports that are forwarded etc, however these aliased IPs are unreachable across the network.

This has been reproduced both with virtualization under KVM and when Endian is installed directly on bare metal.
No tags attached.
Issue History
2011-10-25 02:27ron_e_eNew Issue
2011-11-01 17:15ron_e_eNote Added: 0007525

Notes
(0007525)
ron_e_e   
2011-11-01 17:15   
This apparently can be reproduced erratically. Under some circumstances adding additional red IPs results in the additional IP(s) not responding to rules or ping when allowed.

Some report that setting the unresponsive IP as primary and then reverting it to a secondary IP resolves the problem. Has been reported on version 2.3.0 and 2.4.1 in virtual and bare metal installations.