@tmacka88: looked into the Unifi. they look pretty good and not too expensive compared to other enterprise solutions. might have t get some and have a play. any idea when v3 will be released? also how did you find setting these up with pfsense? was it very difficult? thanks No clue when v3 will be released. The betas are very stable at this point though, so it shouldn't be too far down the road. As far as setting them up with pfSense, what do you mean? They'll work with any routed network, really, regardless of your L3 device. I plugged them in, the controller server saw them, I adopted them, done.

@fser: -I have changed default ip to 192.100.100.1 and set everything on pfSense web ui. 192.100.100.1 is completely invalid IP for LAN. You just don't invent things, there's RFC1918 for non-routable IPs for local networks (ab)use. NetRange:      192.100.100.0 - 192.100.100.255 CIDR:          192.100.100.0/24 OriginAS:      NetName:        DNIC-RNET-192-100-100 NetHandle:      NET-192-100-100-0-1 Parent:        NET-192-0-0-0-0 NetType:        Direct Assignment RegDate:        1991-04-12 Updated:        2009-04-02 Ref:            http://whois.arin.net/rest/net/NET-192-100-100-0-1 OrgName:        DoD Network Information Center OrgId:          DNIC Address:        3990 E. Broad Street City:          Columbus StateProv:      OH PostalCode:    43218 Country:        US RegDate:        Updated:        2011-08-17 Ref:            http://whois.arin.net/rest/org/DNIC :o ::)

Awesome, thanks Steve.  Just installed the latest and it's working great.

It is a squid message. In its default incarnation, Squid doesn't intercept https, so that is why https is working. Did you intend to use Squid? If not, System->Packages and remove it, and look in the config for any trace of Squid. If so, then you would be best to post in the Packages forum with details of your Squid settings.

The packages all attempt to reinstall on the first boot after the upgrade. They will install the latest version of each package. The settings are all in config.xml so they get re-applied after the package install. Some packages need you to go into their web-interface and click enable/save to make them go again (pfBlocker comes to mind - not sure why it does not just do its thing automagically).

Try disabling the firewall by issuing this command : pfctl -d, then try to access. Once you gain access check your firewall rules.

I decided to just let the box keep running and overnight memory usage dropped back to 42% which is the amount used immediately after restarting dnsmasq. The box is running fine, no problems. Highly recommended, at least for small, uncomplicated networks. Thanx…

Just an update on this, I have only just got round to re-doing the network, and it works perfectly :) With the same network diagram shown here; [image: index.php?action=dlattach;topic=72925.0;attach=41289]

Dear Jimp, many thanks for your hint. Erasing all logs did the job, so this one is currently solved. To further avoid a log stall, do you know of a method to do so? In particular, would a syslog server like syslog-ng do the job? I will have post another question on the release depends here: https://forum.pfsense.org/index.php?topic=74897.0

Double check your rules.  It might not be an encapsulation problem as so much as a rules issue.  I have just setup a Cisco to PFSense GRE tunnel and was having trouble.  I searched the forums, found your post and started thinking I was having the same issue.  But when I looked at my interface status, I saw that I had packets coming into the GRE interface but they were getting blocked.  I put an "any any" rule on the opt interface that I associated to the GRE interface and the tunnel came up to my Cisco 7206 router.  It turns out GRE needs to be allowed not only through the WAN but also the OPT interface you assign to the GRE interface.  I see this posting is several months old so if you still need any help post back and I'd be happy to assist.

Hi, Have you tried contacting their support about this? The phone number is 877-880-0055. I am sure they can help get your service restored. Thanks, Vinny

I just disabled it.  That works for me.  Thanks.

You can set it but it appears to get ignored and the pppoe1 interface always gets set as 1492. Last I heard jumbo frame support didn't get added to the FreeBSD version of PPPd (2.4.6) until January this year.  But I'm unaware if the latest update (pfsense 2.1.1) includes this newer version. I know if I manually ifconfig pppoe1 mtu1508 packets still get fragmented,  which is a shame.

@casoah: You realize I can just toss the setup away at any time right? Yes, so do it… yesterday was too late. @casoah: EDIT: I got it, I just had to disable ip masquerading on openwrt. You guys could have mentioned that instead of bashing btw You have been told at least twice that you are double-NATing.

If your trying to access your public IP from the local network you want to enable the nat-proxy in advanced settings. IF your having trouble even pinging your public IP I suspect you are suffering from double-nat ( is your modem a router as well? )

I can help you brother send me a message. @PostalPreacher: If I were to leave my webserver on the same lan as the rest of my network (workstations and webserver would all be on the .49 public address), would I still be able to do NAT reflection with pfSense?