Apart from the fact that now it's not only 1 single IP. If check the log I posted they are different and I am wondering if as a DDoS (if it qualifies) there is something to deter this or if this also falls under there is no tool to do this yet. Thanks

Here is what I got using clog - basically not working: [root@151-redbox.local]/var/log(20): clog lighttpd.log [1.2.3-RELEASE]                                                  ```                                                                                          [root@151- While the file size is more than one line why do I get only one line? redbox.local]/var/log(21): ls -la total 1584 drwxr-xr-x  2 root  wheel    512 Nov  8 00:20 . drwxr-xr-x  12 root  wheel    512 Nov  8 00:20 .. -rw–-----  1 root  wheel  65535 Nov  9 00:31 dhcpd.log -rw-r--r--  1 root  wheel    4278 Nov  8 00:19 dmesg.boot -rw-------  1 root  wheel  512144 Nov  9 00:31 filter.log -rw-r--r--  1 root  wheel  65535 Nov  8 00:19 ipsec.log -rw-r--r--  1 root  wheel      28 Nov  9 00:28 lastlog -rw-r--r--  1 root  wheel      98 Nov  9 00:16 lighttpd.error.log -rw-r--r--  1 root  wheel  65535 Nov  8 00:19 lighttpd.log -rw-r--r--  1 root  wheel  65535 Nov  8 00:19 ntpd.log -rw-r--r--  1 root  wheel  65535 Nov  8 23:29 openvpn.log -rw-------  1 root  wheel  65535 Nov  8 00:19 portalauth.log -rw-------  1 root  wheel  65535 Nov  8 00:19 slbd.log -rw-------  1 root  wheel  512144 Nov  9 00:29 system.log -rw-------  1 root  wheel    1500 Nov  9 00:16 userlog -rw-------  1 root  wheel  65535 Nov  8 00:19 vpn.log [1.2.3-RELEASE]                                                                                                                                            [root@151-redbox.local]/var/log(22): Thanks

@EddieA: @jimp: No, not a port number, that's a number of open files. Are you sure.  Isn't it the uid of the user who is trying to open all the files:  "nobody".   ;D Cheers. Yeah it is, read it too fast :-)

If that is the case, its lack of presence in the ARP table is probably not the cause of the issue, but another indicator that it is not communicating properly on the network. If it were actually sending packets to the firewall, it would show back up in the ARP table. arping wouldn't help.

Thanks a lot Jimp. It's very interesting, and it will be very usefull. I'm going to try playing with it…  ;)

@Cry: However, all clients now have an IP they can't reach as one of their DNS servers… My mistake, I didn't see him set the WAG200 as a 2nd dns server (the function would not work on the WAG200 in bridged mode anyway). However, his pfsense box is the primary DNS IP.  So I don't quite see it as an issue unless the pfsense box goes down or if he disables the DNS forwarder service for some unknown reason. In any case, bad choice and the backup dns ip should be removed or changed to say, an opendns server IP.

There is a wide range of possible causes for "slow connection", some you might have a degree of influence on, others are entirely out of your control. There is nowhere enough information here to give grounds for suggesting a single cause. Here are some approaches you could take to investigate. Ask the people reporting "slow connection" when they observed it and to what site(s)? (Maybe the site(s) is/are heavily loaded.) Has the first page of a browsing session been slow to load and then subsequent pages loaded comparatively quickly? Maybe your DNS is slow. Take a look at the pfSense RRD Traffic graphs (web GUI: Status -> RRD Graphs, click on Traffic tab) for your WAN connection - maybe your WAN connection is heavily loaded for sustained periods. Take a look at the pfSense RRD System graphs - maybe your CPU is very busy for sustained periods. Edited to remove accidental overstrike. (I should use preview more often.)

Okay, this is not cool. Seems like a disease. It has spread out now to my other router on a different site that I was there today. One of the phones connect to a switch and then the Router lost it's IP and then I went to check the router and it's HTTPs is not responding. I did a telnet 192.168.0.1 20443 and it works fine and Escape Charecter comes on. All ports are fine. All functions are fine except for one device that lost it's IP. Once restarted it picked up the IP again but when I connected directly to the router I still couldn't browse the SSL GUI. Where are the logs for these types if misbehaves? Thanks

Hi guys,    I made a mistake and somehow enabled pf scrubbing that caused all this problems. It is all solved and now working smoothly. I want to apologize for all these confusion. Tks and grateful for all the help Eric P.S.   How do I mark this as solved? If you can please mark as solved thank you.

The way I'm proceeding is: Have a live CD burned with the ISO of pfSense. Back up the config file via the web interface. If the machine crashes and burns, reinstall from the live CD. Then restore the settings (config file) via web interface. If you have added different NIC drivers than what is included at some point, maybe you back those up and document the steps to reinstall those.

OK, thank you very much, Best Regards,

Perhaps this will help you. http://www.pantz.org/software/tcpip/subnetchart.html

Two firewalls cannot share the same IP…..But different IP's over the same physical wire, is possible.

thanks for the reply. I am running the latest version and just loaded up squid. Tamtap

CARP would be good, but keep in mind that with CARP it expects the network interface setup to be identical on both systems. So you'd need to have an interface (or VLAN interface) on each box for each WAN and each LAN, and enough IPs on every interface for the routers and the shared CARP VIPs. (Might hard/impossible to do on each WAN depending on the connection type and ISP)

If a ticket is in "feedback" state, it is waiting for feedback. If it's in feedback state and someone confirms an issue is fixed, it can usually be closed. Often, though, the original problem description was a rare circumstance that requires feedback from someone with specific setups/traffic loads/etc so not just anyone can offer proper constructive feedback. If you see a ticket in feedback state that looks like it should be closed, you might give it another try and then post more feedback on the ticket, or let us know specific ticket numbers that look like they can be closed. Usually someone will periodically review the tickets in feedback state and close them as needed.