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

0002191: SNAT incoming traffic in port forwarding. - 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
0002191Endian FirewallFirewall (iptables)public2009-09-23 10:112010-09-23 15:26
Assigned Topeter-endian 
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version2.3-rc1 
Target VersionFixed in Version 
Summary0002191: SNAT incoming traffic in port forwarding.
DescriptionThere is no option for SNAT incoming connections in the port forwarding Destination NAT.
Additional InformationIn 2.2 stable, we have it and by enabling that we can access internal servers using the static public IP address (RED IP).
TagsNo tags attached.
Attached Files

- Relationships
related to 0001927confirmed Reports to be checked - collecting ticket 
related to 0001151confirmedpeter-endian portforwarding: unable to access GREEN from GREEN via RED portforward rule 

-  Notes
peter-endian (administrator)
2009-09-23 13:20

well, you do that in the SNAT page
santy2cu (reporter)
2009-09-24 09:32

But I can not do it on GUI. Because if I do SNAT incoming connections in 2.2 stable it will be applyed on the chain POSTPORTFW in POSTROUTING. Here if I do SNAT then it doesn't get applied to POSTPORTFW chain of SNAT.
mogyiman (reporter)
2009-11-24 21:07

Same issue here in version 2.3,
- could You specify in what case the POSTPORTFW chain is used when manipulating the GUI ?
- I have tried to create a NAT rule from zone GREEN to the Main uplink's public IP address telling that it has to translate it again to internal IP:port. Without any luck.
- Inter-zone firewall rules does not allow to make rules in GREEN->RED direction.

However many of us would be delighted to see this working again.
peter-endian (administrator)
2009-11-25 00:18

the chain POSTPORTFW will not be used anymore. Just forgot to remove it. It is replaced by the SOURCENAT chain now.

The POSTPORTFW chain in 2.2 has been used only for SNAT rules of a portfw when the source-nat checkbox has been ticket on.

The new dnat.cgi does not support this checkbox anymore, since for such functionality we have the snat.cgi. You do those things there.
snat.cgi applies the rules to the SOURCENAT chain, which is also in POSTROUTING.

So if you need to do a snat of a portfw, create a snat rule with destination dnat's target ip, port dnat's target-port.


Could you please be more exact on 2nd question? Did you create a SNAT or DNAT rule?


inter-zone is for local zones only. you do GREEN->RED rules within outgoing firewall.
mogyiman (reporter)
2009-11-25 06:24

Thanks for replying.
The setup at our site involves two external uplinks and both uplinks handling 14 addresses. This might be a bit more complex but SNAT rules are working ok when checking server's queries from the outside.
Basically I have a DNAT from an external IP and a SNAT from the server sitting in GREEN to the public IP. SNAT of a PORTFW is working ok. The only problem is to access external IP (which is DNAT-ed) from GREEN zone.

The second question was a DNAT setup (following an advice on loopback LAN setup with iptables) by having GREEN interface as source and public IP as destination.
The advice rule was :
"iptables -t nat -A PREROUTING -i lan -d -p tcp --dport 80 -j DNAT --to-destination"
which is still a DNAT rule applied to the external IP in PREROUTING chain.
This should be ok, because PORTFW chain is also in there.
My translation to endian was:
"iptables -t nat -A PORTFW -i br0 -d -p tcp -m tcp --dport 80 -j DNAT --to-destination"

The outgoing firewall allows everything to go out for now the time this issue is cleared.
peter-endian (administrator)
2009-11-25 11:37

ah ok.. you run into bug 0001151
this however never worked in older versions.
there's a workaround described within 0001151

another possibility is to SNAT the DNAT'ed connection to the green ip of the firewall in order to force the answer to pass through the firewall. You loose however the real source ip.
mogyiman (reporter)
2009-11-26 11:30
edited on: 2009-11-26 13:06

Oh yes, exactly.
I have tried both workarounds, none of them worked.
The "/etc/rc.d/rc.firewall" modification seemed very nice but no luck again.
In that case the DNAT port forward rule is not applied, web query stops at the firewall, the admin page shows up by redirecting port 80 to port 10443 and if the browser window was not closed, it enters without any login screen.
Our WAN side looks like this:

....../---public IP 1-- Main uplink -------eth0| |br0
......|.(13 more IP)...................................| |
GW--.....................................................| |---- IP-A
......|---public IP 2-- Secondary uplink--eth1| |---- IP-B
......\.(13 more IP)

IP-A is making http query to IP-B via IP-B public IP address which is DNAT-ed and SNAT-ed. The query results the admin page.
Sorry for many updates, I had to correct the ascii graphics!
Anyway we will manage the problem with the hostsfile method either setting up on efw or locally set on each client.
By the way does efw public IP has to have a registered FQDN to make the internal name resolution work ?

- Issue History
Date Modified Username Field Change
2009-09-23 10:11 santy2cu New Issue
2009-09-23 10:11 santy2cu Assigned To => peter-endian
2009-09-23 13:20 peter-endian Note Added: 0002987
2009-09-24 09:31 Anonymous Note Added: 0002991
2009-09-24 09:31 Anonymous Status new => feedback
2009-09-24 09:32 santy2cu Note Added: 0002992
2009-09-24 10:37 peter-endian Relationship added related to 0001927
2009-10-12 08:12 Anonymous Note Deleted: 0002991
2009-11-24 21:07 mogyiman Note Added: 0003352
2009-11-25 00:18 peter-endian Note Added: 0003353
2009-11-25 06:24 mogyiman Note Added: 0003354
2009-11-25 11:37 peter-endian Note Added: 0003362
2009-11-25 11:38 peter-endian Relationship added related to 0001151
2009-11-26 11:30 mogyiman Note Added: 0003402
2009-11-26 11:31 mogyiman Note Edited: 0003402
2009-11-26 11:35 mogyiman Note Edited: 0003402
2009-11-26 11:36 mogyiman Note Edited: 0003402
2009-11-26 11:37 mogyiman Note Edited: 0003402
2009-11-26 11:37 mogyiman Note Edited: 0003402
2009-11-26 11:38 mogyiman Note Edited: 0003402
2009-11-26 11:38 mogyiman Note Edited: 0003402
2009-11-26 11:38 mogyiman Note Edited: 0003402
2009-11-26 11:39 mogyiman Note Edited: 0003402
2009-11-26 11:39 mogyiman Note Edited: 0003402
2009-11-26 11:40 mogyiman Note Edited: 0003402
2009-11-26 11:40 mogyiman Note Edited: 0003402
2009-11-26 13:06 mogyiman Note Edited: 0003402
2010-09-23 15:26 peter-endian Status feedback => closed
2010-09-23 15:26 peter-endian Resolution open => won't fix

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

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker