Captive portal issues solved ? Meanwhile I'm using 2.2.2 some time now. This is a graphical result (real time) : http://www.test-domaine.fr/munin/brit-hotel-fumel.net/pfsense.brit-hotel-fumel.net/portalusers.html These stats are from an hotel, so I do NOT control the device of our users (clients), neither what and how the clients are working with the portal. All I know is that pfSense + captive portal works. 2.2.2 is rock solid. Btw : I consider 2.1.5 completely different to 2.2.2  - it's a major kernel upgrade, PHP upgrade ad much more. Something as a "in place" upgrade when it concerns BIG changes are not logic neither usable. Servers aren't upgraded like that, neither desktop PC's, neither firewall and routers. Going from 2.1.4 to 2.1.5, ok, but 2.1.5 to 2.2.2 is another ball game. Put the config file on a clean install - and it rocks. And yes, sometimes its needed to look into the config XML file (its just a clear, readable file) to do some final trimming. Stay away from packages if you can't stand the hard-core code parching.

Steve: Thanks for the kind updates. I have just had success by turning on UPNP in Pfsense for port range 1024-65535 which is the range that Skype indicates it may use. I showed udp status as good now. Let's see how this operates for a while. I have been trying to short this out for a week. Skype is great but they could use a update of the client software. Best Regards, Howard

Thanks Heper.  It was affecting my FTP server (not client), but I already had all of that stuff done.  What fixed it for me was totally bizarre. When I had first set this up a year or so ago I was pretty green.  I had defined the passive port range different from the NAT'd port range for some reason that I don't remember.  Originally I had 30000-30100 reserved for passive FTP (we don't have many FTP users at all so a small range was fine) and mapped it to 20-120.  Duh, so stupid, but I didn't know what I was doing with pfSense at the time.  I saw that, nuked the port remapping and let it sit natively at 30000-30100 and it's been working fine ever since.

Just a like to DD-WRT howto in case someone else hits this thread in future: http://www.dd-wrt.com/wiki/index.php/Wireless_Access_Point

youripadress/system_advanced_misc.php I was configured the "Proxy URL" and "Proxy Port". When erase this configuration, update work again.

I solved using squid in a debian server  :P

@georgeman: Alright, it is confirmed to be the same issue then, thanks thanks it works ! :)

Were you able to get your problem resolved?

@Chti: In the MAC address I entered "XX:XX:XX:XX:50" the address of my modem That creates a conflicting MAC address, assuming your modem is staying as is, which will break any ability to talk to the modem. Clear the MAC address field on WAN and reboot the 4860 so it gets its native MAC back. Then reboot the modem. After that, I'm guessing it'll probably work.

you are right…its the memstick...amd64 rectified the issue,,,,thx

Install the x86 version.

Yes, if you have ssh access you can use SCP to get the files directly from a connected client. If you only have local console access you can view the boot files like: cat /var/log/dmesg.boot Or edit the loader.conf (or better loader.conf.local) like: ee /boot/loader.conf.local That will use the built in EasyEditor but you could use vi instead. Steve

So its not sending valid ftp commands then? Why don't you sniff and lets see the command its sending.  This way the package could be fixed to address clients sending extra info and such in their commands.

@secabeen: @BlazeStar: So what's the best fix then? Wipe out and re-install fresh? Not sure.  I force power-cycled the system and when it booted, it came up cleanly.  Rebooting through PFSense failed every time.  I had to pull the power/hit the reset button.  If you're still having problems after a true boot, then a wipe and re-install is probably your best choice. I did force the power cycling. On the dashboard I get: 2.2.2-RELEASE (amd64) built on Mon Apr 13 20:10:22 CDT 2015 FreeBSD 10.1-RELEASE-p9 Unable to check for updates. Everything seems fine… although I don't know why I'm unable to check for updates.

@heper: yes thats what the .local is for ;) @cmb: That's why you put it in loader.conf.local not loader.conf, .local will never be overwritten by an upgrade. Thanks guys.  Sometimes my Linux experience is a great help in the BSD's.  Sometimes it just helps me get in over my head faster. So many things are similar, but so many are also different. Appreciate it! –Matt

Figure out what it is about those sites that's much slower - is DNS slow/timing out? are you losing connectivity in general between those networks (does ping stay responsive)? What does a packet capture from an affected client show?

If you only have one NIC assigned, then management is open on that one NIC (which is WAN). Where you have >= 2 NICs assigned, then WAN has its usual behavior of allowing nothing. It works that way for appliance-type usage, where maybe it's just a VPN endpoint or DHCP server or reverse proxy or any number of other possible uses.

Is your WAN DHCP or static IP or? Guessing static since it's metro-E and you mentioned a /27. Can you ping the gateway IP when it stops working? My first guess is IP conflict on the IP you assigned to WAN, all of the actions you mentioned to temporarily fix it would temporarily work around an IP conflict. System log may show the source of the IP conflict with a log like "xx:xx:xx:xx:xx:xx is using my IP a.b.c.d".