More information would be helpful.

What name server should the LAN system be using? Is the LAN system correctly correctly for that (static IP) or getting the correct name server IP address from its DHCP server? Is the DHCP server configured to supply the correct address?

Perhaps your firewall is blocking all access to the name server. Perhaps the firewall is blocking DNS access to the name server.

Some parts of the developer rules page on the dev wiki may be useful to you.  The site for it seems to be down at the moment, so here's a cached version: http://webcache.googleusercontent.com/search?q=cache:xNnNncCyXkUJ:devwiki.pfsense.org/DeveloperRules

There are also other pages that may be useful.  Cached version of the main page: http://webcache.googleusercontent.com/search?q=cache:CCzm5_BWozEJ:devwiki.pfsense.org/

It is better to get get each network segment working to the internet, then you can work on getting them to talk to each other. Basically it is rules and a lack of NAT for each network to talk to each other. Without knowing what rules you have set, what NAT you have set, and the packages you have installed, it becomes a guessing game for us. LAN is going to have a default allow rule, but any OPT interfaces will not. If you have not created a rule there then opt interfaces will not have internet or any access.

Usually this is from the rate program on the realtime traffic graph getting stuck…

The usual way to kick it in the rear is (via ssh/console shell)

killall -9 rate

If that doens't work:

killall -9 php; killall -9 lighttpd; /etc/rc.restart_webgui

While we don't technically support that in the GUI, the underlying OS is perfectly capable of doing that. It can take a little hacking to make it work, but it can be done.

On 2.1 you can adjust the "retries" on the pool. And there is a Settings tab with settings for the interval and timeout.

You might change to a different monitor type, see if it helps.

@mklopfer:

What it seemed like was happening was the web server was spending time trying to maintain dropped connections to the outside at the expense of inside connections - which should never touch the firewall.  All internal machines used an internal DNS server that specified the IP for the web server that was on the same subnet.  It looks like the symptoms we were seeing were indirectly related to the reflective NAT issue.  For some reason there were tons of connections between the server and itself trying to loop back over an external address–-my best guess is that something somewhere was hardcoded to talk over that IP.  But if that were the case, removing NAT reflection would not resolve the issue - it would still try and talk out and back and be blocked.  I'm still at a loss to the exact mechanism of the problem but any speculation to help others in the future is welcome.

My guess would be that the html/php/asp is telling the client to go to http://<externalip>/internalpage.html/php/asp instead of ./internalpage.html/php.asp and as a result you where getting essentially redirected to the external ip instead of it using the internal ip from DNS. This happens sometimes when your webpage needs to load data from another page. This is generally the wrong way to setup a website IMO.</externalip>

Looks like that would reduce the amount of detail shown in the full logs. Does the firewall log view in the GUI still work properly when you have this active?

I'm not sure that's a change that many people would want to make, but it's not a large change, so people can change it on their own if they like.

Ha, good to see I'm not loosing my mind. Yet.  ;)

Steve

@marcelloc:

@luke240778:

So i am guessing that the install of Sarg somehow changed or messed up Lighttpd?

Anything i can do to get this sorted out?

As I told you, there are pfsense users using both.

Your reply doesn't even moderately answer my question..  I am not asking if it is possible to run them both or not, i already know you can..  i am asking, from what i have already mentioned, if there is some way that the install of Sarg via command line using pkg_add has caused a problem to lighttpd?  Not at all mentioning or talking about the pfSense package of Sarg that i have later installed and is working.

I just need to get this Lightsquid reports sorted and working as i find it a much nicer interface than this Sarg one that i have now got working.

It looks to me like WCCP is what we are looking for.  The problem is that we do not have Cisco infrastructure so the other option we may have to go with is an inline filter with bridged network interfaces.

A monastery you say. Interesting.  :)

If you are familiar with tomato and flashing it to router you should have no problem getting a handle on pfSense. It can seem a little overwhelming at first.

I have never used tomato (though I have used dd-wrt and OpenWRT) so I can't comment on that directly. However there are a number of bandwidth limiting options in pfSense, I would expect to be able to get a better solution using it.

The Alix has a maximum throughput of 85Mbps without any services, such as QoS, running. I would advise you to use something more powerful. Can you continue to run it as  VM?

Captive portal is no problem.

I am unsure about throttling from a consumption point on a per user basis. Others have asked similar question though, try searching the forum.

Steve

Because reflection can't work in combination with Squid. You'll have to have split DNS in that case.

Strange.. i just changed that in the script and the file siz of the backup is alot smaller than the way it originally was..  doesn't make sense does it?

Here are the firs 2 i did, and the last one is after changed script:

-rw-rw-r– 1 mutiadmin mutiadmin 202366 2012-04-22 18:15 config-router-20120422181501.xml
-rw-rw-r-- 1 mutiadmin mutiadmin 202366 2012-04-22 19:15 config-router-20120422191502.xml
-rw-rw-r-- 1 mutiadmin mutiadmin    5938 2012-04-22 20:00 config-router-20120422200002.xml

Use a sftp client!

Hot! That did it! Thank you good sir :)

@wallabybob:

@yaw:

@wallabybob:

An earlier post reported this problem on sk interfaces. Are you seeing a similar problem on vr interfaces?

Can you reference the post, and I'll take a look?

See replies 3, 9 and 11 of this topic. I'm curious if this is a problem of a particular class of NIC or a more generic DHCP problem.

Sorry.. I thought you were talking about another thread. Yes, this is the same issue except with the vr interfaces. It only happens with DHCP, and I can replicate it every time.

@torontob:

Am I not right with the assumption that should be always UP and running?

You are not right: "No carrier" means the NIC is not seeing the carrier signal that should be coming from the switch or other computer that could be connected to it. "No carrier" means there is no-one to talk with hence the link can't be UP. The NIC is broken or it is disconnected or the NIC on the other end of the cable is disabled.