So you are authenticating using Radius from pfSense to the Synology device? Does it resturn groups locally correctly? Why are you using LDAP and Radius? Steve

Exactly what VPN type are you using here? I don't really see why you could not use certs signed by another CA as long as the server and clients were both using it. Though I'm not sure I've ever tried that myself, for mobile IPSec at least. Steve

Indeed. If @eiger3970 is seeing this in 2.1 then upgrade! If it's in 2.4.4 then it's almost certainly unrelated to whatevet was happening here and a new thread is more appropriate. Steve

@gboone I preferred the previous spelling. I thought it was more accurate.

Aw, interesting. Yes that file is there. I removed it and the notices have gone away. Thanks!

@HW said in Need help configuring: OK. Enabled the firewall and can ping both 8.8.8.8 and google.com. But still mail isn't working and not possible to reach the Remote Desktop Gateway from outside. Good to hear it's working. Don't forget to backup the configuration this time! Diagnostics > Backup & Restore. I hope you're not using remote desktop into your network without encryption. That's not the best practice.

@viragomann said in Internet only accessible when rules has all interfaces: ti Slap on head - the penny just dropped for me! :) I was, for some reason, considering "WAN network" to imply the next step in the journey to the destination - give access to that and I'm all set. I guess, technically, all I was doing was providing access to any host in the subnet as the IP address my ISP assigns to me :) Not sure what I was thinking but that makes complete sense now and I thank you. Mark

Yeah it pulls in the copyright message and checks it's hash against the message that's stored locally. If it has changed it displays the new message. In this case we wanted to get the survey link out to users so updated the message to include it. Unfortunately the initial link was bad so it was corrected. Some users might have seen the pop-up twice. Steve

@armandelli I doubt it. That would involve reading the contents of encrypted traffic and then looking up accounts. There is no way pfSense could do that.

Same problem here, as johnpoz said, its a problem related to the windows host, in my case, not enough memory. On windows servers if there is not enough memory, RDP is blocked.

@Ralphworth Shouldn't really be an issue if both the LAN and WAN v-switches the pfSense VM connects to are External. Private - Communication between VMs only. Internal - Communication between VMs plus Host. External - Communication between VMs, Host, plus physical network (outside world)

@Gertjan Very well presented, thank you for sharing!

Okay, I re-did everything, the bridging bit, from the beginning and it seems working now. I cannot figure out what different I did this time but glad to see it's working. Thanks for your help @stephenw10 -S

@stephenw10 I have rechecked my NAT rules and it appears it was natting on the Vlan, which was causing a double NAT, which was why it was showing PFsense's Interface address! Thanks for the help anyhow

There is no dedicated menu entry for the OpenVPN client export package, so a user with only that privilege has no way to reach it directly. It works by chance when it's first in the list because that's where users are automatically directed when they attempt to access a page for which they do not have privileges.

Also seeing that. Have poked those in charge. Steve

Thank you for response Steve. The rules are set exactly the same on both pfSense machines. It must be some other problem. UPDATE: I finally got this problem solved. I've reset whole configuration of the 2nd pfSense machine to the factory settings. I've configured all the interfaces & rules again and GRE tunnel is working in both directions now. I don't know what was the casue, but there must have been some mess in pfSense configuration files. I assume that the issue was interface related. I found a guy who had similar issue and he also fixed it this way. Regards Rodak

@jimp My comment applied only to me...there was no guarantee that Snort 4.0 would work with V.2.4.5.

@choder If you have Realtek NICs, I would strongly advise using the 1.95 Realtek driver. The watchdog timeouts are exactly what is known to occur with the Realtek driver built in to FreeBSD. And it's the sort of thing that may seem fine for a while and then bite you. That said, in my experience with this issue, I don't think it would ever survive running 30 mins of maxed out iperf. So you may be fine, but I guess my feeling is that you would only stand to benefit by loading the 1.95 driver.