Never mind, I disabled "TFTP Proxy" from System -> Advanced -> Firewall / NAT, Then did a UDP port forward from 69 to 127.0.0.1 on port 69. I then set the TFTP server to listen on the LAN, uploaded my PXE files, and used TFTP GET and transferred the file perfectly.

You might try logstash.  I haven't used it personally, but I'm told folks like it and that it isn't as heavy as a full Splunk installation. Splunk supports acting as a syslog server itself, and accepting syslog style traffic on port 514 (or whatever port you want).  I'm using Splunk Storm[1] as a destination for my pfSense logs.  Unfortunately, at the moment I'm having to do it in a very round-about way.  It seems as if the Splunk Storm instance isn't actually listening for UDP traffic, but TCP traffic works fine.  I ended up installing a Splunk forwarder on a different host in my network, making that listen for log traffic from pfSense (UDP), and sending it from there onto Splunk Storm (over TCP). The basic version of Splunk Storm is free, but there are quite a few limits (how many accounts you can have log into the same instance, how long the data is kept, etc).  One of the really nice things is you don't have to administer the Splunk server yourself. [1] https://www.splunkstorm.com

After having the switch out of the mix for a week or so, as expected, it made no difference.  OTN physically/directly attached to the pfSense and channels still went missing.  I was hoping maybe somehow the switch was caching something in its internal routing or ARP table, but that doesn't seem to be the case. That's odd. Channels stay available even when channels are switched? I would assume that if you switch to a different channel then the new channel is subscribed to and the old channel is unsubscribed (via IGMP). So either the unsubscribing does not happen or there is something else that your ISPs box does. Yep, it seems as if the channels vanish after a while - not right away.  I don't know exactly when they stop working, but initially they all seem to work fine switching through them. I put the ISPs router back in (so pfSense out), and have a packet sniffer set up like a mouse trap with peanut butter trying to grab anything to/from what appears to be a management port, 4567.  I'm hoping there is a clue, or a way to access that ISP device's internal configuration to see if I'm missing something in my multicast setup. Can you just open the firewall completely temporarily? This could rule out that the firewall is causing the problems. Thanks for the suggestion.  I've put that on my list of things to try.  I need to look at it again, but IIRC there are rules showing up in the pfSense logs that do not seem to be accessible in the UI that I've been able to find. Each new configuration takes some amount of time (have been giving it a few days or so) for the channels to stop working, which is making this difficult to sort out. I'm not sure if this is related but when I was looking at some packet traces a couple of weeks ago with the ISP's box in place, I think I noticed something that may be different about two of the channels I'm having trouble with - each of these trouble channels has the same source IP as at least one adjacent channel.  I haven't gone through all channels recording their IP addresses, I just happened to notice when changing channels on these particular ones, the source IP wasn't changing (but the channel/programming changes just fine).  On other channels that always work, they don't (from what I could see) have the same IP. The two problem channels do not share a source IP address (one is channel 13 and the other channel 119) with each other, they just seem to share one with an adjacent channel (ie (don't remember exact specifics) channel 13 and 14, channel 118 and 119).

I think that using CARP + Virtual IP will help me :-) [image: My_CARP_and_VIPs.png] [image: My_CARP_and_VIPs.png_thumb]

@james_h: You can just create one rule under LAN firewall rules, allow any to WAN to get you up and running. Could you show me how I create a single rule? Its like subnet = lan any to wan any!?

Check the system logs on the secondary, odds are it's being pushed a setting that it can't properly apply (usually trying to add a VIP to a missing interface or similar)

@xenHR: What would my cables have anything to do with it. Because with rules like above, there is absolutely ZERO chance you'd get webGUI access blocked by firewall on LAN. Except that you claim that instead can access it on "WAN". Cannot see anything productive coming out of this. Wipe the mess and reinstall the box from scratch, making sure you set up both WAN and LAN properly at install time. @xenHR: The LAN is operating fine except I can't get out or to web gui. Sure. If you plug the cables to a dumb switch, no firewall is involved in traffic flow between boxes on that switch.

Snort has blocked things a time or two for users. You can test DNS from Diagnostics > DNS Lookup or using "host" from the shell. You can check general connectivity by trying to ping a host on the Internet by name. Usually if your DNS and routing are OK, and packages still do not load, it turns out to be either something like snort blocking or maybe broken IPv6 routing that makes pfSense believe you have IPv6 connectivity when you do not. See https://doc.pfsense.org/index.php/Controlling_IPv6_or_IPv4_Preference for a fix for that.

Possible but not recommended. It's best that everyone have a unique certificate, otherwise you may as well not use certificates at all and use auth only.

@BBcan17: Is there a reason why the "COMM" command is not included in the pfSense /USR/BIN folder? Is there any way to download that file from a secure source? Reasoning is the same as any other "missing" item, we remove things that aren't needed and/or to save space. We don't have a need for that utility and nobody has required it before, so it's not included. You can copy the utility from any other FreeBSD installation that is of the same version as pfSense you're using.

yes i read that while searching for an alternative - dns blacklist. sad to say its not updated upto its current version of pfsense. well yeah i use squid3 in order to run smoothly squidguard. but i am hoping for an alternative, a web filter without having a proxy anymore - aside from opendns.

That should work OK with VLANs. You'd put pfSense on a trunk port, and make a separate VLAN for each WAN, and then in pfsense define the VLANs and assign them so they each appear as a separate interface.

That is possible with squid+squidGuard if you're just talking about an HTTP site.

@johnpoz: What about if the url is say https://something.ads.com/somepath/dir/ad.html ?  Since this does not exist on whatever webserver you point to your webserver would normally return 404, and your browser might bark that the SSL on the https isn't trusted.  So you would need to make sure your browsers trust whatever ssl cert your using.. That's still up to the web server. It's quite easy in Apache to have it answer any request with a specific file via mod_rewrite or similar. Other web server software probably has a similar mechanism. Beyond the scope of the forum here, but it turns up easy in a google search, or just look at what CMS packages like Wordpress use in their .htaccess files.

I have tried using the intel card for both LAN and WAN, and separate intel cards, one for LAN and one for WAN without any effect.