@mcury thanks let me try

Take a screenshot and drag it into the message window. [image: 1562060746874-screenshot-2019-07-02-at-10.45.27.png] [image: 1562060761436-screenshot-2019-07-02-at-10.45.00.png] [image: 1562060810711-screenshot-2019-07-02-at-10.43.50.png]

New update on my own experience. We had a storm in our area take out a bunch of trees and we had a momentary power outage. Coincidentally (or not) a few hours after this, my monitoring IP on my ISP's network decided to stop responding to pings completely. This is after months of doing so reliably. My traffic was still working since I disabled automatic failover due to issues I'm having with my backup gateway (another story). But long story short, go with @NogBadTheBad setting of using Google DNS (8.8.8.8) for the monitor IP. One way or another Google DNS should respond to ping reliably. In my case, I think my ISP may have routed traffic through a different path, maybe due to the storm taking out the part of it I was trying to ping? I have no idea but it was very coincidental.

@SipriusPT said in How to block IP conflicts automatically: There are devices where NICs needs to be reconfigured manually in production site, and also some computers need to have administrator rights to run certain types of programs. While that certainly used to be the case, many programs that require those rights now ask for them. You then have the needed rights in that app only. In the Linux world, we know better. We normally run as users, not root. While some apps require root privilege, they prompt for the password. It's very rare to actually log into a system as root. In my work, I have often had admin rights, as I needed them to change network settings, but that sort of thing should be limited to only those who understand the risks.

Yup testing to the firewall using iperf3 at those speeds will almost always be bad. pfSense is not tuned at all to be a TCP endpoint and the iperf3 version in pfSense/FreeBSD seems to most give worse results anyway. It's is however still a very useful test at 1Gb or below. If you're seeing 20Mbps downloads at clients behind the firewall you can test from the firewall to the client and from the firewall to some public iperf server and quickly prove where the problem is. At 10G it's useful for proving the connection is good only. You will never see 10Gbps to/from the firewall directly. At least not currently. Steve

If your cable 'modem' has a firewall function it's probably a router and has a dhcp server. Enabling that is probably easiest. Steve

Hi, I have this same problem with Telstra SIP and pfsense. Outgoing calls work but incoming calls don’t work. Packets seem to get to the WAN interface of pfsense, but go no further. I will try another firewall in the next few days to confirm that it is indeed pfsense that is causing the issue. Then I will go back to pfsense. Tried just about everything I can think of. Cheers Chris

I was looking at the AC LR https://store.ui.com/collections/wireless/products/unifi-ac-lr . it says it only consumes 6.5w if i am reading the specs correctly so the unifi switch should be enough. I think one ap should be enough for the house as it will be in a central location.

@terpfan1980 said in Unable to access Internet from virtual network: Back to update... a day or so after the discussion above, I was able to resolve the issues that I was having. My best guess is that the issues that I was having related to my flipping the switch within pfSense to "Turn off the Firewall". Turning off the Firewall seemingly also turned off the NATting that I would have been relying upon. Seemingly: Disable Firewall Disable all packet filtering. Note: This converts pfSense into a routing only platform! Note: This will also turn off NAT! To only disable NAT, and not firewall rules, visit the Outbound NAT page. Related, I had created "Any to Any" firewall rules, but then screwed up and had them only for TCP, and not for Any protocol. With the rules changed to "Any" protocol, and not just TCP, things worked as documented (loosely documented, but with the pictures that were seen above, along with others) and the traffic flows as expected, from vlan to vlan, and from the vlans out to the internet as expected and desired in my case. Loosely documented: https://docs.netgate.com/pfsense/en/latest/book

The main system log can be found in /var/log/system.log but that are in a circular format. https://docs.netgate.com/pfsense/en/latest/monitoring/working-with-binary-circular-logs-clog.html Steve

Adding that outbound rule should not affect normal traffic from internal servers at all. Seeing blocked FIN entries like that is not necessarily a problem: https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.html#troubleshooting-blocked-log-entries-for-legitimate-connection-packets If you were seeing asymmetric routing problems I would expect to see blocked traffic on LAN also. Steve

Yup or create the Limiters via the captive portal since I'm pretty sure you're using that. Not sure how Open your Wifi is at this point! Steve

Thanks! Tonight the issue is gone on both W7 computers. Last night, I installed a new cable modem which would seem unrelated to the gstatic issue, but it was an unusual event. Malwarebytes never found anything on either computer. This is not my favorite solution path, but I'll take it for this evening.

Did you try the mailreport package? Steve

Support subscriptions are sold on a yearly basis only. For those who need help but elect not to get a subscription, we have multiple resources available to the public/community (including this forum) where questions may be asked. Answers are provided by the community at no cost.

The internal names, wan and lan, are just that, internal. You can rename them. The only thing that is hardcoded is that the anti-lockout rule is on the second interface and cannot be moved. It would be hard for us to change that at this point as so many users are expecting it. Steve

you should insist with your help desk. tell them to call this adrianc and suggest them to install/check php mcrypt this can't be a pfsense box problem did you try with your phone with 3g/4g/lte connection or only wifi ? if it does not work with your cell phone service provider you have proof it's not the pfsense

Ah, that would do it! I would have suggested that but in your screenshot above you already had an allow all rule on the OpenVPN interface that would have passed that. The first version of pfSense that supported the SG-1100 was 2.4.4p1 and the differences to p3 there is minor. It definitely would not have helped here. Steve

@akuma1x the PoE switches are serving Aruba WAPS as well as VoIP phones and cameras. The switches will not be maxed out maybe 20% utilized for each one.