Of course FreeBSD supports multiple devices. 🙄
pfSense is a firewall/router and was never intended to support multiple storage devices other than as a drive mirror. That's not to say it can't be done. If you search the forum there are multiple threads with users describing their own solutions for making it work. However all of them operate outside the default pfSense config such that if you need to reinstall and restore for example you need to be sure you can restore any custom scripting you added.
It's far simpler to just install and boot from the larger drive directly.

Steve

You could set the values very high since the other WAN is 100% down. So, for example, 1000ms latency and 80% packet loss. Really though you should tune the values to your connection. That's difficult to do if the cell is in very high use but you just want to avoid false alarms whilst still alerting if it goes down entirely.

Steve

@stephenw10 Don't worry about it. It was Firefox with an adblocker but I hadn't seen that behaviour before with any other pfSense field. I'm not touching the pppoe config now that it's working.

@stephenw10

Aug 1 07:52:23 check_reload_status 402 Linkup starting bge1 Aug 1 07:52:23 kernel bge1: link state changed to DOWN Aug 1 07:52:24 check_reload_status 402 Reloading filter Aug 1 07:52:26 xinetd 76035 Starting reconfiguration Aug 1 07:52:26 xinetd 76035 Swapping defaults Aug 1 07:52:26 xinetd 76035 readjusting service 6969-udp Aug 1 07:52:26 xinetd 76035 service 19000-tcp deactivated Aug 1 07:52:26 xinetd 76035 19000-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19001-tcp deactivated Aug 1 07:52:26 xinetd 76035 19001-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19002-tcp deactivated Aug 1 07:52:26 xinetd 76035 19002-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19003-udp deactivated Aug 1 07:52:26 xinetd 76035 19003-udp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19004-tcp deactivated Aug 1 07:52:26 xinetd 76035 19004-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19005-tcp deactivated Aug 1 07:52:26 xinetd 76035 19005-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 Reconfigured: new=0 old=1 dropped=6 (services) Aug 1 07:52:27 check_reload_status 402 Linkup starting bge1 Aug 1 07:52:27 kernel bge1: link state changed to UP Aug 1 07:52:28 ppp 41093 Multi-link PPP daemon for FreeBSD Aug 1 07:52:28 ppp 41093 process 41093 started, version 5.9 Aug 1 07:52:28 ppp 41093 web: web is not running Aug 1 07:52:28 ppp 41093 [wan] Bundle: Interface ng0 created Aug 1 07:52:28 ppp 41093 [wan_link0] Link: OPEN event Aug 1 07:52:28 kernel ng0: changing name to 'pppoe2' Aug 1 07:52:28 ppp 41093 [wan_link0] LCP: Open event Aug 1 07:52:28 ppp 41093 [wan_link0] LCP: state change Initial --> Starting Aug 1 07:52:28 ppp 41093 [wan_link0] LCP: LayerStart Aug 1 07:52:28 ppp 41093 [wan_link0] PPPoE: Connecting to '' Aug 1 07:52:30 ppp 41093 PPPoE: rec'd ACNAME "nme-apt-bur-bras252" Aug 1 07:52:30 ppp 41093 [wan_link0] PPPoE: connection successful Aug 1 07:52:30 ppp 41093 [wan_link0] Link: UP event

So either repluging in the WAN or going to Interfaces/WAN and disabling and reenabling the interface brings the WAN interface back online.

I am not really seeing any difference from the failure before, maybe it is the network card. I am planning on building a new pfsense router soon so maybe that will resolve the issue as it does not seem to be a wide spread issue.

@eriksteel Please open a ticket at https://go.netgate.com/ and include the NDI, SN (if it's a Netgate device) and the order # for your renewal.

Thanks!

@the-other Thank you! Yes these are the exact settings I needed. You are the best.

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.