Just wanted to post an update - while its only been 4 days since I got the new modem so far I have not had any more lockups/dropouts even pushing 200GB per day transfer (I've been trying to run frequent speed tests, several pings, plus normal traffic). Also while I have some channels with "corrected" frames on the modem its only 10 or so at most and 0 uncorrectable (down from many thousands)

On pfSense Status > Monitoring reports only 0.21% maximum packet loss and 0% average and my ping has stayed below 50mS even under load and immediately returns to <10mS when load lets up.

The dmesg output shows no unexpected messages, no flapping, no "watchdog" errors and no "llinfo" errors. It seems stable once again. Hopefully I didn't just jinx it.

EDIT: 7 days now going strong.

@emammadov said in My OpenVPN is hacked?:

TCP:PA

TCP Push Ack. Google it.

http://packetlife.net/blog/2011/mar/2/tcp-flags-psh-and-urg/

Default deny rule IPv4

Default firewall rule to deny all IP4 traffic

Block all IPv6

Block all IP6 traffic

Hardware is

System Netgate SG-2440

I've checked cables etc., I see no packet loss even under heavy load, and throughput through the router (from LAN -> router -> WAN) is normal (~700Mbps, which is likely a limitation on the Xfinity side and not the router).

Yes, the easyrule won't cover that.

Easy to overlook LANnet as source in the rules 😉

Steve

Hmm, curious!

I would definitely try changing the dyndns update period just to be sure it's not related.

I would also check the temperature is reasonable.

Steve

No ideas anyone?

TIA

Greg

@johnpoz When I installed pfSense on the new router I created two interfaces... I had read on the basic firewall page that OPT interfaces have no rules and forgot that - thanks for setting me straight and waking me up. Firewall rules are scary but I'm getting there.

The P2s will only show in the status if they are active. If there is no traffic that has attempted to establish the P2, then the P2 won't exist and won't show there in the list.

Only P1s will show up at all times, even if they are down/inactive.

Well, in my opinion the easiest way to do that is to run DNS off the firewall so the queries are organically sourced from something interesting to the tunnel.

In the Resolver (unbound) you can set one outgoing interface for queries it needs to resolve. That could be the LAN. All queries going to the outside will then have to go through NAT but that is generally not an issue.

In the Forwarder (dnsmasq) you can set the source address on a per-domain-override basis.

Again, if it important, I'd run a couple of bind instances on the inside.

@gertjan said in Why does this forum have only an IPv4 address?:

Yes: 2610:160:11:18::199 ☺

Yep. I see that too.

I would only expect to see that reduction if something else is using the VPN connection. If there is no VPN traffic then the full WAN bandwidth should be available for clients routing directly. Unless you have some traffic shaping in play.
100Mbs doesn't seem bad for a VPN provider but speeds do vary wildly. 70-95% is not a useful measure, there things are almost certainly limited at the VPN provider in absolute terms.

What hardware are you running this on? You may be hitting a local limit there.

Steve

That looks correct. You can't route over policy based IPSec. But if you NAT the subnets you can make the traffic match an existing policy.

Steve

@zacha
Thank you! you're a Hero!! Your solution helped me. And i confess, i've already seen it!

You'd have to set up the firewall rules to block traffic between the VLANs and also allow it out the VPN

@jknott @bfeitell thanks a lot!
After setting as DHCP, internet works under bridge mode. Will spend some time to explore IPv6.

Here's what I finally worked out-

BACKUP_HOST=<gateway_IP> BACKUP_USER=<user_name> BACKUP_PASSWORD=<user_password> # Create config file directory if it doesn't exist [ -d files/ ] || mkdir files # Fetch the login form and save the cookies and CSRF token: wget -qO- --keep-session-cookies --save-cookies cookies.txt \ --no-check-certificate https://${BACKUP_HOST}/diag_backup.php \ | grep "name='__csrf_magic'" | sed 's/.*value="\(.*\)".*/\1/' > csrf.txt # Submit the login form along with the first CSRF token and save the second CSRF token (can’t reuse the same file) – now the script is logged in and can take action: wget -qO- --keep-session-cookies --load-cookies cookies.txt \ --save-cookies cookies.txt --no-check-certificate \ --post-data "login=Login&usernamefld=${BACKUP_USER}&passwordfld=${BACKUP_PASSWORD}&__csrf_magic=$(cat csrf.txt)" \ https://${BACKUP_HOST}/diag_backup.php | grep "name='__csrf_magic'" \ | sed 's/.*value="\(.*\)".*/\1/' > csrf2.txt # Submit the download form along with the second CSRF token to save a copy of config.xml: wget --keep-session-cookies --load-cookies cookies.txt --no-check-certificate \ --post-data "download=download&donotbackuprrd=yes&__csrf_magic=$(head -n 1 csrf2.txt)" \ https://${BACKUP_HOST}/diag_backup.php -O ./files/config_${BACKUP_HOST}_$(date +%Y-%m-%d-%H-%M-%S).xml 2>/dev/null # Clean up rm cookies.txt csrf.txt csrf2.txt unset BACKUP_HOST BACKUP_USER BACKUP_PASSWORD # Remove files older than 100 days find /mnt/user/odin_backup/OdinBackUp/files/ -type f -name '*.xml' -mtime +100 -exec rm {} \;

I did have to change permissions for the backup user though. Even when I used the code in the link that @Gertjan provided and just substituted the correct IP, user and password I would still get the error shown in my first post. Once I added "all pages" to the backup user's permissions the errors went away. I think that the default code in the link didn't generate an error because it uses the default admin/pfsense user which has full privileges IIRC. Just a guess.

@Gertjan and @stephenw10 Thanks again for your help. Very much appreciate it.

Just looked in the logs as per my bold text, it wasn't hitting the sftp host but the dmz interface.

You could bridge the WAN to an internal interface and have clients there pull IPs directly from your ISP.
You can still filter the traffic across the bridge.

Steve

Thanks jimp. I went back to the General System Settings and re-selected the correct timezone location, saved then rebooted and all seems good.