Port foward reflection problem
-
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
-
FWIW - I got impatient waiting for a new auto-update snapshot to be available so I attempted the gitsync. That kinda hosed my pfsense box ;-)
So, I decided to start fresh with a new install from livecd using build 2010-02-19 04:18
On a fresh install using that build, the NAT reflection now works properly.
Thank you pfSense dudes!
-Phil
