Or even a second router seems better than days of effort, and one will have continuous uptime during pfSense updates also: https://docs.netgate.com/pfsense/en/latest/highavailability/index.html https://docs.netgate.com/pfsense/en/latest/recipes/high-availability-multi-wan.html Note the interface names have to be the same in order to sync states. https://docs.netgate.com/pfsense/en/latest/highavailability/pfsync.html#pfsync-and-physical-interfaces

Thank you both for your replies. @bingo600 , my existing home LAN in not in the default and I plan to install the default for him, so I should be OK. @JKnott yeah, that makes sense...that way there wouldn't even be any need to explicitly change the WAN IP during deployment. glad to know that it's just as easy :)

FYI, this has not re-occurred yet so I am going to assume this was a one off.

Thanx Steve. For the reassurance. And yes .. A reboot would not have been optimal. /Bingo

I changed the php file under /usr/local/www/widgets/widgets/thermal_sensors.widget.php and it worked. Thanks!

@ErniePantuso : @stephenw10 said in pfSense-based network security appliance?: The MITM part is still via Squid so the same things apply. You have to install the CA certs on the client or configure them to use the proxy explicitly. As you might have noticed for a long time, nearly every program has settings that enable you to set up a proxy. When a proxy is used, your program will use it for all it's "Internet" communications, and the proxy will do the request on the programs behalf. Normally, when your browser want to connect to "forum.netgate.com" it will resolve this host name into an IP, and connect to that IP. While requesting info (a web page) "forum.netgate.com" will reply back with a server certificate that embeds the name of the host you are connecting to. Now your browser knows it's actually communicating with "forum.netgate.com". When you use a proxy, when your browser want to connect to "forum.netgate.com", it will connect to, for example 192.168.1.1 - where the proxy 'lives', and that one will certainly not answer with "forum.netgate.com" (that's impossible). It will probably be something like "pfsense.yourlan.tld". Your browser is informed that this is a proxy it has to use, and it is informed to accept this certificate. The proxy will go ahead and does the real request to "forum.netgate.com" for you. It will do the normal TLS verifications, and answer back to the browser with the results. For a short moment, the data received on the proxy, is visible. It could do all kind of data inspection. 3 reasons why all this isn't as simple : For all programs, all protocols, all ports, the proxy should know how to handle the traffic. Basic web browsing, ok, that will work. But web pages could contain scripts, ad they can do whatever they want, on a totally non documented way ... proxies won't work : the web page doesn't 'work' any more more. Every program on a device has to be set up to use the proxy. Maybe a OS wide setting is possible, but now you should hope programs actually respect this. If a server certificate announces "HSTS" your proxy won't work any more (edit : that is, the browser will not the proxy certificate as re replacement). And guess what, more and more sites use HSTS these days. Because "sites" won't to talk to the 'real' person, not some MITM guy has these sites have to guarantee the end user that the data isn't robbed, scanned, mistreated etc etc. Btw : these are my words. Never used a proxy, squid etc. I'm just reading about it, for years, a decade or so. @jimp video's, @stephenw10 mentions them above, are very well done. Many more exist on Youtube. True, I tend to say that the usefulness of a proxy doesn't exist any more. It something of the past. MITM has to die. It wasn't "The solution".

Hi, i have resend the the pc to the retailler who sent me back a new motherboard with cpu and nic integrated. It's now ok many thanks for your help

@tobiasfrajka I feel your pain. I had similar issues with trying to cast Youtube from phone on one subnet to my xbox on another subnet. Of course I made sure it worked when on the same subnet. Followed all the tutorials, videos, threads and suggestions, and had any-any rules on both networks but I eventually gave up. I don't know if I was missing something or if something has fundamentally changed with how casting, SSDP/mDNS works and whether the solutions people once had success with is still relevant? I was actually more interested in understanding why it didn't work than anything else, but never got to the bottom of it. I was even trying to compare packet captures of the working setup on the same subnet vs. the broken one, but I had no idea what the packet process should look like when it's working. I wish someone with deeper knowledge could shed some light on that or how to troubleshoot such issues.

@jwj, I suggest you watch The Social Dilemma on Netflix. It's exactly what you're talking about. [image: 220px-Social_dilemma_xlg.jpg]

Turns out global vNet peering on the LB function of Application Gateways is not supported. This is a Azure Application Gateway limitation and not related to Pfsense: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-troubleshoot-peering-issues. Posting this on 10/5/2020 if anyone else runs into this issue, I hope this helps

Script de conexión --> #BEGIN EDIT /bin/echo "Client $common_name from $trusted_ip connected @ date" | /usr/local/bin/mail.php -s"OpenVPN Connection Beginning" #END EDIT Script de Des-conexión --> #BEGIN EDIT /bin/echo "Client $common_name from $trusted_ip disconnected @date" | /usr/local/bin/mail.php -s"OpenVPN Connection Ending" #END EDIT Estos scripts funcionan perfectamente, acabo de testearlos. Así debería quedar el script "openvpn.attributes.sh" [image: 1601906994131-30c42a3b-68e4-4c13-a83e-828d0a586bcc-image.png] Saludos

Do all interfaces in the bridge fail to hand out DHCP leases? Or just this new one? If the pcap shows the DHCP offer leaving the member interface either it's not reaching the client or the client is rejecting it. The client and server are using the same OUI there, they are both virtual devices? Something in ESXi blocking/dropping it? Steve

I managed to fixed the problem, turns out the VM host hadn't been rebooted since before outage, so I thought I'd give that a shot, and it seems to have fixed the problem. Maybe the physical NIC was left in some partial state or something. Thanks to everyone who helped. SOLVED!

What are you running pfsense on? When you say you replaced the modem, it really was a modem.. Or a gateway (modem/router combo) What is the model number? What upload speed to you have? Your pfsense wan is pubic IP or rfc1918? I run uploads all the time, plex server serving up to friends and family.. I just uploaded over 45GB of stuff for just the other day for my friend.. Looks like I do over 400GB a month [image: 1601774020482-400g.png] Never seen an issue.. The other day when I was uploading, pretty much pegging my upload pipe for hours.. No traffic shaping, no need to really do anything at all.. So to try and figure out your issue going to need some more info. You say you start seeing packet loss, well yeah if that happens at some point pfsense is going to kill the connection on its own once it thinks its gateway is offline.. Can we see your quality graph when this happens... For example you can see here while my response time did go up while uploading that large 45GB of data.. There was no packet loss. [image: 1601774354437-upload.png]

Well while your connected it would be only you, but would assume this would rotate like every 24 hours or something. And either way the IP space would be the vpn space, and as they clearly state on their website they don't log or work with any government agencies... And do not profit in any way with the GBs of traffic their users use.. That $29 for life gives them plenty of profit ;) why would they have any need to monetize whatever your doing via their vpn? ;) Most likely even that single IPv6 they give you is only being used by you.. So unless they handing out ULA address space and natting it?? Even that single IPv6 give you is not "shared" like your typical IPv4 vpn..

Thanks for the info folks. The reference to the above video about running 'fsck' in single user mode helped. That solved the problem! Now the data streams nicely to the syslog server. Didn't see much error correcting but apparently it was enough. @jimp Normal shutdown... yes. The question was why though and why no logs were flowing.

@AKEGEC I asked them that and they said the modem had been up for 20+ days. That matched up with the uptime in the GUI. As for weather, at that time it was really calm and moderate. No storms in the area. (That said I will never count out squirrels as a culprit. :)