Disclaimer: This information is provided as-is for the benefit of the Community. Please contact Sophos Professional Services if you require assistance with your specific environment.
Table of Contents
Overview:
This recommended read describes the troubleshooting steps for the issues observed while accessing the Webadmin and User portal externally.
Scenario:
The following error is observed when accessing Sophos Firewall GUI externally.
Step 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 & User Settings>Admin console and end-user interaction and check Admin console HTTPS Port.
On CLI> Go To 5:Device Administration>3 Advanced Shell and type the following command
psql -U nobody -d corporate -c "select destinationport from tbllocalservicedetails WHERE localserviceid =2"
Also, Note that the Port used in the User Portal & WebAdmin must be OPEN in both sides of the computer while doing the connection
For more reference, kindly see the Admin Settings
Step 2: ACL Rule for HTTPS & User Portal
Go to Administration>Device Access
*Alternatively, you can turn on device access for HTTPS and the User Portal on WAN, although this isn’t recommended for safety & security
For more info, Kindly see Device Access & Best Practice
Step 3: Troubleshooting Tools
If you're still experiencing the same error after following the steps mentioned above, Kindly do a TCPdump for the specific port
We'll capture tcpdumps and conntracks on port 4444(HTTPS Access) and Public Host IP 10.201.209.229 for the webadmin portal issue:
Note: In this example, 10.201.209.229 is the Public IP of the Sophos Firewall
3.1 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.
3.2 Conntrack
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.
Revamped RR
[edited by: Erick Jan at 12:26 PM (GMT -7) on 17 Sep 2024]