Sophos Firewall: Unable to access Webadmin and User Portal externally

Note: Please contact Sophos Professional Services if you require assistance with your specific environment.

Overview:

This article describes the troubleshooting steps for the issues observed while trying to access the Webadmin and User portal externally.

Scenario:

The following error is observed when accessing Sophos Firewall GUI externally. 

What to do:

  1. Verify the ports configured for webadmin and User Portal. Ensure you're accessing it on the specified port. To verify, go to Administration > Admin Settings. For reference, please see - https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Administration/AdminSettings/index.html.
  2. Create an ACL Rule for HTTPS and User Portal. For more info, please see - https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Administration/DeviceAccess/index.html.
  3. Alternatively, you can turn on device access for HTTPS and the User Portal on WAN, although this is not recommended. 
  4. If you're still observing the same error after following the abovementioned steps, please collect a tcpdump and Conntrack for the specific port. 
  5. In this example, we'll capture tcpdumps and conntracks on port 4444(HTTPS Access) and Public Host IP 10.201.209.229 for the webadmin portal issue:

Tcpdump:

tcpdump -nei any port 4444 and host 10.201.209.229 

The output of the command is: (suspicious entries are highlighted)

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
12:26:41.826994 Port2, IN: IP 10.201.105.156.57876 > 10.201.209.229.4444: Flags [S], seq 3117992963, win 64950, options [mss 1280,nop,wscale 8,nop,nop,sackOK], length 0
12:26:41.827135 Port2, IN: IP 10.201.105.156.57877 > 10.201.209.229.4444: Flags [S], seq 1050530732, win 64950, options [mss 1280,nop,wscale 8,nop,nop,sackOK], length 0
12:26:41.828799 Port2, OUT: IP 10.201.209.229.4444 > 10.201.105.156.57877: Flags [R.], seq 0, ack 1050530733, win 0, length 0
12:26:41.828820 Port2, OUT: IP 10.201.209.229.4444 > 10.201.105.156.57876: Flags [R.], seq 0, ack 3117992964, win 0, length 0
12:26:42.081250 Port2, IN: IP 10.201.105.156.57878 > 10.201.209.229.4444: Flags [S], seq 2988879817, win 64950, options [mss 1280,nop,wscale 8,nop,nop,sackOK], length 0
12:26:42.082250 Port2, OUT: IP 10.201.209.229.4444 > 10.201.105.156.57878: Flags [R.], seq 0, ack 2988879818, win 0, length 0 

  • Based on the tcpdump, we could see in the reply of SYN we're getting RST ACK instead of SYN-ACK, which fails to complete a three-way handshake.

Conntracks:

conntrack -E  | grep ‘orig-dport=4444’

The output of the command is: (suspicious entries are highlighted)

[NEW] proto=tcp      proto-no=6 timeout=120 state=SYN_SENT orig-src=10.201.105.156 orig-dst=10.201.209.229 orig-sport=58157 orig-dport=4444 [UNREPLIED] reply-src=192.168.55.237 reply-dst=192.168.55.11 reply-sport=4444 reply-dport=58157 id=2774981440 masterid=0 devin=Port2 devout=Port1 nseid=16777442 ips=0 sslvpnid=0 webfltid=0 appfltid=0 icapid=0 policytype=1 fwid=6 natid=4 fw_action=1 bwid=0 appid=0 appcatid=0 hbappid=0 hbappcatid=0 dpioffload=0x1 sigoffload=0 inzone=2 outzone=1 devinindex=6 devoutindex=5 hb_src=0 hb_dst=0 flags0=0xa0000200000 flags1=0x50400800000 flagvalues=21,41,43,87,98,104,106 catid=0 user=0 luserid=0 usergp=0 hotspotuserid=0 hotspotid=0 dst_mac=fa:16:3e:11:37:b0 src_mac=c8:4f:86:fc:07:09 startstamp=1653981735 microflow[0]=INVALID microflow[1]=INVALID hostrev[0]=0 hostrev[1]=0 ipspid=0 diffserv=0 loindex=6 tlsruleid=0 ips_nfqueue=0 sess_verdict=0 gwoff=0 cluster_node=0 current_state[0]=41 current_state[1]=0 vlan_id=0 inmark=0x8001 brinindex=0 sessionid=204 sessionidrev=13611 session_update_rev=2 dnat_done=3 upclass=0:0 dnclass=0:0 pbrid_dir0=0 pbrid_dir1=0 nhop_id[0]=65535 nhop_id[1]=65535 nhop_rev[0]=0 nhop_rev[1]=0 conn_fp_id=NOT_OFFLOADED 

[DESTROY] proto=tcp      proto-no=6 orig-src=10.201.105.156 orig-dst=10.201.209.229 orig-sport=58157 orig-dport=4444 packets=1 bytes=52 [UNREPLIED] reply-src=192.168.55.237 reply-dst=192.168.55.11 reply-sport=4444 reply-dport=58157 packets=1 bytes=40 id=2774981440 masterid=0 devin=Port2 devout=Port1 nseid=16777442 ips=0 sslvpnid=0 webfltid=0 appfltid=0 icapid=0 policytype=1 fwid=6 natid=4 fw_action=1 bwid=0 appid=0 appcatid=0 hbappid=0 hbappcatid=0 dpioffload=0x1 sigoffload=0 inzone=2 outzone=1 devinindex=6 devoutindex=5 hb_src=0 hb_dst=0 flags0=0xb0000200000 flags1=0x50400800000 flagvalues=21,40,41,43,87,98,104,106 catid=0 user=0 luserid=0 usergp=0 hotspotuserid=0 hotspotid=0 dst_mac=fa:16:3e:11:37:b0 src_mac=c8:4f:86:fc:07:09 startstamp=1653981735 microflow[0]=INVALID microflow[1]=INVALID hostrev[0]=0 hostrev[1]=0 ipspid=0 diffserv=0 loindex=6 tlsruleid=0 ips_nfqueue=0 sess_verdict=0 gwoff=0 cluster_node=0 current_state[0]=41 current_state[1]=41 vlan_id=0 inmark=0x8001 brinindex=0 sessionid=204 sessionidrev=13611 session_update_rev=2 dnat_done=3 upclass=0:0 dnclass=0:0 pbrid_dir0=0 pbrid_dir1=0 nhop_id[0]=65535 nhop_id[1]=65535 nhop_rev[0]=0 nhop_rev[1]=0 conn_fp_id=NOT_OFFLOADED

Similarly, we have to capture and confirm the details for the user portal, e.g., the User portal is configured on port 443, so we need to check tcpdumps and Conntrack on port 443.

We could see traffic flow's firewall and NAT rules based on this.
We shall check Rule ID - 6 and NAT ID – 4.

FW Rule – 6


NAT ID - 4

Since the firewall and NAT rules have been created for "Any" services, this would conflict with Sophos Firewall webadmin and User portal configuration. Thus, traffic would flow from these rules, and they would never reach Sophos Firewall services.

Fix:

We would need to confirm the purpose why the DNAT rule was created and which services are required to publish server access over WAN and add only those services(ports) in the rule instead of keeping "Any" to avoid the conflict with XG services.



Edited TAgs
[edited by: emmosophos at 8:12 PM (GMT -7) on 22 Jun 2022]