@eribob Wow, really good numbers, congratulations!

@wisepds 11 days and where is the comunity?.. i know a lot of people lost conectivity when wan ip change and your DDNS ip change. Can anybody tell me what must i do? Is there a script for pfsense that fix this.. i don't know... for example via script + Cron every 30 seconds? Please Help!

I am not really that familiar with the 2100, but my undertanding is that the VLAN ID's used internally for the switch, are only internal to the switch unless you tell it otherwise. So you can use e.g. VLAN 4081 for WAN and 4082 for OPT1 and that will maintain them separated in the switch. Then in the interface setting you just repeat what you already did for your WAN connection earlier. And since they are separated you are free to reuse the same VLAN ID 7 without any conflicts....

@w0w no, it's a carrier problem (currently). Either a node is failing or a customer on the node is sending noise back to the node, causing high packetloss everyday between 2p & 4p. I can set my clock to it almost....but it causes pfSense to flip sheep with the failover. I had a truck rolled today, showed them the latency logs from 2 different addresses in the neighborhood. They agreed it was a "them issue".

@egates Cool, glad that you got it working!

@boulesmoonraker Thanks guys. I was able to get this to work with your advice, but unfortunately wildcards are not supported in the IP Alias list as @viragomann pointed out. It would be a cool feature if pfSense did support wildcards for hostnames. With some packet captures I was able to determine the handful of hosts I needed to add to the list and it worked like a champ.

@Shinigami So configure the UNIFI properly to accept access from its WAN facing iterface.

@johnpoz I actually tinkered with this, it didn't seem to help unfortunately. I believe what I'm going to do is get a small managed switch and put it in front of the pfSense VM, I've seen a few people say that did the trick. Thanks for the reply friend!

@saint90 I'm guessing you could use their ASN's to have pfBlocker create an alias that can be used in a policy rule doing what you want. That rule would then route all traffic going towards any of the IP's they use, via WAN2. Not sure if that would affect and create any problems with online gaming though. As some traffic is p2p and other go via their platforms. A bit more "brute force" perhaps but a quick fix is a policy rule that simply puts all traffic from the devices that run any of those games on WAN2... Question though, do you actually need to use the two WANs for loadbalancing? Or is it primarily failover that is of interest??

Thanks for the fast responses, better than my connection :) Sadly this means I need to get a different box and install pfSense, the 4200 is very expensive for my needs, Will start looking for generic boxes with that level of specs to build my own.

@adamw Now that I’m by a PC, bwlimit is Kbytes per second. Somewhere I also recall that rsync doesn’t necessarily limit at a constant speed: “Rsync writes data over the socket in blocks, and this option both limits the size of the blocks that rsync writes, and tries to keep the average transfer rate at the requested limit. Some “burstiness” may be seen where rsync writes out a block of data and then sleeps to bring the average rate into compliance.” https://www.cyberciti.biz/faq/how-to-set-keep-rsync-from-using-all-your-bandwidth-on-linux-unix/ That page also has other possible solutions. Or as I mentioned, traffic shaping to make this low priority traffic.

@viragomann do you have layer one? (Link lights)

@rune-san said in Shutdown WAN when Reaching Data Cap?: @Gblenn All of AT&T's DSL/Fixed Wireless/Fiber plans below 100Mbps plans have Data Caps. Same with Cox cable internet. I agree it's not common when looking across say, a large part of the US, but for those that are in that location, it's probably the only choice they've got. Hmm, makes sense when they offer connections over a shared resource like FWA, but fiber (or cable)... seems like a way to force people to pay extra, just because they can. Or to force people to abandon costly (for the operator) DSL. Globally though, quite unusual...

@oscar-pulgarin said in Problem routing: When I do a traceroute from the ip 10.10.10.1 it follows the following path: 10.20.35.1 10.250.1.2 So I assume, that the Sophos is either the default gateway on the Forti or there is a static route in place on the later for 192.168.0.65. Additionally you need two static routes on the Sophos for this to work. One for 192.168.0.65 pointing to 10.250.1.2 and one for 10.10.10.0/24 pointing to the Fortinet. AND you have to configure an IPSec phase 2 to connect 10.10.10.0/24 and 192.168.0.65, presuming none of the involved devices does masquerading the traffic.

@martincutts said in AWS S3 Sync Not Working: Hi everyone, I wonder if anyone has come across this issue before? Background We have well over 100 AWS accounts which we setup for customers who run our ERP software from within AWS. For a number of years we have been using a Vyatta instance for VPN connectivity when the customer has multiple branches, which is a lot cheaper than multiple AWS VPN's. The issue is that the old Vyatta doesn't support IKEv2, so I looked for a replacement. Initially I looked at VyOS, which did seems to work OK apart from a few niggles, but then chose to adopt pfSense due to better OpenVPN support. The Issue For one new customer, I'd already setup a VyOS device which was working just fine, and then replaced it with a pfSense device which all seems to be working fine, however. We have a script which backs up the PostgreSQL databases, and then uploads the backup files to an S3 bucket which has versioning enabled, so we can go back to various days in the event that historic data is required. For some reason the 'aws s3 sync' command which uploads the files has stopped working. It was working just fine with a VyOS and Vyatta, and stopped working on the day I replaced it with a pfSense. This is where it gets interesting as when you run the backup script manually (as the postgres) it runs just fine and the files upload, but when it runs via a daily cron job it doesn't upload :-( Before you say it, this is not a pathing issue as the same script has been running OK for years on multiple systems. The only change is the replacement of the VyOS with a pfSense. I know for a fact that if I replace the pfSense back with the VyOS it will start working again. So my question is, what is causing the problem? I've been looking at this for days and getting nowhere! There is nothing in the Firewall log to suggest it's being blocked, but surely if it was a FW issue it would be blocked when running manually? At some point we will need to replace all the Vyatta instances (over 100) with pfSense devices, so need to know these are as solid as the Vyatta appliances they will be replacing or I need to go back to a VyOS? Thanks Hi there, It sounds like you're encountering an issue with the 'aws s3 sync' command after replacing a VyOS device with a pfSense one in your ERP software environment on AWS. The script runs successfully when triggered manually but fails to upload files when executed via cron job. This behavior suggests a potential interaction issue between pfSense and your script execution environment. While firewall logs show no blocking activity, the change to pfSense might be affecting how cron jobs or script permissions are handled. You might want to check how cron jobs are configured on pfSense, ensure proper permissions are set for the script execution, and verify any networking or routing settings that could be impacting the AWS S3 connectivity. Considering your scale and the need for reliability across multiple instances, exploring configuration nuances between Vyatta, VyOS, and pfSense could provide insights into resolving this issue effectively.