@the-other Thanks. the interface is set to auto... the TrendNet will auto negotiate at whatever is needed up to GB speeds

Bouncing the TrendNet makes everything work...for about 5 minutes... this is driving me crazy

@miracuru
As was mentioned by @viragomann the "Default deny rule IPv(4|6)" logs are normal. Actually they show that pfSense is doing its basic job, which is (by default) blocking all incoming connections to WAN.

You could implement a firewall rule on the WAN interface which does the same thing, but doesn't log the blocks. Enable that rule when you don't want pfSense to record all the WAN blocks in the logs. If you want to start logging the WAN blocks, just disable your rule and the defaults will kick in again.

Also, it may be possible to directly connect the enpf4s0 and enpf7s0 interfaces to pfSense via PCI-Passthrough. This will depend on hardware compatibility, but could be worth looking into; just food for thought.

@azdeltawye that's amazing tech. I had to fix a couple different remote post office sites a couple years ago because lighting hit the telephone line and it shorted out the router's wan cards by way of the ports. They had zero protection on the wan line coming in.

@root1ng said in Can someone explain to me how i can do this ?:

the network card of the motherboard is disabled in the bios

Most of us who use Proxmox reserve that port for Proxmox...makes it a lot easy, and once you passthrough the PCIe NIC in your setup, Proxmox won't have a gateway. Please visit here: https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-proxmox-ve.html

Hmm, I'm not sure how to show that per interface. Possibly some combination of netstat -i and netstat -Q

Issue with the flux capacitor?

@sameerchouksey do you mean these 2 network segments directly connected to pfsense?

Or do you mean their are either upstream or downstream networks that get to pfsense via a transit network?

@johnpoz said in How to keep networks separated:

Seems odd to me that your saying pfsense is getting a public IP - but other devices are getting 192 - this isn't normally how a gateway in bridge mode works.

That's how the att garbage works. Their gateways have what's called passthrough mode. Via dhcp it assigned the public ip to a single device on the lan side.

However, the public ip still remains assigned to the gateway's wan as well. It's a pseudo passthrough mode of sorts, fake bridge.

The end result, customer's device (router, pfsense, etc) has what appears to be a public ip as well as the gateway. As such, the gateway can assign various private ip's to other devices (wired and wireless) connected its ethernet ports and/or wifi ssid. A traceroute behind the customer's router (pfsense or other), will show the gateway ip as the first hop (192.168.1.254) rather than the real wan gateway.

For those of us on fiber in areas not get upgraded to xg-pon, several bypass methods exist which eliminate the isp gateway box entirely. The best is extracting (or buying) the 802.1x certs then implementing them in software using wpa_supplicant. This gives customer full access and control of the network, no double nat, etc. Also a /60 PD for ipv6 vs /64 from the gateway box.

The other methods still rely on the gateway box in one manner or another.

@stephenw10
Just to confirm, if anyone else reads this thread and have the same problem.

Installing a 1G transceiver in the SFP+ port on auto negotiation, did solve my problem, and I'm using it as a WAN interface now on 1G speed.

@noplan said in PFsense 2.5 RC OpenVPN/ExpressVPN problem:

@trikki69 said in PFsense 2.5 RC OpenVPN/ExpressVPN problem:

so your problem is now solved with this

added this to my advanced custom options within the OpenVPN client setup:
;pull-filter ignore redirect-gateway;

brNP

Yep - works great now, no thanks to ExpressVPN support.

Yes, it is official, I am stupid! 🙄

I use limiters and I had them also acting on my LAN interface! I've now updated the relevant firewall rule to only apply when "destination NOT LAN net." With that change, iperf is now back to normal.

Connecting to host 192.168.7.1, port 5201 [ 5] local 192.168.7.2 port 58164 connected to 192.168.7.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 74.1 MBytes 622 Mbits/sec 0 840 KBytes [ 5] 1.00-2.00 sec 70.0 MBytes 587 Mbits/sec 0 1.53 MBytes [ 5] 2.00-3.00 sec 70.0 MBytes 587 Mbits/sec 0 1.70 MBytes [ 5] 3.00-4.00 sec 71.2 MBytes 598 Mbits/sec 1 1.24 MBytes [ 5] 4.00-5.00 sec 70.0 MBytes 587 Mbits/sec 0 1.37 MBytes [ 5] 5.00-6.00 sec 70.0 MBytes 587 Mbits/sec 0 1.47 MBytes [ 5] 6.00-7.00 sec 70.0 MBytes 587 Mbits/sec 0 1.55 MBytes [ 5] 7.00-8.00 sec 70.0 MBytes 587 Mbits/sec 0 1.61 MBytes [ 5] 8.00-9.00 sec 70.0 MBytes 587 Mbits/sec 1 1.18 MBytes [ 5] 9.00-10.00 sec 70.0 MBytes 587 Mbits/sec 0 1.26 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 705 MBytes 592 Mbits/sec 2 sender [ 5] 0.00-10.02 sec 703 MBytes 588 Mbits/sec receiver iperf Done.

Thank you @johnpoz @stephenw10 for the hints and setting my mind on the right path.

@mohkhalifa said in pfSense on ESXi | Best Practices:

problem SOLVED after "Disabling hardware checksum offload"

Awesome. I poked around on a few of mine and didn't find any with that enabled. Mostly Dell hardware here. Good find.