@stephenw10 ... it finally worked. Created new CA/Certificates for Freeradius. Created new CA/certificates for Captive Portal. Finally what actually worked : User Manage : Authentication Server : Selected Radius Server and saved it again. And every thing started working. Kept it under testing (finger crossed)

@stephenw10 no, re-connecting the cable does not bring connectivity back

Yup, you can use /tmp/rules.debug and load that into pf with pfctl directly. You could export, for example, the OpenVPN conf file(s). And the Squid conf file. And that would be most of the config but there would certainly be a load of other work required. Steve

@flybye I made a brief mini pfSense Vlan how2 here , and a few posts forward. https://forum.netgate.com/post/944381 /Bingo

@johnpoz nothing a VM won't solve to see if the driver actually works :)

@johnpoz got it thanks, never thought of that !

How do you have it configured? What is happening? What do you expect to happen? Steve

@bmeeks Thank you sir!

@raymondchauke A little further afield , central and western EU (HU and PT)

You can't test like that using the WAN. The route-to rules will force and traffic sourced from the WAN IP via it's gateway if there is one defined on the interface. You can try sourcing from another interface to check the target is responding to anything outside it's own subnet. The VLAN 10 interface maybe. Steve

This? https://redmine.pfsense.org/issues/9267 Yes, that's been in since 2.4.5. Steve

Yup, it's possible to use TCP. I was more pointing out that rule is set to TCP and that's probably unintentional. I doubt that's the issue though since OP says he's checking his pubic IP which I assume is via ipchicken or similar. That would be TCP anyway. Steve

There are a few ways you can do this. That should work. What I would do is create the PPPoE session on the VLAN in Interfaces > Assignments > PPPs. Then assign the WAN as that new PPPoE 'port'. But either should work. Steve

@stephenw10 Thank you thank you thank you for responding

@ghost-0 Tell that to the thousands of people that bought the switch that said it would do vlans. Which it can't. Pretty much amounted to just running multiple layer 3 on the same layer 2. Any freaking dumb switch could do that.. With zero compensation and no fix.. If you were v1 or v2 you just got hung out to dry.. Oh well I guess - buy version X, we fixed it... I don't go out of my way to bad mouth them.. But there are plenty of other brands to choose from - if people ask me what I would suggest. They are just not one of them.. btw - notice I stated "But current model would prob work as well." I just didn't link to one.. They have a bad track record... Lookup vlan 1 tplink yourself if you don't believe me..

@jerothle Aug 31 19:36:31 dpinger 28952 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr ##.##.##.1 bind_addr ##.##.##.49 identifier "WAN_DHCP " Aug 31 19:36:32 dpinger 35290 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr ##.##.##.1 bind_addr ##.##.##.49 identifier "WAN_DHCP "

I previously setup 3 ring devices with pfSense without any issues. Now, I have two behind it since I moved. You need to rule out that a firewall rule on PF isn't blocking it. I never setup any special ports for Ring devices, but I'm also not restricting outbound traffic - are you?

Yeah, I would also block it without logging. It shouldn't be there IMO but the volume is not high enough to be anything but a nuisance.

Do you see states/traffic on the port forward WAN firewall rules when you try to connect? Or you can enable logging on those rules connections using them will show in the firewall log as passed. Steve

Thanks. I've removed the NTP NAT entry, but alas it still doesn't sync. O. M. G. I feel like such a !@%$#@ idiot. I was collecting screen shots of NAT and firewall status for the thread, and when I went to LAN rules there was a block for NTP on *. It was part of a bunch of rules I had setup to block Alexa at one point when I had Googled what ports it uses, as my friend kept annoying me asking the Echo to play stupid crap. I totally forgot I had done that. Removed the rule and wouldn't you know it, time sync'd :) God I feel stupid lol. Thanks!