Set Up Avanet Support Access on Sophos Firewall

For support cases, planned changes, or joint troubleshooting, it may be useful to temporarily grant Avanet access to a Sophos Firewall. However, this access should not be achieved by making WebAdmin or SSH generally accessible from the internet. A better approach is a clearly defined support access with its own admin user, defined source, and documented rollback.

This guide describes a typical procedure for access via HTTPS/WebAdmin and optionally SSH. For general basics on local firewall services, also refer to Device Access and Local Service ACL on Sophos Firewall. If SSH is used, Connect to Sophos Firewall via SSH should also be known.

⚠️ Support access is an administrative access to the firewall. It should only be active for the required period, be as narrowly limited to the support source as possible, and be reviewed or removed after the case is closed.

Clarify Before Setting Up

Before granting access, it should be clear what access is really needed. For many tasks, HTTPS/WebAdmin is sufficient. SSH should only be activated if log files, CLI, or Advanced Shell are really needed. It should also be clear from which source access is allowed, when the access will be removed, and whether a current backup is available before major changes.

If a general admin or partner account already exists, another permanent account should not simply be created. In such cases, it is usually better to review the existing access, control MFA and roles, and only temporarily allow the source.

Security model for support access

Support access should not be treated as a normal permanent account. It is an operational access that should be clear, limited, and easy to remove again after the support case.

Possible variants:

• Temporary user avanet: useful when a support appointment is planned and access should be removed afterwards.
• Dedicated support admin: useful when support is provided regularly, but only with a strong password, MFA, and limited access sources.
• Short-term activation of SSH or WebAdmin: useful for a specific troubleshooting window, but should be disabled or restricted again afterwards.
• Access via Sophos Central or remote session: useful when no direct inbound management access should be opened.

The important point is that access, authentication method, source restriction, and rollback are defined before the appointment. For changes on productive firewalls, it should also be clear who approves the change and where it is documented. For audit trails, configuration audit logs and, for larger changes, Config Studio are useful follow-up topics.

Define password, MFA, and handover path

Technical access is only one part of the support setup. Just as important is how credentials are handed over and how access is protected.

• Use a unique password only for this firewall and this support access.
• Do not send passwords together with all access details in the same channel.
• Enable MFA when the account remains active for longer or allows WebAdmin access.
• Document whether access is temporary or permanent.
• Define who disables or deletes the account after the support case.
• If SSH is required, prefer public key authentication where possible.

For admin accounts, MFA for Sophos Firewall is the better companion article. For SSH access, the public key method is preferable when it fits the support workflow.

Add User avanet

The user avanet is intended for WebAdmin access. This makes it easier to trace in the audit trail that a change was made as part of a support case. The user should receive a strong password and remain active only as long as needed.

1. Open Authentication in the left navigation.
2. Select Users.
3. Click Add.

Typical values:

• Username: avanet
• Full name: Avanet
• Profile: Administrator, if Avanet needs to fully review or change the firewall
• Password: strong one-time or support password from a password manager
• Email: for example service@avanet.com

Then save with Save or Add.

If only very limited tasks are planned, a narrower admin profile may be more appropriate. For many support cases, however, Avanet temporarily needs full rights because cause, logs, rules, NAT, VPN, routing, and system status often need to be checked together.

Create FQDN Host for support.avanet.com

To ensure the ACL rule does not apply to arbitrary internet sources, a host object for the Avanet support source is first created.

1. Open Hosts and services.
2. Select FQDN hosts.

Then add a new FQDN object:

• Name: support.avanet.com
• FQDN: support.avanet.com
• Description: Avanet Support Access

Save with Save. The firewall resolves the FQDN via DNS and then uses the object as a source in the local ACL rule.

Set Up Local Service ACL Exception Rule

Access to WebAdmin and SSH are local services of the firewall. They are not governed by normal firewall rules, but by Administration > Device access and Local service ACL exception rule.

1. Open Administration.
2. Select Device access.
3. Scroll to the Local service ACL exception rule section.
4. Click Add.

The rule should be set as narrowly as possible:

• Rule name: Avanet Support
• Rule position: appropriate to the existing ACL structure, often Bottom
• IP version: IPv4, or additionally IPv6 if explicitly needed
• Source zone: Zone from which the support access comes, often WAN
• Source Network / Host: FQDN object support.avanet.com
• Destination host: Any or specifically the firewall address, depending on the environment
• Services: HTTPS; SSH only if really needed
• Action: Accept

Then save and check the rule position. If there is a broader deny or exception rule above, the new rule may be ineffective.

⚠️ Any as a source is not a good support release for WebAdmin or SSH. If the source is not clear, it should first be clarified with Avanet which support source will be used. A broad release immediately increases the attack surface of the firewall.

Optional: Store SSH Public Key

SSH is only needed if an analysis via Device Console, log files, or Advanced Shell is necessary. For many support cases, WebAdmin is sufficient.

It is important to distinguish: The previously created user avanet is a WebAdmin user. SSH access to Sophos Firewall is usually done with the user admin. Therefore, the SSH public key is stored in the Public key authentication for admin section.

1. Open Administration.
2. Select Device access.
3. Scroll to the Public key authentication for admin section.
4. Enable Enable authentication if public key authentication is not yet active.
5. Add the public key provided by Avanet under Authorized keys.
6. Save.

Example of the Avanet public key:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCktco/uC29KdU+Hf7GjcYXFumGJvt11MPxhdpnYA2XVEbnsI9r/XrW9J9K2ugvVGNoOD4IlN/bWZ1z3W6UqFKGgHUYkQu2h+0PFzP5I12Pu9I/3qIWwOhdA2j523FzneGQFptNCHHLQwma/zYJJwcVqsiJo/mg6W8jUbS30jFP6zDJvGRzbA2ATC7XzGNfa/CYr/AKoqdvm87RThOT7uh86w39x9VQTZH7d217K2UVuUrSppvnRaw5NCwukamWDDs8EtsVIFNkkxMl/SdJTC1SOSfO6mw8erXm1RhmNT5+wN/87f+DQioQPuWSrC3EHkgqw9BjoU3aLtYUw9AAItf6jJeUnZBfBCeJ1fJAzYpR8STdbaI8RXP1QMOr4omtmCakfnEH8kZ1BAYXxVzrJBXQ+sDVLZtWNDPqg8jIpdJ6bRNk/m7B+LAwsofHVLH1VSxoOEYdJGQvPfwonqo2JR+vosYhoHG89eh5EL/X9z5amvfVCShf6icstYwmaUmT/9lUTd8tkJZeTxNoezyspHhMryfB93653vb6wPS/n0ITkfu6rSfSrE1A1Y1dD5QtsFF6oEZxPqo8qQajtGhI3vZdHZSx53PqFqInra75xFHc+EjEsoLjt2wQdHr+ttEKvfrjfQmyXaWzqqE6bxmbbcMPtqY+pzMf83nEGwepJka0uw==

The private key is not stored on the firewall and should never be shared via email or chat. Only the public key belongs in the authorized keys field on the firewall.

Test Access

After saving, access should not be blindly considered complete. A brief functionality test is advisable:

1. Test WebAdmin access via the agreed Avanet support source.
2. Verify login with the user avanet.
3. If SSH is needed: Test connection with admin and public key.
4. Check in the Log viewer and, if necessary, in the Audit Trail whether the login and subsequent changes are traceable.
5. Document when the access will be deactivated or removed.

If access does not work, first check the source and the ACL rule. Then check DNS resolution of the FQDN object, rule position, Device Access, upstream NAT devices, and routing.

Roll Back Access After Support Case

After the support case is completed, the access should not remain unchanged permanently. Depending on the agreement, there are three clean options:

• Disable user: If further support is foreseeable later, but no access is currently needed.
• Disable ACL rule: If the account should remain, but no external access should be possible.
• Remove user and ACL rule: If the access was only needed once.

Additionally, it should be checked whether an SSH public key can be removed again. If changes were made to the firewall, Backup and Restore on Sophos Firewall, Audit Trail Logs, and for rule changes Config Studio are suitable for post-control.

Checklist

• User avanet created with a strong password.
• Admin profile consciously chosen and documented.
• FQDN host support.avanet.com created.
• Local Service ACL Exception Rule limited to the Avanet support source.
• Only necessary services allowed: HTTPS, SSH only if needed.
• SSH public key stored only in the Public key authentication for admin section.
• Access tested and documented in the ticket.
• Rollback or deactivation planned after completion.

Frequently Asked Questions