@detox you should be able to edit your first post and edit title with [solved] in the title, add tag.. If you can not - let me know and can do it for you. There might be some restrictions on rep ports or something - but you have 6, I would think that enough?

@crazypotato142 said in [solved] WAN gets IPv6 but LAN can't:

Wouldn't that mean it has the connectivity and with a prefix translation I could use IPv6? Like Teredo or HE.

Imho : don't invest any time in using Toredo. That's a dying concept.
HE (tunnel broker) is something else. I've been using it for years, as they implement a clean and close to perfect, one of the best IPv6 implementations. Their services are not free ! That is, it won't cost you any money, and they even send you a free (yes) T-Shirt when you finish their IPv6 certification process. It's back to school-time-again, and do their multiple choice exam.
They offer a /64 to start with, but don't bother, go for the whopping /48 right way 65535 prefixes.
Your WAN will have a IPv6 GUA.
Downsides :
The POP needs to be close to you.
The connection can be interpreted by the site you visit as some sort of VPN connection (there is a work around available if you use pfBlockerng).
The POPs can be crowed, so the speed won't be stellar.

After clearing the Protocol field in stunnel config, which I had originally set to ldap, saving the change, and restarting stunnel service, executing a connection test from the Toshiba MFD was successful.
And after adding the Google Workspace server entry in the Toshiba MFD LDAP Client settings as a directory/service option (click Server Assignment button, also in MFD LDAP Client settings), Google Workspace directory searches from the Toshiba MFD are working as expected.

@mvikman oh sorry - I must of hit reply on wrong post, corrected ;) thanks

Good idea about redmine, I will look to see if anything in there already - and not make the suggestion

Should be marked as solved.

It's common to have the SWAP as double the RAM size. That way you can dump the full ram to it if required. pfSense doesn't do that though.

@lohphat said in ASN lookup failing with empty files [solved]:

I still think that the failure mode could be better handled and alerted -- the logs indicated empty files, but was it due to d/l failure or the server returned an empty file? Something should throw an alert if possible.

Ofcourse that could be a good Idea!

yeah, I found this thread yesterday on forum.level1techs.com and switched it off, as you said, only to see no difference.

"PPP is weird if you’re used to LAN and ethernet addressing. There’s only a single IP on the other side, and peers are originally meant to be symmetrical and not really ask for IPs using DHCP - instead, they’d just announce what IPs they have using IPCP and expect the other side to ack.
Then the whole ip address discovery thing was bolted on, so you as a peer can say, “I have 0.0.0.0”, and ISP can say “no you don’t, you have 2.64.x.x”. ISP peer can still say “I have 10.64.64.0” and you’d typically use that as a gateway.
In your routing tables, you’d have a directly attached 10.64.64.0/32 route via ppp0 as well as a 0.0.0.0/0 (default gateway) route via 10.64.64.0/32 .
[well something along those lines anyway … ppp itself is dying … but you might end up having /32 on ethernet interfaces these days instead]

My PPP log says the same now.

Thanks and best regards,
Mike

@justconfused I can marked it solved for you. So your currently working? While as I said I really don't think this is a pfsense issue - want to help in anyway we can to get you working.

@lolcakes69 you should be able to edit the subject - but I will mark it for you.

I don't know why a testing device acquired an IP address for the Guests VLAN while connected to a wireless network associated with the IOT VLAN. I tweaked subnet/VLAN settings a little, but still very similar to the settings as described above. The testing device now acquires an IP address in the expected subnet, when connected to the IOT wireless network, so I guess that problem is resolved...
Even after the device acquired an IP address in the expected subnet, it still had no Internet access. After adjusting outbound NAT, this too was resolved.

I know this thread is old, but it helped me with my WAN uplink speed negotiation issue I experienced after updating my 2100 to 24.11.

Sometimes the obvious is the easy solution. After the 24.11 update, my WAN was set to 100BaseT. I spent at least an hour trying to figure this out, rebooting everything under the sun. Then I came across this thread, swapped out my cable, and BOOM! back to 1000BaseT.

@viragomann That triggered something in this tired brain. :)
I want to access and reconfigure the device (I'm not it's original admin) with IP 10.0.5.251 for a different subnet. The device is statically configured and from a previous packet capture, it appeared that it is configured for a default gateway of 10.0.5.1. After changing the virtual IP to 10.0.5.1, I can ping/access the device.
Thank you!

It's a known issue and fixed on 2.6.0/21.09 snapshots

@stephenw10 Thank you very much Steve for the info, I will take it in account.

You can only choose a switch port on one interface as you found. If you leave unset it will use the actual VLAN status which takes it's state from the parent interface. In this case though that's the in internal port which is always UP.

No, there's no private VLAN type function. That would need to be on a switch where hosts are connected directly.

Steve

@teamits

Thank you, Steve, you somewhat pointed me in the right direction.
The location of the events are located here:
Applications and Services Logs > Microsoft > Windows > DHCP-Server

I checked and I couldn't find the culprit, but there's a DHCP server log file here:
%windir%\System32\Dhcp

The log file revealed the following error while a client was asking for an IP and the OpenVPN tunnel was on:
"Packet dropped because of Client ID hash has mismatch or standby server"

Upon further search, it turns out that the Active Directory DHCP server on Site A was trying to contact an AD DHCP server on Site B that once was part of the AD Domain of Site A, but since was removed from, but some more cleanup was necessary on AD Site A to make it stop trying to contact that orphaned AD Domain Controller. The issue has been resolved, all clients are able to obtain IP #'s from Site A.

Thanks so much for the hint.

Stay safe my friends.

SuperVertrix.

@apsis-im You are welcome, enjoy :)

@herman

You should be able to edit the thread title and tag - if not I can do it for you.

Thread marked.

@viragomann Awesome, thanks again !