@stephenw10: What firewall rules do you have on WAN? Any unsolicited traffic on WAN should be blocked by default so why is it showing as 'in-pass'? The obvious answer the that is that it's not unsolicited, something on your LAN is asking for it. Why then is that traffic not showing up on an internal interface? If you didn't know Akamai are a content distribution network used by many companies including Microsoft to deliver updates service packs etc. I would guess that one or more machines on your internal network has got stuck in Windows update loop, downloading the updates, failing to apply them and then trying again. If you go to Diagnostics: States: rather than state summary, and then filter by the offending external IP you should see the NAT state showing your internal machine requesting the traffic. Steve I originally assumed it was a PC, tablet, etc on the LAN causing this like you said, but nothing ever appeared to be sending or receiving anything. It's stopped as of now so its  a bit harder to check on, I am not sure what actually stopped it though, and whether or not I had any part. Using States and filtering by a few of the IP addresses only showed traffic between my public IP and the offending IPs. I'm not sure if this is because it's been a few hours since it stopped, I assume it gets cleared out a bit? Below is the Traffic graph for the last week on the WLAN(i dont have anything on the wired LAN). [image: Screenshot_from_2014_02_20_04_23_24.jpg]

@jimp: That's just how IPsec operates currently. The traffic follows the routing table, so unless you have a route telling it to go "out" the LAN, it will not be sourced from the LAN and will end up going out WAN. If you want better control over the VPN routing, you'll need to use a routed VPN setup such as OpenVPN or IPsec in transport mode + GRE. OpenVPN is much easier if the other side supports it. If your WAN has a static IP, you might be able to work around that by adding another IPsec Phase 2 to cover the path from your WAN IP to the 10.10.10.x network on both ends. Thanks Jim, I tried to create a 2nd phase 2 on both pfSense Routers without success. I set the 2nd PH2 to, Tunnel IPv4                                                  (Also tried to change the Type to WAN Subnet) Type - Address xxx.xxx.xxx.xxx / 32  (WAN address)  Nat/BINAt - None Network - 10.10.1.0 /24                                  (Tried to set this as the remote router 10.10.1.1 /32 ESP tried AES, than Blowfish separately. (all on Auto) Tried with one or several Hashes PFS 512,1024,2048, OFF No Luck. Also tried to turn on "Prefer older IPsec SAs" First PH is solid, First 2nd phase no issue either. ESP 2048, AES256, SHA512 I will try to debug with an ssh shell using      racoon -F -d -v -f /var/etc/racoon.conf Thanks.

@droth1988: You could just get an express card NIC, if your netbook has a slot.  Thats what I used for my netbook, works great. http://en.wikipedia.org/wiki/ExpressCard I have the slot yeah, but not got the card, moved onto a whole pc a friend gave me @rjcrowder: @droth1988: You could just get an express card NIC, if your netbook has a slot.  Thats what I used for my netbook, works great. http://en.wikipedia.org/wiki/ExpressCard I've been searching for a Gig ExpressCard that works on on 2.1. Are you using a Gig card? If so, which one? Unfortunately I dont have one sorry :(, and am no longer using a netbook.

Thanks. 2.1 upgrade is in the works, but I have to make sure it's not going to affect our production network adversely. Realistically we are just going to duplicate our config to a 2.1 install on newer hardware. I'll try disabling the state killing. As far as I can tell it is detecting the GW and I'm not seeing anything being marked as "down".

Not sure I let it get to 3.8M states before taking action - this is production traffic.  My experience is that the adaptive settings don't really help.  When pfSense tosses states for an active connection the sender tries again, apparently the sender has more capacity to generate new connections/states than pfSense has capacity to keep up - pfSense loses every time, so far no matter what the settings are.  My recourse is to reduce the traffic, though that does not meet our business needs.

Yes… This host "Bigfeller" has both the wan IP and Lan IP assigned to the same mac address on Diagnostics/ARP table. IPConfig /all on this host does not show this connection.

You can't just get "some" of the HTTPS in that way. The channel is encrypted before the site request is ever made, and you can't always guess the site by secondary characteristics like the server IP or DNS lookups. You have to see inside the encrypted communication, which is impossible without proxying their traffic explicitly or performing a man-in-the-middle attack on their SSL connection. In most cases, you have to have the clients set their browser's proxy settings to the firewall in order to see any HTTPS. I believe the squid3-dev and/or dansguardian packages can intercept HTTPS transparently but you still have to install a trusted root cert of your own creation on the clients.

The error suggests that somehow it's half installed. The menu and XML entries may be there in the config but not the actual files. Remove and install Lightsquid again and it should work.

It only uses the default unless you have set "allow default gateway switching" under System > Advanced on the Misc tab.

FreeBSD has a tpm(4) driver but it only mentions storing cryptographic keys as far as I can see, nothing about RNGs

The beauty of RRD is that the files do not grow over time. You set a limited size for each data file and never exceeds that. They do seem to grow initially, presumably from a completely empty file, but you shouldn't run out of space. However you can move /var to another media. See this post for a similar project: https://forum.pfsense.org/index.php/topic,67823.0.html Doing this will not get you any further RRD data since, as I said, the files are fixed size but it should free up valuable RAM on the Alix. In nanobsd the RRD graphs are periodically written to the CF card. Since yours will now be on non volatile storage you can adjust that period to some thing very long (maybe disable it?) if you wish. It's in System: Advanced: Miscellaneous: Edit: Looks like you can disable it completely there. Interesting project, let us know how it goes. Has anyone else done this? Steve

No, after writing that post I did some reading and also failed to find the right info. None the less people have used it, there threads here detailing what was required. Edit: https://forum.pfsense.org/index.php/topic,46525.0.html You could try forwarding port 3483 to the Squeezebox server. If the discovery packets are sent to the broadcast address they will hit the interface and should be forwarded. Whether the server will respond or the client is then able to deal with a server in another subnet is anyones guess.  ;) Steve

No problem.  :) To make the firewall rules easier to read you may want to create an alias that contains all your internal subnets, 192.168.200.X, 192.168.10.X etc. Then you can make firewall rules on each interface the allow traffic with destination: not internal subnets. All other traffic will be blocked by default. Steve [image: wifi2rules.jpg] [image: wifi2rules.jpg_thumb]

That could do it. Yes try one of the 2.1.1 snapshots. Go to System: Firmware: Updater Settings: Check the box for a different URL and enter the appropraite URL for your box (32 or 64bit) http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/amd64/pfSense_RELENG_2_1/.updaters/ http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/i386/pfSense_RELENG_2_1/.updaters/ Check the box to allow unsigned images, only the releases are signed. Steve

The packet capturing when you select Filter "All" was fixed up by this commit - https://github.com/pfsense/pfsense/commit/6901d6af97920f816b4dfc1b6d7efebda0bd7633 - and will be in 2.1.1. Try and see if it helps for your situation, transparent mode.

@phil.davis: Normally the "DMZ" is just another ordinary LAN, that happens to have some servers to which public port/s are forwarded from WAN1, WAN2… The DMZ does not have an upstream gateway to the internet on its own subnet. The upstream gateways are on WAN1, WAN2... through which the internet is reached. So do not put a gateway on the DMZ interface. You cleaned it up by going back to a previous config - that works! For others, if you do not easily have a good previous config, remove the gateway specified in the DMZ interface, then go to System->Routing, select the real WAN as the default gateway and delete the DMZ_GW. General rule: If an interface is to an internal LAN (i.e. usually with private IPs) then do not put a gateway. If an interface has an upstream device that is the way out to the internet, then it is a WAN and should have a gateway set. Phil, Sound good! I did see a DMZGW listed under GATEWAYS but I did not find a way to remove it. I will definitely keep this in mind. Thanks for the quick response and heads up!

I'm going to get the most available, but I'm not sure yet what that is. I've been trying to find different options. My goal is to have equipment that can handle a high amount of bandwidth, even if it's not available, so that when it becomes available, we can just connect a better connection. Everyone is interested in building the best possible arrangement, within reason of course. Thank you for your response!