Yes, looks reasonable otherwise.

What do the states look like when you connect? There are packets both ways? Where are you testing from? Another VM inside ESXi? I assume you have rules to pass that traffic. Steve

@drinkyt said in Homelab Project: Install pfSense into Unifi Network with USG.: I am a Networking student Options Set up a home lab under your existing network infrastructure. Set up pfsense as your network boundary router and remove the Unifi router. Run the Unifi application to program your residual UniFi devices. More work and problem solving required but if you want to be a competent network engineer you need to be able to solve such problems yourself.

@stephenw10 That was what I thought. Will try to hook up an VLAN aware switch and try that out. BTW Thank you so incredulity much @stephenw10 !

@bmcgover said in USB GPS receiver: The signals aren't overly strong to start with That is a massive understatement. When you look into GPS you find it requires some engineering blackmagic to detect the signals at all even in the best conditions. Something everyone takes for granted these days.

Yeah, 1000000103 is the default block rule. And that is expected behaviour. There are no rules added to the IPSec interface by default, and never have been. The reason ICMP appeared to work in this case is that the outgoing pings opened a state the incoming traffic was able to use. It's possible to get successful pings in that way even without any pass rules present on either end. That can only happen if both ends are testing with Windows clients though because it uses icmp ID 1 for all pings allowing the match. Linux and FreeBSD do not. Steve

@gertjan yes, /usr/local/lib/php/20190902 is the location. I also saw that Netgate mentioned about potential PHP errors in their upgrade documentation: Upgrading from versions older than pfSense 2.5.0 My previous upgrade worked fine with the VPN and Suricata so it might not be the root cause (in fact, this is the fist time I have an issue with the upgrade). I'll monitor this for the next upgrades. Either way, everything is working fine for now. Thank you for checking!

You should also be able to apply the patch to 2.5.0 and then delete the bad cert. You should upgrade anyway though and that patch is already in 2.6. Steve

@rolster said in Routing traffic between remote offices behind respective firewalls: Simple routing table mod for the traffic: e.g. Source 192.168.1nn.0 , destination 0.0.0.0, Default GW (192.168.1nn.254) Source 192.168.1nn.0 , destination 192.168.2nn.0, PFS VPN (192.168.1nn.250) and vice-versa Are you applying that to each HQ client directly then? Or at the HQ router? The MPLS default route at 192.168.1nn.254 is somewhere uncontrollable in the ISPs network? There's no reason why an OpenVPN tunnel between A/1 and A/HQ should not work. And having that would then allow you to route traffic to the HQ pfSense in order to use the tunnel. You could very easily end up with some asymmetric routing happening though. I imagine currently the subnets at each site are part of the MPLS routed network directly? Does each site actually have a firewall/router? Adding pfSense at each site and putting all traffic through it would give you far more control over what goes where and prevent asymmetry but may not be practical. Steve

@stephenw10 I will let you know, thank you for the help! P.S. I've just notice now that I've put the wrong symbol on diagram switchs lol.

Pure routing sounds like the way to go @stephenw10. Thanks!

@stephenw10 cheers for the suggestion. I haven't tried that! but can do next time it dies and see what happens.

@stephenw10 said in Gigabit internet PPPoE and pfSense: @riahc8 said in Gigabit internet PPPoE and pfSense: could I install pfSense there to rule out any issues???? Yes, it's a good test if you can do it. Yeah, I havent used it and/or turned it on in a while. Ill install pfsense on it when I can and see how it performs there.

@stephenw10 said in Upgrade to 22.05 has killed my pppoe WAN: You can fetch it and install it: So fetch it in advance and install it manually if required. Thank you, @stephenw10 ! That saved my day. The upgrade from 22.01 to 22.05 went wrong again the same way. I transferred the mpd then to the machine, disabled and re-enabled the WAN IF and I had internet connectivity. Running the upgrade option (13) via shell then again and it updated the remaining stuff. It's in final startup now and I hope all will work ;-)

The states might be closing quickly. You would need to be trying to open a connection to the server whilst checking the states. Do you see any blocked traffic in the firewall log also? If there is another route to the server and that works is the server using pfSense as it's default route? If not you probably have some asymmetric routing. Steve

That is the default setting in pfSense. There is no SIP ALG unless you install the siproxd package, which you shouldn't. All ports are open outbound for any devices on the LAN. So unless you have added firewall rules to block traffic it should be allowed. However I would check the firewall log when it fails. I would also check Diag > States to see what states are open to/from the ATA191 IP and what changes after you reboot and it starts working again. The only thing that pfSense does differently to many (most?) SOHO devices is to set a random source port on outbound connections. Some services, including VoIP, object to this (VoIP and NAT are mortal enemies! ) requiring a static source port rule to be set: https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html#disable-source-port-rewriting Steve

Shouldn't make much difference. What latency are you seeing across the tunnel? What hardware are you using? What speed do you actually see outside the tunnel? Use the WAN as source. The last thing you want is a VPN connecting out across another VPN, either way around. Steve

@Cool_Corona Please contribute constructively. Thanks.

@stephenw10 said in OpenVPN + WireGuard breaking DNS resolver.: No worries. Let me know if that helps. There easily be more interactions happening there based on the connection timing. Steve It works !! I removed the monitoring IP`s on both gateways, and i enabled "Do not create rules when gateway is down" in System / Advanced / Miscellaneous. After reboot, both WireGuard and OpenVPN clients connected as usual and all subnets are going through their designated gateways. Once again, thank you @stephenw10 !!!

Probably a DNS issue. The error the client is showing is probably saying exactly that....