Arkwright Community Legend ✭✭✭✭✭
Reactions
Comments
-
This kind of question is really too vague to work as a forum discussion. I would start with using the Connection Monitor and filtering on each WAN interface. Identify what traffic is on there. Move those services over to your new WAN. Keep watching for connections on your old WANs, you should seem them reducing in number…
-
No hits on rule = disabling won't break anything *that hasn't been used since the last firewall reboot*. How long as the firewall been up?
-
Rules are processed top to bottom, first match wins. Create a rule allowing what you want to allow. Create a rule blocking what you don't want to allow. Re-order the rules to suit.
-
I have no experience with screen readers, but do they work with the CLI? There is a CLI netextender installed along with it, perhaps you could try that.
-
I assume you mean from internal, as accessing it externally on X1 IP when X1 is down is obviously not going to happen. Loopback NAT policies will allow you to reach port-forwarded resources by their public IPs from an internal network. However, if X1 is dynamically configured [DHCP or PPP] you might struggle to get…
-
There probably is but it's easy enough to un-tick each one.
-
SMB is notorious for "bandwidth-delay product" so is a poor choice for testing throughput BUT that usually only applies with a high RTT which presumably isn't an issue on your LAN, so probably is the security services inspection slowing things down here.
-
Turn off all the security services and re-test.
-
Switch one in diagram is unmanaged That's probably your problem. IME, it's not possible to predict if an unmanaged switch will or won't pass VLAN tags. Connect X0 directly to your managed switch and re-test. Additionally, I wonder what "asymmetric VLAN" is? Not sure if this is some weird implementation I have never come…
-
Another vote for iperf. Even if you can max out a link with SMB, it would still be interesting to know what you get with iperf.
-
Any firewall that is passing traffic is not in safe mode, that's for sure. Try the console port on both [although I have never seen a console port go bad]. If it doesn't work on either then it's the serial settings on your device or it's the cable.
-
It says "administrator/user lockout" which to me suggests both administrators and users. Yes, it's in the Administration section. But there's no setting for this in Users>Settings. I am sure you can test this easily enough, change the value to n and fail to log in n times. What happens?
-
You can try via Ansible . You've got me intrigued - are you [or anybody] using Ansible + SonicOS? The Github issue you linked to is simply a report of it not working, closed with no solution [I love those kind of Github issues :D]
-
NAT is not default for site-site VPN, so this will be down to the configuration.
-
Additional networks need to be added to SSLVPN client routes and the allowed networks for the user/group. Won't work without both.