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:

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.

Wow, that seems to have made it work, thanks a lot. I'm still not able to disable ipv6 though, which is strange as I've also disabled it in the gateways section, but even greyed out it is listed as default. Glad it's working at least partially how I'd hoped though - much appreciated!

@robtoronto I was looking for just the same solution. One ISP is fast but has a data cap and charges a lot after it has been reached. The other ISP is good enough for most things and has no data cap. When I reached my data cap, or perhaps got to within 90% of it, to have pfsense close down that ISP until the next billing month. Thank you for asking about this issue. It saved me trouble.

Before doing that, see if you can boot normally and set /var to 1GB. You have plenty of RAM. If that works, try reducing to 768, then 512. Maybe works. I had no trouble running PFB on a RAM disk, but every time I rebooted, the /var PFB data got wiped and I either had to wait until the next update or force it. Finally went back to /var on SSD. After all, the whole VM is on SSD anyway...