|Anonymous | Login||2017-03-26 03:26 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001151||Endian Firewall||Firewall (iptables)||public||2008-07-23 12:10||2013-02-22 14:58|
|Target Version||future||Fixed in Version|
|Summary||0001151: portforwarding: unable to access GREEN from GREEN via RED portforward rule|
|Description||as 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.
|Tags||No tags attached.|
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 (?)
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
search for PORTFWACCESS
remove -m state --state NEW
resolution of this issue is not scheduled right now, please use the workarounds instead
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?
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:
portforward from 18.104.22.168:25 -> 192.168.0.10:25
firewall has ip: 192.168.0.1
NAT to 192.168.0.1
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.
edited on: 2011-07-12 20:54
Instead of adding rules for every private IP I've added a single SNAT rule
NAT to 192.168.0.1
That seems to work for me but does it maybe have some unwanted side-effects?
|2008-07-23 12:10||jasonwalls||New Issue|
|2008-07-23 12:10||jasonwalls||Status||new => assigned|
|2008-07-23 12:10||jasonwalls||Assigned To||=> peter-endian|
|2008-08-08 13:11||peter-endian||Note Added: 0001512|
|2008-08-08 13:11||peter-endian||Status||assigned => confirmed|
|2008-08-08 13:11||peter-endian||Target Version||=> 2.2|
|2008-09-10 17:41||chris-endian||Target Version||2.2 => 2.3|
|2008-09-10 17:53||chris-endian||Target Version||2.3 => future|
|2008-10-27 20:49||peter-endian||Note Added: 0001757|
|2008-10-27 20:50||peter-endian||Relationship added||has duplicate 0001400|
|2008-11-06 14:23||yokomaka||Note Added: 0001778|
|2008-12-11 20:53||peter-endian||Severity||major => crash|
|2009-11-25 12:38||peter-endian||Relationship added||related to 0002191|
|2010-02-09 15:23||peter-endian||Note Added: 0003755|
|2010-02-09 15:24||peter-endian||Relationship added||has duplicate 0002662|
|2011-03-18 16:13||ra-endian||Status||confirmed => new|
|2011-03-18 16:13||ra-endian||Assigned To||peter-endian => lorenzo-endian|
|2011-03-18 16:13||ra-endian||Status||new => confirmed|
|2011-03-21 13:13||lorenzo-endian||Assigned To||lorenzo-endian => peter-endian|
|2011-04-15 12:36||icedburn||Note Added: 0006122|
|2011-07-12 20:53||Dj_GL||Note Added: 0006966|
|2011-07-12 20:54||Dj_GL||Note Edited: 0006966|
|2013-02-22 14:57||ardit-endian||Product Version||2.2-rc1 => 2.5|
|Copyright © 2000 - 2012 MantisBT Group|