@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.