To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".
We can buy a licence, we can install the machine, but we can´t Restrict Admin Access To The Device ...
So, we can´t sell the machine to customers.
Any idea when this confusion will be ended ?
Technical Support Advisor - Premier Services
in former times we had:
How can I restrict admin access to the device? | SonicWall
but this does noct work on WAN/LAN so there is a strange security hole, so
Yes, you are right. The KB mentioned by you is the right resource to restrict the admin access to the firewall appliance based on Source IP address(es).
Have you tried building the rule from WAN to WAN or LAN to LAN zones? What is the error that's been reported by the SonicWall if any? Is the rule itself not getting created?
I have done a test on NSv270 SonicOSX 7.0.0-1128
ZONE WAN to ZONE WAN security policy was created:
SOURCE any DESTINATION X1 IP (or "All X1 Management IP" or "WAN Interface IP"
Interface X1 MANAGEMENT option "HTTPS" ,"PING" and "SSH" was enabled
I thought the security policy can limit access to firewall "HTTPS" ,"PING" and "SSH" on WAN IP.
But the test results are anywhere can access firewall "HTTPS" ,"PING" and "SSH"
The ZONE WAN to ZONE WAN security policy seems not work? 😕
If you are trying to restrict the WAN management for all users, please have the HTTPS management check box on the WAN interface disabled.
If you are trying to restrict the web management for certain users based on IP addresses, please specify the source field on the access rule with allowed IPs with action set to allow.
There is no direct deny rule can be enforced instead disabling the web management completely on the WAN interface.
Hope this clarifies.
Hi SARAVANAN ,
>If you are trying to restrict the WAN management for all users, please have the HTTPS management check box on the WAN interface >disabled.
>If you are trying to restrict the web management for certain users based on IP addresses, please specify the source field on the access >rule with allowed IPs with action set to allow.
>There is no direct deny rule can be enforced instead disabling the web management completely on the WAN interface.
>Hope this clarifies.
did you tried this?
or is this your hope ???
I did not work, when the management is disabled then it is disabled !
@TOMCHOU , please check:
LAN an WAN the same, it did not work , using x7 as DMZ then there will the rule-management work as expected ...
The device is sold since months and no one one as checked this ???
@RKRONENBERG - My comment is based on my recent testing.
i have SonicOSX 7.0.0-1128-31e37b64 on Vmware vsphere 6.5
X0,X1 Management not useable, because not restrictable ...
and this is a serious Problem
@RKRONENBERG - I understand. Please approach our support team and take further help as the issue needs real-time assistance.
for critical issues pls. open a ticket, give full tsr. and so and so on ...
I think, it is very critical. So why a tsr ??? You can check it it in your own environment.
Support told me: made by design ...
There is already a case open, but we loose too much time while thinking about tsrs and so on ...
Obviously, this issue is on any os7x security policy with DESTINATION is any interface IP
on os6.x if any Interface MANAGEMENT option "HTTPS" ,"PING" and "SSH" was enabled
The allow rules will be created automatically.
Then we can change the SOURCE "any" to other address object to allow only particular IP addresses.
Begin from os7x, The allow rules will not be created automatically.
So If we want to limit access to interface IP we can only create policy manually.
But unfortunately any security policy with DESTINATION on any interface IP (ex. X0(LAN),X1(WAN)...) seems not work!
when you hit the info-button in
Policy / Rules and Policies / Security Policy / Configuration
will get this Info: There are no system default rules.
Packets are dropped if failed to match a rule
That is wrong, because in syslog-output i can see:
Jan 30 04:56:22 10.0.0.17 id=nsv270 sn=******** time="2021-01-30 04:56:22" fw=aaa.bbb.ccc.ddd pri=4 c=2 m=658 msg="IKE Responder: Proposed IKE ID mismatch" n=1 src=22.214.171.124:53926 dst=aaa.bbb.ccc.ddd:500 proto=udp/500 note="VPN policy does not exist for peer IP address:
That means: There was an IKE Request from "126.96.36.199" and there was not the right policy exixtent ...
But we have no Security Policy to allow IKE from Wan to X1 IP !!!
hi @rkronenberg (Ruediger) We are checking this issue and do have a bug created for tracking this. Hi @Saravanan Can you make sure all these data is added to the open bug for WAN to WAN access not restricted issue. You can reahc out to me in case you are unable to find the open issue.