SonicWall has confirmed the issue I discovered. The quick fix? Restart the sonicwall and the changed service object/group will be recognized. If a reboot is not possible, recreate the service object/group (rather than editing an existing)
… See full details below…
DTS #47619 “Access Rules w/ Service Groups stop passing traffic if member service is edited” was created for this issue. Please read details below.
Steps to Reproduce
Comment #1 from Sonicwall on 2007-02-14 16:23:35.134239 -
Create inbound config w/ rules and NAT policies using the public server wizard,
or manually, using a service group.
Confirm inbound traffic works using that config.
edit the name or port definition on one of the services in the group
change the server on the internal network to use the newly-edited port number
confirm that the server is answering that port as seen from a testing client on
the inside
try reaching the server on its new port from outside, through the firewall ; it
will fail.
Look at the logs and see the dropped TCP entry from your attempt.
Job Workaround
Comment #1 from SonicWall on 2007-02-14 16:23:35.134239 -
restart firewall or re-create the rule.
Job Comments
Comment #1 from SonicWall on 2007-02-14 16:23:35.134239 -
Description of problem:
SonicOS Enhanced versions 3.2.0.0 through 3.2.4.0 have a problem in which an
access rule stops working if:
a) it uses a Service Group
b) one of the member services is edited in any way
I have verified this using my TZ170SPW. I have a webserver on the LAN and I
have a service group which contains the web port 8000 and a few mail protocols
like SMTP and POP3. If I edit the service web port 8000 to 8001 instead, and
then change the webserver to answer on that port, traffic from the WAN to the
webserver on the LAN will fail and will be logged as dropped TCP (with no rule
citation).
If I create a new rule using the service group or the individual web port 8001,
it works fine. A restart will also restore connectivity. I suspect that other
types of changes to the service group, such as removing or adding member
services, might have a similar effect. More testing is needed.
Customer wrote in SR:
Bug Report: If I have a Firewall rule setup utilizing a defined service,
and then change any aspect of that service - such as a port
range or even service name - the rule ceases to function.
Example:
Access Rule:
WAN > LAN
Source: Any
Destination: All WAN IP
Service: SRWEB01 Services
Action: Allow
Users: All
SRWEB01 Services is a service group containing:
Jabber S2S
Jabber Client
Jabber S2S is a service defined as:
TCP 5269 to 5269
Jabber Client is a service defined as:
TCP 5222 to 5223
This works if I build the following from scratch, however if
“Jabber Client” is initially 5222 to 5222 and i change it to
5222 to 5223, I am unable to use either 5222 or 5223 (the
entire “Jabber Client” service). The same occurs if the
service is initially named “Test” and I rename it to "Jabber
Client", even if the ports do not change)
Version-Release number of selected component (if applicable):
3.2.x.x Enhanced on any platform
How reproducible:
100%
Actual results:
traffic stops after real-time edit of service used in a rule
Expected results:
traffic attempted against a rule is re-evaluated in real time, after real-time
edit of service used in a rule
Additional info:
I don’‘t see this behavior in 4.0.0.0_21e on Pro4060 and I suspect it’'s not in
3.5.0.0 Enhanced either. I’'ll update this case w/ news on that front.