OpenVPN is probably easiest to setup for this from pfSense but Tailscale should work.

Yes, it's probably a missing firewall rule somewhere.

shellcmds don't go in the interfaces config like that. They would never get run there. They should be in the main <system> section, you will see the package has added them there.

@ggpf You can just add it:
https://docs.netgate.com/pfsense/en/latest/interfaces/configure.html

I have several residential clients, and I have been promoting the Netgate appliances to them. My selling point has been that, unlike with consumer-grade equipment, their Netgate devices will not become insecure, as long as the latest pfSense version is installed. My most recent client has a Linksys E1200, which saw its last firmware update in 2018. Furthermore, there is no guarantee that that firmware update fixed all known vulnerabilities. With pfSense and its open source nature, I have much greater confidence that security holes are discovered, and are fixed soon enough thereafter.

If a client who now has a Netgate 1100 today upgrades to a 10 Gbit/s connection (available, where I am 💪💪💪) at some point in the future, his connection will still be safe, but he will have to upgrade his equipment to take advantage of that bandwidth. My selling point always is security and a little bit self-serving in that I am familiar enough with pfSense to provide the features he requires.

I usually set up separate subnets and corresponding Wi-Fi SSIDs for the family, for guests, and for home automation. One client I set up with a separate SSID for his kids and had the access point they connect to switched on and off with a smart switch, so that the parents can enforce bedtime. I doubt that consumer-grade hardware makes that as convenient as that setup ended up being.

@johnpoz yeah sorry just a bit worried of sharing information I will PM information over to you if that’s okay. Will be later on this afternoon.

Regards.

You'd have to reassign the interfaces but otherwise yes. If you have any complex VLAN/switch port setup in the 3100 that wouldn't apply in a 4100 of course.

@stephenw10 said in DHCP from ISC to KEA - any side effect?:

until you reboot

Rebooting pfSense ? I didn't find a reason to do so, so I don't do that 😊
But frankly, yes, if it I have to reboot, I'll activate DHCP ISC for a moment, then go back to Kea, and I'm good.
My LANs DHCP leases are all "MAC static".

Yes. Please see discussion in the NUT support thread.

@Judge_of_Death yeah that would scream asymmetrical problem coming from a vpn client, that has some vpn tunnel IP..

Sure you can get to 10.10.10.50 pfsense would route your traffic there.. But that box then says oh some 10.10.200 (your tunnel network as example) hmmm, no route - send it to my default gateway (x.x.x.17).. pfsense says wtf is this, I have no state to allow this return traffic..

But if you would of sent the traffic back to 10.10.10.254, pfsense would have a state your good.

So you can work around this couple different ways, either source nat the traffic from your vpn going to 10.10.10.50 so it looks like it comes from 10.10.10.254 and not your tunnel network IP of your vpn client.

Or you can add a route on this .50 device that says hey if you want to talk to 10.10.200 (your tunnel network in my example) send it to 10.10.10.254 and not your default gateway. You wouldn't be able to use the x.x.x.22 address then to access your multihomed device.

@ndemarco I have never ran into such a device, that would be horrible on the makers of whatever device - and they should hopefully have fixed that right after release of such a horrible choice. maybe in your host name section if you were trying to add the host name with a . in it

Normally the thing just either asks for the full fqdn, or it breaks it out to host and domain. In the case with host and domain it would be

name: host
domain: sub.domain.tld or sub.other.domain.tld etc..

@dieggocampos I had so many issues with ipv6 and Google trying to force it on me, my isp is ipv4 only so I had to manually disable it.

@VerticalTechnik said in Should I upgrade 2.5 to 2.7?:

But what can go wrong when updating?

release notes:
https://docs.netgate.com/pfsense/en/latest/releases/

and:
https://docs.netgate.com/pfsense/en/latest/install/upgrade-guide.html
https://docs.netgate.com/pfsense/en/latest/install/upgrade-guide-versions.html

@stephenw10 said in Cant Login webGUI after Restart:

You shouldn't need new hardware. 😉

You can reset the password from the console menu if required.

Steve

Did so and now working again.
Thx to all for the reply, much appreciated.

@stephenw10 My bad, I was trying to create the gateway directly from the "Add a new gateway" button in the WAN interface, but there are no advanced options there.

By going through the Routing/Gateways menu, I do have access to the option you mention, and I could add the Gateway.

I could then add the "Interfaces" widget without issue on the dashboard !
Thanks a lot for your help ☺

@stephenw10

Wow, so simple, I had not done a reboot and assumed all would work. Killed power and rebooted modem and router together, tada, internet! Thanks!!

@stephenw10 said in where to put hw.uart.console setting so it sticks after reboot:

@gfeiner said in where to put hw.uart.console setting so it sticks after reboot:

show command reveals efi is already in the console option:

console=comconsole,efi

But comconsole is set first and the referenced bug shows that running it unsets the hw.uart value.
So try adding console=efi to loader.conf.local

Bingo. That was it. /efi/freebsd/loader.env is not needed. All that is needed is a /boot/loader.conf.local with these two entries:

console="efi" hw.uart.console="mm:0xfedc9000,rs:2"

In looking at the details and comments of the actual change in FreeBSD 13, it makes sense: https://cgit.freebsd.org/src/commit/?id=525ac1948af8
Their change will specifically unset hw.uart.console if console has comconsole as a value.

For those reading this who may wish to install pfSense on a Deciso appliance like myself, I got the mmio address value for hw.uart.console by inspecting the output of "dmeg | grep uart" while the appliance was running OPNsense.

@flugenblar yeah as long as your browser doesn't bug you every time about the self signed, its not an issue for sure.. Your still encrypting your traffic..

Its only a few seconds to setup, and once you setup a browser to trust you can issue signed certs for all your different things that might want to use a cert. switches, printers, your nas gui, my unifi controller software.. etc. etc.

Use to be better when the browsers also didn't complain about lifetime of cert, use to issue them for 10 years and never had to think about it again etc.. But now I think like 398 days is longest you can issue one for before browsers bitch at you about it.

I don't believe that's possible. Only kernel mode crypto operations can use SafeXcel, so IPSec or OpenVPN DCO.

Check the MAC stats in the sysctl output. The errors there are shown by type. For example in igb:

[2.7.2-RELEASE][admin@t70.stevew.lan]/root: sysctl dev.igb.0.mac_stats dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.mac_stats.tso_txd: 0 dev.igb.0.mac_stats.tx_frames_1024_1522: 4687 dev.igb.0.mac_stats.tx_frames_512_1023: 2618 dev.igb.0.mac_stats.tx_frames_256_511: 7200 dev.igb.0.mac_stats.tx_frames_128_255: 27786 dev.igb.0.mac_stats.tx_frames_65_127: 75559 dev.igb.0.mac_stats.tx_frames_64: 722390 dev.igb.0.mac_stats.mcast_pkts_txd: 0 dev.igb.0.mac_stats.bcast_pkts_txd: 26 dev.igb.0.mac_stats.good_pkts_txd: 840240 dev.igb.0.mac_stats.total_pkts_txd: 840240 dev.igb.0.mac_stats.good_octets_txd: 68322288 dev.igb.0.mac_stats.good_octets_recvd: 145377581 dev.igb.0.mac_stats.rx_frames_1024_1522: 24579 dev.igb.0.mac_stats.rx_frames_512_1023: 4478 dev.igb.0.mac_stats.rx_frames_256_511: 9296 dev.igb.0.mac_stats.rx_frames_128_255: 6689 dev.igb.0.mac_stats.rx_frames_65_127: 53689 dev.igb.0.mac_stats.rx_frames_64: 1503308 dev.igb.0.mac_stats.mcast_pkts_recvd: 21 dev.igb.0.mac_stats.bcast_pkts_recvd: 785609 dev.igb.0.mac_stats.good_pkts_recvd: 1602039 dev.igb.0.mac_stats.total_pkts_recvd: 3127575 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.missed_packets: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.excess_coll: 0

Yup it's gets added to the config if you make a change to the interface. So I imagine you set the subnet there in the setup wizard and never changed anything since.

Anyway glad that solved it!