Access Point What's the point of doing it?

Ok. Thanks for the response. I will try it.

@SammyWoo:

@H20FRKS:

SammyWoo, are you saying building a pfSense server with better hardware will not resolve the through put issue I have?

Just the opposite.

Great thanks! I will continue my efforts to understand pfSense better and work on building a server.

Hi Steve,

I fully support your statement. Do not upload files to your firewalls from an unknown sources.

The driver was compiled on freeBSD 11.1 amd64 release.

Kind Regards,
Nick

I was able to get back into the router after setting my static IP address (and then unsetting it afterwards).  I was able to restore my router using a backup to the point BEFORE I tried to implement OpneVPN.

This issue is resolved.  Thank you all for your help.

Reflashed the BIOS to 4.0.12.

Ran a memtest for a week, 0 errors.

Stopped the memtest this morning. Let PFSENSE boot, withing 5 minutes it crashed. Below is the log in the pastebin link.

https://pastebin.com/hHSnpnmg

@stephenw10:

If you have Gold membershiop or Book access then:
https://portal.pfsense.org/docs/book/usermanager/external-authentication-examples.html#active-directory-ldap-example

Otherwise there's troubleshooting tips here: https://doc.pfsense.org/index.php/LDAP_Troubleshooting

Steve

Yes i Have , i found it

Many Thanks Steve

USB Ethernet is notoriously variable. Usually not too much we can do about that other than swap it out.

Try increasing the number of available php processes. In System > Advanced > Admin Access set 'Max Processes' to 4.

That may resolve it if it's something temporarily using resources or it may just increase the time between issues.

Steve

Hi,

the modem isn't the source of the problem. Since it doesn't handle the pppoe session the settings for MTU are greyed out.

Here's a snippet of my pfsense config file:

        <ppps><ppp><ptpid>0</ptpid>                         <type>pppoe</type>                         <if>pppoe0</if>                         <username>myusername@netaachen.de</username>                         <password>youwontbelieveit</password>                         <provider>netaachen</provider>                         <idletimeout>0</idletimeout></ppp>                 <ppp><ptpid>1</ptpid>                         <type>pppoe</type>                         <if>pppoe1</if>                         <ports>vtnet0</ports>                         <username>myusername@netaachen.de</username>                         <password>youwontbelieveit</password>                         <provider>netac</provider></ppp></ppps>         <interfaces><wan><enable></enable>                         <if>pppoe1</if>                         <spoofmac></spoofmac>                         <ipaddr>pppoe</ipaddr>                         <ipaddrv6>dhcp6</ipaddrv6>                         <dhcp6-ia-pd-len>16</dhcp6-ia-pd-len>                         <dhcp6usev4iface></dhcp6usev4iface>                         <mtu>1492</mtu></wan> [...]</interfaces>

What's REALLY weird is that the password I find in the config is different to the one I find in my tcpdump/wireshark recordings. WTF? How can that be?
Session is coming up fine though.
What I haven't found is some RFC explanation about how MTU is being negotiated.

This is what my interface is saying btw:

pppoe1: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1442</up,pointopoint,running,noarp,simplex,multicast>

Ping6 seems to verify that, since 1442 - 40 (IPv6) - 8 (ICMP6) are actually 1394 which is the maximum packet size I can ping6.
Confusion starts to grow. :-\

Edit:
I took a closer look at the tcpdump and what I found is that the Router Advertisement is saying 1442. Why would the provider want to do this? It looks like a faulty setup Router Advertiser to me.

wireshark_pppoe.png
wireshark_pppoe.png_thumb

I asked about this just recently..  https://forum.pfsense.org/index.php?topic=145261.0

and using openvpn seems like something people would expect you to use from home-to-work. (but that is already setup by our sysadmin)

So I'm guessing your asking how to setup this - because you do not have this feature today.

Check out this: https://www.ceos3c.com/2017/04/10/configure-openvpn-for-pfsense-2-3-step-by-step/

Well, you have no choice but to VLAN from something to get the Wireless AP behavior you desire. But that does not have to be done on pfSense. A switch could do it. pfSense would have two physical interfaces to two untagged ports on the different VLANs in that case. But why not just VLAN it?

If you don't want to mix tagged and untagged traffic on a physical interface, don't. Just leave the untagged interface unassigned.

Thank you for your response. I will try and keep notes on when it occurs throughout the day tomorrow and see if anything odd is in the system logs.

@viragomann:

ping and traceroute maybe do well. ICMP is a stateless protocol. The problems with that come if you establish a stateful connection.

So I'd try one of the suggestions.

OK, thanks for bearing with me! That one got through, I can just about picture how that makes a difference with how things are flying around.

@muppet:

I would check with your ISP and see if they have hard-set your port to 100/Full
Maybe the pfSense is trying auto and, seeing nothing, not bringing up the port.
And the switch, not seeing auto frame either, might be defaulting to 100M half-duplex, thus causing all the frame drops/problems.

This really sounds like an Ethrnet problem, nothing to do with pfsense itself.

PfSense works just fine, so it's not the problem.  The problem will be your Ethernet card, the drivers or similar.
Try and do some diagnosis to see what speed and duplex the port is coming up at, especially when connected to your laptop (is auto-neg being used or not?)

Thank you!
It really was something wrong with ISP's port. It was set to auto, but still didn't work correctly, so my connection was regularly jumping through different modes-speeds and getting big error rate. They just changed the port, and now everyhing is perfect.

They would never do anything if I said them it's pfSense or any incompatible router, but they couldn't reject the issue with just switch.

@stephenw10:

At layer 3, yes (probably). At layer 2, maybe. At layer 1, nope.

The reason it's a good test to put an unmanaged switch between your WAN interface and modem is because it can show up issues exactly like this.

If your modem is set to 100Mb full duplex rather than auto the switch will likely connect to that fine and will also connect to the WAN interface that is set top auto negotiation fine. But without it you get a default connection which is often 10Mb half duplex, horrible speeds and huge error rate.

Ethernet hardware should all conform to the specs and be compatible but that is not 100% true. Some cards will refuse to establish a link or continually flap up and down for no good reason. I have a Realtek card here that behaves exactly like that but only when connected to one switch I have.  ::)

What is the NIC in the Win7 PC?

Can you see the link speed/duplex on the switch in each of these cases?

Steve

Thanks for the info. Yes, they seem to implement things a bit differently. My Realtek NIC refused to see that broken connection at all, while Broadcom's one somehow worked fine on that… Also that Realtek only accepts it's hw mac, while Broadcom don't care.

Can't be done. There is no way to obtain a list of IP addresses for a wildcard domain. You would have to resolve every possible hostname which would be infeasible if not impossible.

One of the other packages, such as pfblockerng might have a pre-compiled list you can use. Not sure.