If you can just use different IPs on each container, yeah that pretty much removes the problem.

@sandlake
Hey there,
There might be no queries and localhost has vansihed from listed dns servers, because you changed system global settings from
"Use local dns, fall back to..." to now "Use remote dns servers, ignore local"
...so no more localhost.
:)

Yes, long term, I agree. But if it makes any difference at all then that's clue as to what the actual cause might be.

Otherwise wait for it to fail again and then start digging into what's actually not working.
What does ifconfig show?
Do you see anything in a pcap?

Steve

Yes, that is the expected behaviour:
https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html#default-deny-rule

If you're seeing anything different it's probably either because the ping traffic is not passing the interface you think it is or there are rules on other tabs passing it you have not considered (floating rules, interface groups).

Steve

@swa
Anyway, the masquerading solution would replace the source IP of internal clients and you would loose this information as well with that.

So there is nothing else you can do on pfSense, when passing internal requests over HAproxy.
This will result in asymmetric routing issues, and I think, it's the client, which does not accept the respond directly from the web server, since he sent the request to the gateway before.
However, it should work if client and server reside in different network segments.

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