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

0001151: portforwarding: unable to access GREEN from GREEN via RED portforward rule - MantisBT Endian Bugtracker
Endian Issue Tracker

Please see now our new Bugtracker system: JIRA

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001151Endian FirewallFirewall (iptables)public2008-07-23 10:102013-02-22 13:58
Assigned Topeter-endian 
PlatformOSOS Version
Product Version2.5 
Target VersionfutureFixed in Version 
Summary0001151: portforwarding: unable to access GREEN from GREEN via RED portforward rule
Descriptionas per summary, a device on the GREEN network is unable to access another device on the GREEN network, by using the RED interface and portforwarding.

we configure mobile devices to access resources on the GREEN network, by using the RED device and port forwarding. they can operate onsite and offsite (without vpn) this way.
TagsNo tags attached.
Attached Files

- Relationships
has duplicate 0001400closedpeter-endian Firewall port forward rules not working 
has duplicate 0002662closed Can not Access from Green to Green via Red 
related to 0002191closedpeter-endian SNAT incoming traffic in port forwarding. 

-  Notes
peter-endian (administrator)
2008-08-08 11:11

packets will return directly from the target to the source, whenever they are in the same subnet

portfw rule should somehow automatically create a
non-stateful GREEN -> GREEN allow rule for that specific port/target and target-subnet as source.
little problem is that PORTFWACCESS stateful.

maybe PORTFWACCESS should become non-statefule at all (?)
peter-endian (administrator)
2008-10-27 19:49

Workaround is to configure hosts with their public domain in Network > Hosts and make them point to internal ip addresses, which makes the portforward work for machines in green

another workaround:
edit /etc/rc.d/rc.firewall
remove -m state --state NEW

resolution of this issue is not scheduled right now, please use the workarounds instead
yokomaka (reporter)
2008-11-06 13:23

Thanks for pointing out the workarounds.

1) Works fine for us, however it does not really solve our problem. We have one external IP and forward multiple ports to different internal machines. I don't know how to do this with the given solution as it would only allow me to point a hostname to one internal IP, independent of the port.

2) Does not seem to work for me with 2.2RC3. I changed the line
"iptables -A FORWARD -m state --state NEW -j PORTFWACCESS"
to "iptables -A FORWARD -j PORTFWACCESS"
and rebooted the firewall.
Is there anything else that I missed to get this working?
peter-endian (administrator)
2010-02-09 14:23

well. the attempt to solve this issue with a non-stateful rule is definitively not solving the problem, since the target will answer with its own ip-address and will not translated back to the target ip address, because the answer does not pass the DNAT'ing device.

So the 2 possibilities to solve this is:

1) Configure your internal DNS (dns proxy) in order that access to the host which points to your external portforwarded ip will point to the green ip. So traffic will go directly to the target and do not pass the DNAT rule.

2) Create a matching SNAT rule for your DNAT rules in order that traffic coming from the same subnet as the DNAT target and going to the DNAT target, will be SNAT'ed to the firewall's ip address of the target subnet.
So answers will be forced to go back passing the firewall. However you will see connections coming always from your firewall instead of your internal ip.

example for 2:

DNAT rule:
portforward from ->
firewall has ip:

SNAT rule:
dest-port: 25
NAT to
icedburn (reporter)
2011-04-15 10:36

May i ask. Does this issue has any update. My client has the same problem and we are trying to solve their problem. We have try what peter gave, but still the problem arise.
Hope to hear from you guys.. thanks.
Dj_GL (reporter)
2011-07-12 18:53
edited on: 2011-07-12 18:54

Instead of adding rules for every private IP I've added a single SNAT rule
NAT to

That seems to work for me but does it maybe have some unwanted side-effects?

- Issue History
Date Modified Username Field Change
2008-07-23 10:10 jasonwalls New Issue
2008-07-23 10:10 jasonwalls Status new => assigned
2008-07-23 10:10 jasonwalls Assigned To => peter-endian
2008-08-08 11:11 peter-endian Note Added: 0001512
2008-08-08 11:11 peter-endian Status assigned => confirmed
2008-08-08 11:11 peter-endian Target Version => 2.2
2008-09-10 15:41 chris-endian Target Version 2.2 => 2.3
2008-09-10 15:53 chris-endian Target Version 2.3 => future
2008-10-27 19:49 peter-endian Note Added: 0001757
2008-10-27 19:50 peter-endian Relationship added has duplicate 0001400
2008-11-06 13:23 yokomaka Note Added: 0001778
2008-12-11 19:53 peter-endian Severity major => crash
2009-11-25 11:38 peter-endian Relationship added related to 0002191
2010-02-09 14:23 peter-endian Note Added: 0003755
2010-02-09 14:24 peter-endian Relationship added has duplicate 0002662
2011-03-18 15:13 ra-endian Status confirmed => new
2011-03-18 15:13 ra-endian Assigned To peter-endian => lorenzo-endian
2011-03-18 15:13 ra-endian Status new => confirmed
2011-03-21 12:13 lorenzo-endian Assigned To lorenzo-endian => peter-endian
2011-04-15 10:36 icedburn Note Added: 0006122
2011-07-12 18:53 Dj_GL Note Added: 0006966
2011-07-12 18:54 Dj_GL Note Edited: 0006966
2013-02-22 13:57 ardit-endian Product Version 2.2-rc1 => 2.5

Copyright © 2005-2008 Endian, SRL. All rights reserved.

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker