Well it started working. Not sure why but it just started working the other day. After a month of using untangle so I could use my works vpn I decided to try smoothwall. Smoothwall wouldn't install because the drivers wouldn't work so I figured might as well install pfsense again and get some logs for this thread. The only thing I did different was to not use the auto install. I just clicked through the defaults. So, I doubt this had anything to do with the vpn working this time but figured I would post about it so maybe it will help someone else. Maybe my work changed something but I have no idea. Its a very large enterprise network so I never submitted a ticket to network team.

I think I know what you mean… By way of experimentation I put this on a webserver: <rss version="2.0"><channel><title>IP</title>         http://www.pfsense.org         <description>Your info as seen by this server</description>         <ttl>1</ttl>         <title>IP address</title></channel></rss> and then subscribed the RSS reader on the dashboard to http://my.web.server/ip_rss.php Obviously it's dependent on the 'public' webserver component.  Is that what you wanted?

Thank you for the response, I do appreciate the assistance. Here is what i have discovered, location A and B are connected via ipsec. Location A holds the mail server.  Location B is unable to ping Location A's External Ip.  Location A is unable to ping location B's external Ip Location B can ping Locations A's INTERNAL IP After looking through the logs I was able to allow Location a to ping Location B, I had to enable ICM (echo request). Unfortunately reversing this on location B was unsuccessful. I have used traceroute for (mail@mydomain.com) which points to location A's external IP on the remote network the route is incomplete at ip 64.230.152.250 I then ran a traceroute at 64.230.152.250 the route gave one hop from my pfbox to 50.43.250.1 then the hop became incomplete. I installed Microsoft Network monitor on a server in Location B and filtered 50.43.250.1 This was the result 943021 2:01:37 PM 3/19/2013 12161.0588449 System PRISMUSASERVER  50.43.250.1 NbtNs NbtNs:Query Request for *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00> <0x00> Workstation Service {UDP:7589, IPv4:7513} 943023 2:01:37 PM 3/19/2013 12161.0744699 50.43.250.1 PRISMUSASERVER  ICMP ICMP:Destination Unreachable Message, Port Unreachable, 50.43.250.1:137 {IPv4:7513} 943095 2:01:39 PM 3/19/2013 12162.5588449 System PRISMUSASERVER  50.43.250.1 NbtNs NbtNs:Query Request for *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00> <0x00> Workstation Service {UDP:7589, IPv4:7513} 943099 2:01:39 PM 3/19/2013 12162.5744699 50.43.250.1 PRISMUSASERVER  ICMP ICMP:Destination Unreachable Message, Port Unreachable, 50.43.250.1:137 {IPv4:7513} 945442 2:02:49 PM 3/19/2013 12232.6994699 50.43.250.1 PRISMUSASERVER  ICMP ICMP:Time Exceeded Message {IPv4:7513} 945444 2:02:49 PM 3/19/2013 12232.7307199 50.43.250.1 PRISMUSASERVER  ICMP ICMP:Time Exceeded Message {IPv4:7513} 945446 2:02:49 PM 3/19/2013 12232.7463449 50.43.250.1 PRISMUSASERVER  ICMP ICMP:Time Exceeded Message {IPv4:7513} 945527 2:02:53 PM 3/19/2013 12237.1994699 System PRISMUSASERVER  50.43.250.1 NbtNs NbtNs:Query Request for *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00> <0x00> Workstation Service {UDP:7589, IPv4:7513} 945528 2:02:53 PM 3/19/2013 12237.2150949 50.43.250.1 PRISMUSASERVER  ICMP ICMP:Destination Unreachable Message, Port Unreachable, 50.43.250.1:137 {IPv4:7513} 945566 2:02:55 PM 3/19/2013 12238.6994699 System PRISMUSASERVER  50.43.250.1 NbtNs NbtNs:Query Request for *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00> <0x00> Workstation Service {UDP:7589, IPv4:7513} 945568 2:02:55 PM 3/19/2013 12238.7150949 50.43.250.1 PRISMUSASERVER  ICMP ICMP:Destination Unreachable Message, Port Unreachable, 50.43.250.1:137 {IPv4:7513} 945626 2:02:56 PM 3/19/2013 12240.1994699 System PRISMUSASERVER  50.43.250.1 NbtNs NbtNs:Query Request for *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00> <0x00> Workstation Service {UDP:7589, IPv4:7513} 945629 2:02:56 PM 3/19/2013 12240.2150949 50.43.250.1 PRISMUSASERVER  ICMP ICMP:Destination Unreachable Message, Port Unreachable, 50.43.250.1:137 {IPv4:7513} looking through location A logs I see no records of Location B's ext Ip, or 50.43.250.1 As for DNS forwarding, My domain has a DNS server, (windows) I assume I would need to put this into the DNS server instead of the PFbox I can't seem to get this to work either. Any more ideas would be appreciated.  I have tried to use the DNS forwarding via pfsense (location b) but also unsuccessful,  I'm  going to reboot the firewall tonight when no one is online, With hopes that there mayu be a glitch although I doubt there is. "Do such pings go over the public internet or over the VPN? On which path should they go? Why?" I expect the pings go outside the VPN, which is ok, this will allow my laptop users which fluctuate inside and outside the building to use the same setting.

found it for those who are interested… /usr/local/sbin/pfSctl -c 'interface reload wan'

It varies a lot, but it can be from things like interface events, scheduled changes, DNS changes, etc. Usually it would log the filter reload in the system log and just before it would likely show the reason.

I'm thinking that my pkg_add of a newer curl broke things at some point. Comparing to an absolutely clean installation, I discovered the following difference: diff php.ini php.ini.prev 27d26 < extension=curl.so Fixing that fixed the issue.

We don't have a setting in the GUI for that right now, but you can edit /etc/inc/vslb.inc, around line 204, and change it there.

np - glad I could be of help.

Start here: http://www.freebsd.org/releases/8.1R/hardware.html#ETHERNET I'm an Intel fan based on other platforms, many pfSense/BSD folks also are fond of them. Amazon has reasonable prices: http://www.amazon.com/s/ref=sr_nr_n_0?rh=n%3A541966%2Ck%3Aintel+pci+ethernet&keywords=intel+pci+ethernet

So far so good :) looks like it's fixed in 2.1. wonder what it was in 2.0.2 that was causing disconnect, does anyone know?

Moved to vmware and lan problems are gone, but now the same thing is happening for wan (basically there are a lot of retransmitions/dup acks in tcp connections), lowering mtu/mss does not help.

On the surface this sounds like a network design issue or possible hardware related.  We're here to help, so state your issue and provide details, so we help you identify a possible config issue, subnetting issue, flaw in network design, hardware issue or bug in the software. Honestly, if you have your network deployed "properly"… DNS, DHCP, WAP's, etc should all be handled outside of the firewall anyway... I do not think PFsense is your issue. There are people here who have dedicated years of their time to provide you with a solid product for FREE, so less ranting... it just inflames the community. Clearly defined goals, issues, details and a map of your network posted in the proper forum is the way to go... the dev's and the community will be happy to help.

Yeah I phrased that badly, I meant to say…. Powerd is disabled by default so unless you have enabled it yourself it won't be running. Enabling it will not provide any significant power savings (or even measurable) because the desktop Atom CPUs don't support speedstep. That doesn't mean it won't effect performance though as it will still attempt to use cpu throttling. See this for why that's not much use. Steve

Update: This seems to have been related to some component of the hardware I was using. I migrated my config over to a dedicated appliance (a Twitter box from TranquilNet with an Atom processor, Intel NICs and a 4GB CF card) and my RRD graphs are now gap-free. I'm still not sure which component was the root of the problem, so apologies if you happen upon this thread hoping to find the culprit. If you do, post the hardware you're using and maybe we can narrow it down.