Port foward reflection problem
-
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?
-
I can confirm that the same thing happens to me as well with the current snapshots (grabbed 20100125-2045 last night); I've tested with HTTP, FTP and SSH. The inetd.conf file is actually populated this time; A small snippet of inetd.conf:
19001 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 21 19001 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 8075 19001 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 28852 19001 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 28852 19001 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 20560 19001 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 20560 19001 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 3784 19001 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 3784 19001 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 7708 19001 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 7708 19001 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 7717 19001 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 7707 19001 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 7707 19001 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.90 6881 (...) 19130 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.90 7850 19130 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.90 7850 19130 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 22 19130 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 80 19130 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 65000 19130 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 65000 19131 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 65001 19131 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 65001 19132 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 65002 19132 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 65002 19133 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 65003 19133 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 65003 19134 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.1.253 65004 19134 dgram udp nowait/0 nobody /usr/bin/nc nc -u -w 2000 192.168.1.253 65004I'm not too familiar with how inetd.conf is supposed to be generated - Isn't the first column supposed to be unique per-entry (or per-port)? It seems like there's a good deal of overlap at the beginning of this portion (19001, 19130). Is that normal? Looking at the log, it seems like port ranges are the only things that increment the first column; Single port forward rules don't seem to increment.
-
Commits for one of the below tickets may have introduced a bug in the course of trying to fix other bugs.
http://redmine.pfsense.org/issues/show/193
http://redmine.pfsense.org/issues/show/99Not sure which of those would be more appropriate to reopen in this case, probably #99. Copy that inetd.conf info into the ticket, along with as much info about your NAT port forward entries as possible.
-
Try latest snap.
-
Looks like the latest snaps aren't building properly at the moment (last good build was on the 25th, build.log shows signal 15's); I'll hold off on adding any information until I can get my hands on a fresh snapshot.
-
It should be safe to try a gitsync instead:
http://doc.pfsense.org/index.php/Updating_pfSense_code_between_snapshots
