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!

@dennypage Thanks!

@SteveITS Thanks! Have taken my question to that thread.

@Cobrax2 said in netmap errors since 2.7.x:

Umm, tried to go back to 2.6.x but it seems that the old versions are unavailable for download? Wtf

They may not be there long, so grab a copy quickly from this link:

https://atxfiles.netgate.com/mirror/downloads/

There are 2.6.0, 2.7.0, 2.7.1, and 2.7.2 images posted at the link. Download the appropriate image for you (ISO or USB memstick) and make sure you save it in case you need to reinstall at some point in the future.

Be very careful installing/updating packages with any older version. Be sure you set the repo under SYSTEM > UPDATE > Update Settings to the appropriate version. Failure to do that will result in either the package installation failing, or worse, breaking the install completely by pulling down shared libraries compiled for newer pfSense versions.

@SteveITS Thanks - I wound up finding this...https://forum.netgate.com/topic/184661/unable-to-upgrade-from-2-7-1-to-2-7-2-unmounting-boot-efi-done-failed/18 Which netted out to reinstalling 2.7.0, its configuration which I had backed up and then upgrading to 2.7.2 -which worked.

Happy New year!

Hello!

It is worth noting that the check_dnsavailable function in system.inc that was improved/patched is also used by other subsystems in addition to acb, such as pkg and dhcp. The change may address weirdness in those areas as well.

John