@dbennett: PHP Errors: [28-May-2015 17:09:43 CST6CDT] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 260833280 bytes) in /usr/local/www/exec.php on line 240 This is the Diagnostics: Command Promp GUI Page /usr/local/www/exec.php on line 240 Did you run any commands from that GUI page?

@doktornotor: None. Traffic on the same subnet does not go through the firewall. Yes, I know. But 192.168.70.10 (the load balancer virtual server on SRV network) is a virtual IP address on the firewall, so its traffic goes to the firewall and enter in the load balancer. Anyway, I solved. The outbound NAT rule was wrong. The correct one is: Interface: SRV Protocol: any Source: network 192.168.70.0/24 (the SRV network) Source port: empty Destination: network 192.168.70.21/32 (the IP address of the server in the load balancer - I have to create one rule per server) Translation: network 192.168.70.254 (The CARP virtual IP address for the SRV network) Thank you very much! Bye

Good question, great answer. Are there current NICs that do not support VLAN tagging themselves? If so, which?

bump?

Dear fellows, Finally the problem is solved! That was quite a tricky problem, due to the fact that I was trouble shooting it from distance. One of the computers behind the pfsense firewall was running uTorrent with enabled DHT. When the computer was ON and uTorrent was in IDLE mode (no active seeding/leeching, just the app running) the WAN interface was constantly dropping my PPPoE connection. However, when uTorrent was running (actively seeding/leeching), there is no problem, but as soon as it goes to IDLE - pfsense restarts all services. As soon as I disabled DHT on uTorrent the problem disappeared. Unfortunately I couldn't identify why with DHT enabled and uTorrent in idle, pfsense was restarting the services, but at least the problem is gone. More on the uTorrent issue: https://forum.pfsense.org/index.php?topic=93812.0 Thank for all the help. Regards, Nick

Try using a geographic named zone and not that one, and you would at least need to kill/restart charon and filterlog, but a reboot is best after changing time zones.

Just as an update, we were unable to further reproduce the errors. Most probably due to the fact that we have reached our steady -sort of-  set of rules. But we suspect  the process filterdns is messing things up somehow when hierarchical aliases are used. We hope this will be addressed in future releases as PfSense is a great product. BDAB

Hmm. I would think your logic is flawed. I use CARP for failover purposes and send my logs to an ELK stack to visualize firewall entries. Why would I want logs from the secondary host when its in Backup state and not being actively used? And even then, I could just configure the other hosts to use their LAN IP as source? And keep primary as CARP.

@NOYB: Please post packet capture of both the successful Android WoL and failed pfSense WoL. All methods of WoL are not created equal, and it could be very telling as to why one works and the other does not. Will try this as soon as I can… Good advice. Thank you.

@Derelict: You might need to https://portal.pfsense.org/support-subscription.php  They'll know. I still think you should consider spanning tree.  Once the topology is established, in my experience RSTP converges in fractions of seconds and is a viable HA solution at layer 2, given multiple L2 paths to the same destination. I am admittedly out of my lane and am going to merge right. You may be right. What I'm trying to do is a little out of the norm. I'll give spanning tree a look and see how it impacts fail over speed. Maybe it'll be acceptable. I don't feel like it's the most elegant solution, but it may do the job. In the meantime, if I can figure out how to down the bridge on boot up, that would be the ideal solution. Maybe someone else might chime in with a solution. I appreciate you spending so much time trying to help. It's very appreciated! Thank you.

Why not use the package DANSGUARDIAN, if you can figure it out.  To me the package is over complicated at best.

If you don't want to look at the sniff of when you get an IP, look at the lease in pfsense. in /var/db you should see a dhclient.interface file so example lease {   interface "em0";   fixed-address 24.13.xx.xx;   option subnet-mask 255.255.248.0;   option routers 24.13.xx.xx;   option domain-name-servers 75.75.75.75,75.75.76.76;   option host-name "pfSense";   option domain-name "hsd1.il.comcast.net.";   option broadcast-address 255.255.255.255;   option dhcp-lease-time 345600;   option dhcp-message-type 5;   option dhcp-server-identifier 69.252.202.7;   renew 4 2015/5/28 16:46:18;   rebind 6 2015/5/30 04:46:18;   expire 6 2015/5/30 16:46:18; from there you can see the dhcp server, see how mine is 69.252.202.7 But sniff show you the whole picture.

Yeah, it is generally important that traffic on ports 137/138 and 445 never leave the WAN interface to your ISP, as this also opens some holes in the firewall….. I just had here the case, that in my test environment my WAN interface was in productive LAN. In my test LAN behind the pfsense I was able to browse the shares outside of my WAN interface  ;D Incoming traffic was blocked at all, except 443 to pfsense. So if your computers talk to the computers outside in internet .... they answer. You may not like all these answers ;-D And the firewall will let the answer through .... as your LAN computer opened the session.

Hummm… yeah, you're right.  The dtrace kernel modules might not be there for dtrace to access.  I got the following error: dtrace -l | grep 'syscall.*read' dtrace: failed to initialize dtrace: DTrace device not available on system Kind of makes it a bit more challenging to gather data....