@E-I
I'll second that.
I get the same issue.

@viragomann said in splitting a subnet, moving from LAN to WAN:

Yes, if they statically route the lower /25 to pfSense, that could be a reason. But why should they do that?

pfSense has just an IP in this subnet from their view and it would rather make sense to route the upper /25 to it, because this is behind of pfSense.

They might have an error in setting up the VLAN in vSphere.

It is routed correctly to the network port where the pfSense is attached, otherwise all my stuff wouldn't have worked for years.

But it's new and untested in the VMware environment. And it might be wrong. At least I don't have another idea right now.

I am looking forward to their reply.

As far as I understand things, even when the LAN interface in pfSense is configured in the upper /25, it won't hijack traffic going to an IP in /24. pfSense itself has a route to that upper /25 then, but this should must not affect routing in the larger /24 VLAN "above" ...

I even tried that yesterday: triggered a reboot of pfsense and pinged vm_new .180 all the time ... just to see if somehow things change while the pfsense is offline. It would have surprised me, but anyway ... I can only search in my range for now.

Maybe I overlook something, but so far @viragomann hasn't spotted a real misunderstanding, right? thx ...

@cust
You don't need to wait anything.
You can apply this patch via system patches package, just use commit id 62b1bc8b4b2606d3b20a48a853ef373ff1d71e26

Resolved by implementing BGP peering over IPSEC.

Thanks again for the video. It solved my problem.

If anyone bumps into this thread in the future, the static route showed in a screenshot above here was correct, however here's what I did wrong:

On site2 I had set "IPv4 Upstream gateway" in the interface config to the gateway on site1. This makes pfsense NAT the traffic instead of routing it. Here's a timestamped link to the video where this is explained.

I really wish I could do the same here. I get some false positive failovers because the single IP monitor becomes offline, but the gateway is working fine...

Gateway 1 monitor 8.8.8.8
Gateway 1 monitor 1.1.1.1

Gateway 2 monitor 8.8.4.4
Gateway 2 monitor 1.0.0.1

Gateway 3

Then prioritize them and route following this order.

OK, I think I just figured it out!! I didn't have the subnet enabled. Not sure how it happened, but it now seems to be working. I can open the printer's web page!!

Now I can revisit things.

Do you see errors on the parent interface?

You can try the dtrace commands shown in this thread and see if you're hitting some error other than 55 (no buffers).

@4o4rh i am struggling to get policy based routing working on truenas scale.
either i get the situation where non-media vlans can access the jellyfin server on the media vlan (but then the truenas/smb vlan is not accessible, or the truenas/smb vlan is accessible by not the jellyfin vlan (other than from a device on the vlan).

It both cases the non-accessible vlan is appearing on the wrong pfsense interface.

so, it seems truenas is returning via the default route rather than the desired return route

Ignore this

For anyone maybe suffering with similar issues, I went through the guide again and realised I'd forgotten to update the Port VID under Interfaces > Switch > Ports as well as updating the VLAN Tag under Interfaces > Switch > VLANs

Once that was done it got an IP and I could use it as a WAN port.

I add a consideration.

Currently the workaround of changing the global Firewall State Policy has worked, but can it have negative impacts on other things?

It would be nice to have an overall solution to the problem on OpenVPN, maybe with an option like it was done for IPSec. 😊

Bye,
Edo