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

Please see now our new Bugtracker system: JIRA

Anonymous | Login

2021-05-10 05:55 UTC

Relationships

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

Relationships

Notes
(0001512) 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 (?)
(0001757) 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 search for PORTFWACCESS remove -m state --state NEW resolution of this issue is not scheduled right now, please use the workarounds instead
(0001778) 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?
(0003755) 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 80.80.80.80:25 -> 192.168.0.10:25 firewall has ip: 192.168.0.1 SNAT rule: source: 192.168.0.0/24 destination: 192.168.0.10 dest-port: 25 NAT to 192.168.0.1
(0006122) icedburn (reporter) 2011-04-15 10:36	Hai, 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.
(0006966) 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 source: 192.168.0.0/24 destination: 192.168.0.0/24 NAT to 192.168.0.1 That seems to work for me but does it maybe have some unwanted side-effects?

Notes

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

Issue History

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

---

Copyright © 2000 - 2012 MantisBT Group