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.

On your Nvidia Shield?

Thanks, all! I was able to get the old box up and running for a few minutes, and I downloaded the configuration the normal way. But I did telnet in and browse /cf/conf, just to verify that I could see it, and I did cat config.xml just for fun. So if I ever am in this pickle again, I'll know what to do!

BitNInja appears to be a host based security solution so it can only have limited affect against the attack discussed. Though I have only looked briefly. If the attack is filling the WAN entirely or using all the available CPU cycles at the firewall nothing at the target server is going to help much. Steve

@johnpoz Yes that makes sense. I will give it a go. Thank you for your time on this.

@marvosa said in Gigabit WAN slow download, fast upload: Personally, I think we need more info: Give us the specs on your PFsense box (assuming its bare metal). Also, what kind of NIC's are in it? What packages are installed? When testing with VM's, what hypervisor are you using and what are the specs of the host? Also, how is the VM connected to the network? Does the PFsense VM have dedicated NIC's or is LAN adapter being shared with other VM's? pfSense box is bare metal, it has the following specs: AMD Athlon 200GE 4 GB RAM Intel Pro/1000 PT dual NIC Only a couple packages - acme, apcupsd, open-vpn-client-export, service_watchdog My VM hypervisor is Proxmox 6.1-5. The host is a Cisco C220 M3 with dual Xeon E5-2620 v2 CPUs and 64 GB RAM. The NIC is an onboard Cisco GbE port. I'm testing from a Ubuntu 19.04 VM with 4 cores and 8 GB RAM. The NIC is a VirtIO (Paravirtualized). The VM is on a shared port, but I evacuated other workloads to a sister server before running tests - so effectively the Linux VM was isolated on the Proxmox node. I tried other VM NICs (e.g. Intel E1000, vmxnet3) and the VirtIO had the best performance. I've also tried from other hardwired 1 Gbit clients (a Windows 10 laptop and a Mac Mini) and they yielded worse results than the VM.