@detox it is being worked on and is, in-fact, the major focus of the next release.

It's less about Plus vs CE and more about the config format.

Look at the table here: https://docs.netgate.com/pfsense/en/latest/releases/versions.html

Note the "Config Rev" column.

You can restore an older config revision to a system with a newer revision but not vice versa.

See https://docs.netgate.com/pfsense/en/latest/backup/restore-different-version.html for details.

Going from CE to Plus there isn't any concern about config items either.

Going from Plus to CE anything specific to Plus would end up just sitting unused in the configuration, it wouldn't be removed in most cases.

@stephenw10
Thank you, Stephen, appreciate it!

Hmm, yes the fact it's ARPing for the LAN side gateway and the gateway is responding but it's NOT in the pfSense table does seem to point at the NIC not passing traffic. At least inbound.

Yet it appears in a packet capture so the driver is seeing it. 🤔

@nick-loenders
Yes, you can do this. But to be accurate, you have to forward a certain destination IP and port to a target IP and port, not domains, pfSense can't see them.

So you forward
81.82.120.21:443 to 192.168.10.11:21443
81.82.120.22:443 to 192.168.10.11:22443
81.82.121.23:443 to 192.168.10.11:23443

OutBound NAT.

The /1 route being passed by the VPN provider is a more precise route than the default route which is /0. So it would be used in preference.

That's likely why you see the DNS states on the VPN interface. That should work.

I prefer to set the VPN client not to pull routes from the server and then add policy routing for clients/subnets I want to use the VPN.

@stephenw10 said in Exceeded input buffer (on reboot):

It could well have ended up with a newer boot loader when starting from 2.7.2. That could explain the difference.

Possibly as I think most times I saw it I had restored from 2.6.x clean install restore and then upgraded. It is certainly an odd error as searching for it exactly yields few results. If it reoccurs I will come back here with a video or screenshot.

@stephenw10 said in Large packet sizes fail to send to internet:

You can use the new Net Installer to install Plus directly if the NDI is eligible.

I had missed that post when it came out. That certainly resolves my concerns once it makes it out of beta. In the meantime it looks like things are stable again and we found the oddities that were causing issues. Thank you for your assistance.

@SteveITS

I'll have to chalk it up to me being super tired yesterday. I honestly did not see that anywhere -- but I've registered now and submitted my comment.

@stephenw10 hahah - that could be staged, but it wouldn't be unthinkable that was a legit conversation... I take it that was some video off his doorbell camera or something.

Pretty funny either way. But more funny if actually legit conversation.

Ok testing here....

There were some threads discussing it. For example: https://forum.netgate.com/topic/187100/serious

Nope that rule would not have allowed an outbound connection. But none of those prevent inbound connections and once the state is open the replies can use that.

However that would require something allowing inbound connection to reach the pfSense VM. So a port forward on the ISP router and another port forward on the pfSense VM to reach the server.

You don't have those as far as I know so if you were able to browse the site hosted on the server coming from some external IP address then the connection must have been coming over the tunnel to Cloudflare. That tunnel must have been created outbound from the server when you had a rule to allow it at some point. I would bet that if you had rebooted the server or pfSense at that point the connection would have failed.

@AlexDesro18 said in TLS Error, reconnecting:

Wan interface it says it's missing rules.

Do you see something like this on your wan?

rulesjpg.jpg

The "wan" needs no rules, but it defaults to having block rfc and bogon.. But maybe he removed those?

rules.jpg

The rfc and bogon are the only rules that would be on your "wan" unless you add something.

I ended up figuring it out by a couple of things. I don't know why the UI was saying up to date, but after running some of the commands and I set the default gateway for the "temp" WAN connection, then the commands started working and the UI started saying update available.

There was some kind of connectivity issue resolving the DNS for the repo's and I don't know why hard setting the default gateway made it work, but thats what happened.

I was able to update to the newest version and the pkg commands work again. Thanks for the consult.

If you need to run HAProxy and pfBlockerNG though I would want a 4200.

Hello @stephenw10

Thank you for you reply. Finally, we solved issue.

Phase 1 disabled was in Ikve1 config mode and VPN IPsec status blocked on Connecting message indicated ikve2

So we reenabled Phase1 with ikve2 + we force disconnect Phase 1 from vpn status and now it's oks

Best Regards

@VioletDragon
MTU is blank on all interfaces, so I assume default / 1500
In so far as I understand OSI, its all Layer 3. Its all firewall rules, no ethernet rules.
No I haven't tried a fresh install. I guess I should do that.

@kjk54 said in Best Network Topology with Current Hardware:

@stevencavanagh
Things are often not what they seem.:)

Very true!