Port foward reflection problem
-
I don't mean to thread necro, here, but this is still an issue.
I've grabbed the latest snapshot (20091220-2310) and the issue still remains. I've run into this as well, and I've been looking around the forums for information. After reading about some issues present in some older versions of it (those older fixes already applied in this release), I dove into the /etc/inc/filter.inc file and found a few lines starting at line 753:
$reflection_txt = "\tstream\ttcp/udp\tnowait/0\tnobody\t/usr/bin/nc nc -w {$reflectiontimeout}{$target} {$tda}\n";It seems like the nc command was typed twice by mistake, and it's like this for every occurrence of the nc command (there are two more; On lines 760, 785). Modifying the line to read:
$reflection_txt = "\tstream\ttcp/udp\tnowait/0\tnobody\t/usr/bin/nc -w {$reflectiontimeout}{$target} {$tda}\n";Causes the nc message to disappear, but I'm still looking into fixing it - It still doesn't redirect properly to the LAN host; Instead, it's redirecting to the firewall's localhost. I'm not terribly well-versed in pfSense's codebase nor coding in general (more of a hacker), so maybe someone else could take what I've found and turn it into something a little more helpful.
EDIT: Upon closer inspection, it looks as though $target doesn't properly address the LAN host (it comes up blank in inetd.conf). It also seems to be nuking every other reflection-related line once it reaches the final port reflection rule, leaving only the last in the listing present in inetd.conf.
-
try next snap.
-
Newest snapshot (20091222-1721) seems to remedy the issue with redirecting to localhost, but still deletes all reflection rules but the last in the list from inetd.conf (thus meaning only the last rule in the list will be reflected) and in addition causes the filter (re)load to break altogether with ranges of ports, regardless of NAT reflection being enabled or disabled. The error according to the Filter Reload page is:
Syntax error in config file: pf rules not loaded - The line in question reads [78]: rdr pass on fxp0 proto { tcp udp } from any to (Ext. IP Hidden) port 7840-7850 -> (Int. IP hidden) port 7840…
I should add that deleting/recreating the rule or creating a new rule with any port range other than a single port causes the issue, as well.
-
Can you please send /tmp/rules.debug and /etc/inetd.conf and your config.xml.
Even privately if you are concerned. -
I PM'ed the contents of the files in question. I did end up having to remove the port ranges in order to actually get my internet connection to work from within the LAN, so I added one of the ranges I did use before for demonstration purposes. It still causes a filter load error.
-
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/d9e258bb1df4c8a0d720c818ad433f8e9f6c3824
Here is the fix.
-
Thanks, I can confirm that adding those lines did fix the filter load problem with port ranges. The only issue that remains now is that only the last of the NAT rules is kept in inetd.conf for reflection, rather than the entire table (as you can see with the inetd.conf I sent you as compared to the port ranges specified in the reflection rules). It appears that once the list is generated, it deletes all but the final NAT entry.
-
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/34fd61683d5ddaf531a0db916f4d7d5d1e07d54c
:)
-
I applied the diff to filter.inc and modified the NAT table to test it out. It doesn't cause any errors on reload or anything, but it doesn't actually write anything out to the inetd.conf file (it remains empty but for the tftp-proxy line) and the redirects end up not working. It's worth noting that I haven't yet upgraded from snapshot 20091222-1721, so I am working from that version of the /etc/inc/filter.inc file.
-
Sorry to double-post, but I've updated to the latest snapshot (20091224-0722) and the problem persists - The inetd.conf file isn't being properly written to, either not being populated at all, or being populated and then having all the entries removed. NAT reflection is enabled, and I've tried changing the NAT table to force a reload with no success. As far as I can tell, this is probably the last hurdle to getting NAT reflection working again.
-
I also had this problem and here is how i fixed it, I'm not a coder (more sysadmin) so it kinda hack, but it should help the devs fix the problem and provide a solution for anyone who wants it. I had to make a few changes to /etc/inc/filter.inc
Starting around line 803
$reflection_txt[] = "{$inetdport}\tstream\ttcp\tnowait/0\tnobody\t/usr/bin/nc nc -w {$reflectiontimeout} {$target} {$tda}\n"; $reflection_txt[] = "{$inetdport}\tdgram\tudp\tnowait/0\tnobody\t/usr/bin/nc nc -u -w {$reflectiontimeout} {$target} {$tda}\n";And alittle more down
$reflection_txt[] = "{$inetdport}\t{$socktype}\t{$protocol}\tnowait/0\tnobody\t/usr/bin/nc nc {$dash_u}-w {$reflectiontimeout} {$target} {$tda}\n";You need to add a second nc in there, i got it from here http://www.openbsd.org/faq/pf/rdr.html
Next a few lines down you need to update:
$inetd_fd = fopen("/var/etc/inetd.conf","a"); /* add tftp protocol helper */ /* fwrite($inetd_fd, "tftp\tdgram\tudp\twait\t\troot\t/usr/local/sbin/tftp-proxy -v\n"); */ $reflection_txt = array_unique($reflection_txt); foreach ($reflection_txt as $txtline) fwrite($inetd_fd, $txtline); fclose($inetd_fd);The big there was changing the "w" to "a" (the a tells it start at the end of the file, not the top). I commented out the tftp-proxy part, as this should be moved outside the loops somewhere, but I'm not using it so instead finding the right place, I just commented it out.
Last change is around line 1166
$natrules .= filter_generate_reflection($rule, $target, $extport, $starting_localhost_port); $natrules .= "\n"; $starting_localhost_port++;You need to add the "$starting_localhost_port++;". I could not find anywhere that was being incremented so every new rule was always using port 19000
-
I just wanted to chime in here and mention that I'm affected by this issue. I run a web access portal behind my firewall via NAT port forwarding. Need to be able to use the same URL whether inside or outside my home network but the NAT reflection is not working. Worked fine under 1.2.3 - does not work with "2.0-BETA1
built on Fri Jan 8 03:48:57 EST 2010
FreeBSD 8.0-RELEASE-p2"Edit: Thought it might be useful to point out that this was an in-place upgrade from 1.2.3
-
I made some changes lately so try newer snapshots.
-
The latest snapshot (20100108-0349) has the same problem as previous - The NAT reflection rules are not created properly, and only the last NAT rule is listed. I can confirm that casshan's fix did actually solve the problem and that NAT reflection is fully working on my setup with those modifications. Many thanks, casshan! Maybe someone can clean it up to work with the tftp proxy so it can finally be deployed and fixed with future snapshots.
-
That is an old snapshot actually.
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/01cf3e74e5c1fae3c47c0e0154a0f1bd0964d986
This are the changes. -
That's an old snapshot? It was (and is) the most recent available in the i386 repo. Are updates still being made at http://snapshots.pfsense.org/FreeBSD_RELENG_8_0/i386/pfSense_HEAD/updates/ or is there another place to receive updates now?
-
The snapshot server is having some hardware issues and may not have been building new snaps. Last I heard they were waiting on FedEx to deliver the new server to replace it. I imagine it will have to undergo some configuration and testing before moving to the data center to replace the failed server.
The snapshots URL is actually pointing to a mirror site right now and not the server.
-
I just upgraded to "2.0-BETA1 built on Fri Jan 22 00:26:29 EST 2010" and am still having the issue. After the upgrade I deleted a port-forward rule and recreated it with linked filter rule but it's still having the same issue.
-
Can you detail what issues?
-
@ermal:
Can you detail what issues?
Sure - the same issues as I mentioned previously. I have a port forward setup for HTTPS to forward web access to an internal web server. When I access the pfSense box's ip as https://xx.xx.xx.xx from a machine outside my private network, this works just fine. When accessing it via the same URL from a machine on my internal private network, it is unable to connect. Specifically, the error message from Firefox is "The connection was interrupted" which happens immediately - no timeout period. If I remove the forward rule and try this connection again, Firefox waits a long time and then reports, "the connection has timed out". This tells me that some part of the port forward reflection is working, but not successfully.
This worked fine externally and internally under 1.2.3 but has failed from the internal side since I upgraded to the 2.0 beta a couple weeks ago.
Since this was an upgrade and there are some mentioned issues with upgrading, would it be worthwhile to rebuild from scratch? Would resetting to factory defaults be sufficient?
