0002191: SNAT incoming traffic in port forwarding.

Notes
(0002987) peter-endian (administrator) 2009-09-23 13:20	well, you do that in the SNAT page

(0002992) 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.

(0003352) 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.

(0003353) 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.

(0003354) 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 1.2.3.4 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.2" 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 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.2" The outgoing firewall allows everything to go out for now the time this issue is cleared.

(0003362) 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.

(0003402) 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

Please see now our new Bugtracker system: JIRA