@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.

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...

@johnpoz Working like a charm. Thaaaaank you! I basically just had to click Hybrid outbound and save. Then Just add 1 more mapping for my new .11 subnet (just duplicated the original mapping that was already there)

I have a similar setup only with unifi switch and not edge switch and unifi APs I have a VLAN 20 on my setup which is up and running which I configured last night. Your Network configuration however is different. I selected VLAN only since pfsense was handling all my DHCP functionality. I see in your Network setup VLAN only is greyed out and says USW required (which I don't know what that means). In terms of DHCP mode, have you tried just setting it to None. Did you setup a DHCP server on pfsense for the LAN within Pfsense. I terms of your Edge switch, it seems like you've setup your trunk port appropriately (I would guess - I've never used an edge switch).

A different site's connection suffers from LCP timeouts on a regular basis, possibly caused by VDSL resyncs due to changing SNR, though that's just a guess from occasionally seeing the negotiated connection speed changing. This particular site appears to be the worst behaved, though it runs the same hardware and almost identical configuration as my home connection (i3-7100 Gigabyte Brix, Cisco 3560CX & Draytek Vigor 130). A third site has a very stable PPPoE connection which runs for weeks at a time apart from occasionally where it all goes haywire; many LCP timeouts / reconnections within minutes and this very quickly causes the issue.

Hello, I have the same issue here. I'm using pfsense 2.4.4. Being in the pfsense network I have access to the standby node without any problem. Trying to access the standby node from a different network, https access become unresponsive. cmouse have you found a way to overcome this issue?

@jimp Not a brower plugin. However, I did clear browser data which resolved the problem. Menu>More Tools>Clear Browsing Data>Advanced>clear all except saved passwords, for all time. Chrome works now.