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

0000543: Port Forwarding not working - MantisBT
MantisBT - Endian Firewall
View Issue Details
0000543Endian FirewallFirewall (iptables)public2008-02-04 14:022008-04-23 17:41
0000543: Port Forwarding not working
I installed 2.2 Beta 3 and imported the backup from beta 2. I had three ports forwarded on Endian which had been working previously. Now, none of them work.
I tried deleting the entries and recreating them, but no change. A reinstallation didn't help either. Copy of output from iptables -L attached.
No tags attached.
has duplicate 0000547closed peter-endian Port forward is broken. 
has duplicate 0000555closed peter-endian Problem with NAT, port Forwaring 
has duplicate 0000662closed peter-endian Port forwarding / NAT does not forward to WEB server on GREEN interface 
related to 0000452closed peter-endian Multiple Uplinks, Ports Not Being Forwarded from Uplink1 
related to 0000592closed peter-endian portforwarding: each rule with ANY Uplink as source changes to ANY after any rule will be deleted. 
related to 0000596closed peter-endian portfw using a destination port range fails to create a valid iptables rule 
related to 0000014closed peter-endian PPTP Passthrough does not work 
txt iptables.txt (10,740) 2008-02-04 14:02
txt logging.txt (52,458) 2008-02-04 14:45
log devorem-putty.log (54,320) 2008-02-05 14:47
txt logging2.txt (24,412) 2008-02-05 15:02
log putty_kfason.log (78,794) 2008-02-05 15:05
txt putty_log_dmayan.txt (21,421) 2008-02-06 17:34
? efw-firewall-2.2.45-0.endian11.i586.rpm (68,648) 2008-02-19 19:02
Issue History
2008-02-04 14:02SotaNew Issue
2008-02-04 14:02SotaStatusnew => assigned
2008-02-04 14:02SotaAssigned To => peter-endian
2008-02-04 14:02SotaFile Added: iptables.txt
2008-02-04 14:07peter-endianNote Added: 0000884
2008-02-04 14:07peter-endianStatusassigned => feedback
2008-02-04 14:18ra-endianTarget Version => 2.2-rc1
2008-02-04 14:45SotaNote Added: 0000886
2008-02-04 14:45SotaFile Added: logging.txt
2008-02-05 08:27ra-endianRelationship addedhas duplicate 0000547
2008-02-05 12:04peter-endianNote Added: 0000894
2008-02-05 14:46devoremNote Added: 0000897
2008-02-05 14:47devoremFile Added: devorem-putty.log
2008-02-05 15:02SotaFile Added: logging2.txt
2008-02-05 15:05kfasonFile Added: putty_kfason.log
2008-02-05 15:05kfasonNote Added: 0000898
2008-02-06 17:34dmayanFile Added: putty_log_dmayan.txt
2008-02-06 17:35dmayanNote Added: 0000900
2008-02-06 21:05kfasonNote Added: 0000902
2008-02-08 13:25XahidNote Added: 0000905
2008-02-08 13:47peter-endianNote Added: 0000906
2008-02-08 13:50SotaNote Added: 0000907
2008-02-08 13:55peter-endianStatusfeedback => confirmed
2008-02-08 13:56peter-endianNote Added: 0000908
2008-02-08 19:15peter-endianRelationship addedhas duplicate 0000555
2008-02-08 21:01juanlockNote Added: 0000910
2008-02-17 05:15rwebb616Note Added: 0000921
2008-02-18 11:16peter-endianNote Added: 0000922
2008-02-18 15:08efee428Note Added: 0000923
2008-02-19 19:02peter-endianFile Added: efw-firewall-2.2.45-0.endian11.i586.rpm
2008-02-19 19:16peter-endianStatusconfirmed => resolved
2008-02-19 19:16peter-endianFixed in Version => 2.2-rc1
2008-02-19 19:16peter-endianResolutionopen => fixed
2008-02-19 19:16peter-endianNote Added: 0000925
2008-02-19 19:20peter-endianRelationship addedrelated to 0000452
2008-03-03 06:05yylawStatusresolved => feedback
2008-03-03 06:05yylawResolutionfixed => reopened
2008-03-03 06:05yylawNote Added: 0000942
2008-03-03 14:45juanlockNote Added: 0000945
2008-03-03 14:47juanlockNote Deleted: 0000945
2008-03-03 17:06peter-endianNote Added: 0000947
2008-03-04 11:21yylawNote Added: 0000950
2008-03-04 12:01peter-endianNote Added: 0000951
2008-03-04 12:03peter-endianRelationship addedrelated to 0000592
2008-03-04 12:16peter-endianNote Added: 0000952
2008-03-04 14:42ra-endianTarget Version2.2-rc1 => 2.2-beta4
2008-03-04 14:43ra-endianFixed in Version2.2-rc1 => 2.2-beta4
2008-03-04 17:37peter-endianRelationship addedrelated to 0000596
2008-03-04 17:37peter-endianNote Added: 0000953
2008-03-04 17:42peter-endianNote Edited: 0000953
2008-03-18 00:29z71crazymanNote Added: 0000964
2008-04-08 07:57peter-endianRelationship addedhas duplicate 0000662
2008-04-22 13:27ra-endianStatusfeedback => resolved
2008-04-22 13:27ra-endianResolutionreopened => fixed
2008-04-23 17:41peter-endianStatusresolved => closed
2009-03-17 06:54raphael-endianRelationship addedrelated to 0000014

2008-02-04 14:07   
Your output is ok, should work.
I'm not able to reproduce this problem here, but there must be an issue.

Could you please send me the output of: --debug --force

and after that, the output of:

iptables -t nat -vnL
iptables -vnL

does the portforward still not work after the setportfw call?
2008-02-04 14:45   
Portforwarding does not work after
2008-02-05 12:04   
this is wired.
the rules in the output you provided (thank you!) are correct.

hmm,. maybe there is something in routing which goes wrong, since we changed
a lot there and it is not trivial anymore.

Could you please post the output of the following:

ip rule
ip route
ip route show table uplink-main

hope i can see the mistake with those output

i try again to reproduce it here.
2008-02-05 14:46   
I'm having the same problem except my 2.2 Beta 3 system experiencing the issue did not have a configuration restored to it but was a fresh and clean install. I am trying to forward 3389 to and 17311 to I had these working successfully on test systems with Beta 2.

I captured the output as requested of Sota. I will attach that as my next step.
2008-02-05 15:05   
I attached my output also Peter since this ticket is a dup of mine.
2008-02-06 17:35   
Attached my output too, same problem!! Config restored from 2.2b2.
2008-02-06 21:05   
This also affects inter-zone as well. For my blue network I allow SSH and a port for an HP printer to GREEN, neither work from BLUE to GREEN.
2008-02-08 13:25   
Same problem here !
Port forwarding broken !
2008-02-08 13:47   
I could reproduce the problem now. It's a problem which is obvious on community version and subtile on enterprise version. Therefore it was not so easy to reproduce.

Here is a work around:

iptables -t mangle -I VPNFW -j ACCEPT
2008-02-08 13:50   
That appears to work - thank you! Will this hold across a reboot?
2008-02-08 13:56   
no, but i will fix it now and provide a rpm
2008-02-08 21:01   
Thanks you. is work, you cant sendme one rpm too..
2008-02-17 05:15   
Where could one find this RPM?
2008-02-18 11:16   
as soon as i post it.. here.
it is fixed right now, but need to do some more testing, then i'll post it
2008-02-18 15:08   
On your workaround post 0000906, after applying the "iptables -t mangle -I VPNFW -j ACCEPT" on the firewall I encountered unwanted traffic on GREEN. I have another back fire-walled server which was giving me reports of scanning and probing from traffic that would have been on RED now showing up on GREEN through the DMZ.

So although it was a workaround it seems to give card banch access from my DMZ to GREEN. I can SSH, Telnet, etc... all from ORANGE.
2008-02-19 19:16   
The update is attached here.
Please install it with

rpm -U efw-firewall-2.2.45-0.endian11.i586.rpm --nodeps

since the requirement-tree it would require does not exist yet within last beta release. That requirements are only necessary for ebtables logging, so that logging for now would not work. You will also get errors that ebtables nflog rules could not be created. Just ignore them for now.

Next release will contain all necessary requirements.
2008-03-03 06:05   
After installing the rpm patch, TCP port forwording from red to green ok. But UDP port forwarding from red to green still not working.
2008-03-03 17:06   
do you have multiple uplinks and forward from a second uplink or it is a simple setup?

It did not happen in our test environment.
I will retry to reproduce..
2008-03-04 11:21   
I have a simple set up consisting of single RED (DHCP) and single green only.

My TCP port forwarding from "Uplink ANY : 25(SMTP)" to my internal server is working and tested reachable from

My other UDP port forwarding rule from "Uplink ANY :20100 - 20199" cannot reach my app. No matter "ANY", "Any Uplink" or "Main" is used the port forwarding still doesn't work

Strange thing occured during my testing: after I removed the 2nd rule (total 5 rules), in the "Source" field all "Uplink ANY" is changed to "ANY". I then rebooted EFW but I cannot browse internet anymore. On the main status page it shows "Connected". I can ping the EFW Green ip from inside green. When I ping, it can resolve the ip address but there is no ping response.
2008-03-04 12:01   
I can confirm the change from Uplink ANY to ANY. Think this must be a migration script (confguration migration from 2.1 to 2.2) which run amok.
I filed that bug as 0000592
Thank you!
2008-03-04 12:16   
The problem you have that after reboot there is no more connection to the outside could be this issue: 0000560

Still trying to reproduce the portforwarding udp issue
2008-03-04 17:37   
(edited on: 2008-03-04 17:42)
was able to reproduce also the port forward problem. it happens only with destination port ranges. if you use a single port number it does not happen.

I filed the bug as 0000596.

Now it's not easy to provide a workaround right now. It has to many dependencies which will break thinks if not installed.
The fix will be part of the next release

2008-03-18 00:29   
when is the next release scheduled team?