That CPU should pass 1G easily. Unless, perhaps, it's paired with bad NICs. What do you have there? At the command line run top -HaSP whilst testing the throughput. Is either CPU core at 100%? Are you running packages? Testing over VPN? Steve

I have no numbers for that. As far as I know there have been no arm AWS builds and no plans for any as of now. Let me see if anything is planned internally....

Testing to or from pfSense directly will always be slow. Especially on an APU where it's pushed to route 1Gbps anyway. Running iperf itself uses significant CPU. What do you see if you run iperf between different internal subnets with hosts in each? Steve

You are using BGP to add the routes over IPSec right? If it's always sending traffic across that then it's becoming the preferred route and you need to reduce it's preference so it's only used as backup. How is the BGP over IPVPN setup though. Is that just between your routers or does that also include the ISPs routers centrally? That could complicate things significantly.

Mmm, it was set as DHCP and just never received a response so the status page shows no IPv4 address. Steve

@garric said in Having trouble accessing server's services on my LAN.: I did a quick google search and found on reddit someone with a similar issue and their subnet mask. Could this be something related? If you have mismatched subnet masks between devices in the same subnet then yes that could certainly cause issues. However that seems unlikely here because some services at the same IP are responding. Steve

@johnpoz I will try that, thank you for helping !

@viragomann Thank you very much for the responses!

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