XG Firewall v18 MR-5: Feedback and experiences

I have a problem with SSL VPN (remote access). I use SSL VPN with split tunnels. Networks changes in "Permitted network resources (IPv4)"  are not reflected on SSL VPN clients. Routes are not pushed into SSL VPN clients. In version MR 4 it operates normally. I had to roll back to MR4 version.

Same problem here.

How do I directly report Sophos this apparent bug? I don't want to establish Standard Support Case. I just want to report it and hope it in MR6 will be fixed...

Sophos needs at least one support case to follow up the process queue. 

I am not able to reproduce this issue with MR5. 

Sorry, but I can't open Standard Sophos Case because I currently use in production firewall MR4 version. I had to roll back to MR4 version.

But I can to someone more capable offer full access to my lab appliance with MR5 where the error is also visible. Still pushing route to SSL VPN client that has been removed from Permitted network resources (IPv4) and another cannot add...

Hi Jaroslav Faldík,

I'll be attempting to replicate the issue you reported and provide you with an update. 

Thanks,

Hi Jaroslav Faldík,

I'll be attempting to replicate the issue you reported and provide you with an update. 

Thanks,

Jaroslav Faldik,

Could you please check the status of the service on your LAB appliance running on MR5? 

Run the following command from the Advanced Shell: 

service -S | grep sslvpn

Also, put the csc service in debugging and add the new network under permitted networks and collect the csc logs. 

To put the csc service in debug run: 

csc custom debug

Note: Run the same command to remove the service from the debugging. 

Thanks,

Hi,

OK, here is output:

XG210_WP03_SFOS 18.0.5 MR-5# service -S | grep sslvpn
sslvpn RUNNING
XG210_WP03_SFOS 18.0.5 MR-5# csc custom debug
XG210_WP03_SFOS 18.0.5 MR-5# tail -f /log/csc.log
DEBUG Apr 28 19:46:04 [listener:1399]: csc_waitpid: Process with pid 27400, wrapped-up successfully using signal 9.
DEBUG Apr 28 19:46:04 [listener:1399]: Main TLV:{ 4, data:{ 1, 4, 0000} data:{ 2, 4, 86B00} data:{ 5, 4, 1000} , 27}
DEBUG Apr 28 19:46:04 [listener:1399]: csc_socketpair called: biggest fd is 110
DEBUG Apr 28 19:46:04 [listener:1399]: Realising worker 27402
DEBUG Apr 28 19:46:12 [listener:1399]: ln_recvfrom: fd '110.TCP.UNIX.auxilary': 37 bytes are read by listener
DEBUG Apr 28 19:46:12 [listener:1399]: register_request_unix: request from path ''
INFO Apr 28 19:46:12 [listener:1399]: protocol content type not found
INFO Apr 28 19:46:12 [listener:1399]: protocol length not found
DEBUG Apr 28 19:46:12 [listener:1399]: stuff_of_listener: custom command debug found
MESSAGE Apr 28 19:46:12 [listener:1399]: Toggling log level to: WARNING
DEBUG Apr 28 19:46:27 [worker:27402]: read_packet: read() 52 bytes from listener
MESSAGE Apr 28 19:46:27 [worker:27402]: Toggling log level to: WARNING
MESSAGE Apr 28 19:46:27 [worker:27402]: {"request":{"method":"nopcode","name":"u2d_pt_installer","version":"1.2","type":"text","length":0}}
MESSAGE Apr 28 19:46:28 [worker:27467]: {"request":{"method":"nopcode","name":"u2d_dr_installer","version":"1.2","type":"text","length":0}}
MESSAGE Apr 28 19:46:43 [worker:27475]: {"request":{"method":"opcode","name":"apiInterface","version":"1.0","type":"json","length":481,"data":{"idletimeoutfullaccessconf":"1","___serverport":4444,"___component":"GUI","users":["test"],"transactionid":"1506","mode":202,"currentlyloggedinuserid":3,"users_cat":"users","APIVersion":"1800.2","selectedhosts_cat":"","___serverprotocol":"HTTP","name":"Test","id":"Test","___username":"admin","tunneltype":"1","accessmode":"1","selectedhosts":["#Port1","#Port3","#Port5","#Port6"],"___meta":{"sessionType":1},"___serverip":"91.201.33.94","currentlyloggedinuserip":"185.5.227.227"}}}
DEBUG Apr 28 19:46:43 [worker:27388]: read_packet: read() 735 bytes from listener
MESSAGE Apr 28 19:46:43 [worker:27388]: Toggling log level to: WARNING
MESSAGE Apr 28 19:46:43 [worker:27388]: {"request":{"method":"opcode","name":"update_sslvpn_policy","version":"1.6","type":"json","length":683,"data":{ "APIVersion": "1800.2", "Event": "UPDATE", "tunneltype": "1", "idletimeoutfullaccessconf": "1", "Entity": "sslvpnpolicy", "name": "Test", "___component": "GUI", "accessmode": "1", "description": "", "id": "Test", "___serverprotocol": "HTTP", "___serverip": "91.201.33.94", "selectedhosts_cat": "", "___meta": { "sessionType": 1 }, "mode": 202, "selectedhosts": [ "#Port1", "#Port3", "#Port5", "#Port6" ], "currentlyloggedinuserip": "185.5.227.227", "currentlyloggedinuserid": 3, "idletimeoutfullaccessvalue": "null", "transactionid": "1506", "___username": "admin", "selectedhostsforipv6": "", "users": [ "test" ], "anyurlaccess": "0", "users_cat": "users", "___serverport": 4444 }}}
DEBUG Apr 28 19:46:43 [fwm:1477]: read_packet: read() 80 bytes from listener
MESSAGE Apr 28 19:46:43 [fwm:1477]: Toggling log level to: WARNING
MESSAGE Apr 28 19:46:43 [fwm:1477]: {"fwm":{"method":"service","name":"fwm:manage_sslvpn_policy","version":"1.0","type":"json","length":28,"data":{"policyid":"1" , "opt":"a"}}}

PAckage ::::vpn::sslvpnpolicy
Readobject returning from function prepareOperationQuery,tempTypeQuery=hosttype in (?,?,?)

Readobject returning from function prepareOperationQuery,tempTypeQuery=ipfamily = ?

Readobject returning from function prepareOperationQuery,tempTypeQuery=usertype in (?)

Readobject returning from function prepareOperationQuery,tempTypeQuery=usertype in (?,?,?,?)
MESSAGE Apr 28 19:46:47 [worker:27520]: {"request":{"method":"nopcode","name":"quarantine_data_cleanup","version":"1.0","type":"json","length":15,"data":{"qur_res":"0"}}}
MESSAGE Apr 28 19:46:47 [worker:27519]: {"request":{"method":"nopcode","name":"restart_dyndns_connections","version":"1.2","type":"text","length":0}}
MESSAGE Apr 28 19:46:49 [worker:27530]: {"request":{"method":"nopcode","name":"smtp_quarantine_cleanup","version":"1.0","type":"text","length":0}}
MESSAGE Apr 28 19:46:55 [worker:27535]: {"request":{"method":"opcode","name":"login_user","version":"1.0","type":"json","length":316,"data":{ "groupid":"Open Group","userid":"test","liveuserid":"1","ipaddress":"10.81.234.6","bwpolicyid":"","webfilterid":"Allow All","appfilterid":"Allow All","starttime":"272081","clienttype":"13","setname":"lusers","addr_family":"2","ismicroapp":"1","authservername":"","macaddress":"","logintime":"2021-04-28 19:46:55" }}}
MESSAGE Apr 28 19:47:00 [worker:27547]: {"request":{"method":"nopcode","name":"garnerevent","version":"1.0","type":"text","length":2,"data":60}}
MESSAGE Apr 28 19:47:03 [worker:27602]: {"request":{"method":"nopcode","name":"auth_execute_heartbeat","version":"1.0","type":"text","length":0}}
MESSAGE Apr 28 19:47:04 [worker:27606]: {"request":{"method":"nopcode","name":"auth_edir_sync","version":"1.0","type":"text","length":0}}

^C
XG210_WP03_SFOS 18.0.5 MR-5#

Here are print screens from SSL VPN (remote access) and OpenVPN Client log.

#Port1 - 172.16.16.16/24 (by default)
#Port2 - WAN (by default)
#Port3 - 192.168.3.1/24
#Port4 - 192.168.4.1/24
#Port5 - 192.168.5.1/24
#Port6 - 192.168.6.1/24

In OpenVPN client missing routes for #port5 and #port6 and in addition, there is a route for #Port4.

This is a invalid config. #Port does not mean the network of this port. Instead its the Port itself. Hence everything works fine. 

Hi LuCar Toni,

sorry, I don't share your opinion.  Mask /32 nothing doesn't matter. Here is the same output (OpenVPN Client) for "standard" /24 networks:

But in MR4 with #Ports in Permitted network resources (IPv4) operates normally.

EDIT: Yes, until now I understood what you thought...

Fixed masks:
#Port1 - 172.16.16.16/32 (by default)
#Port2 - WAN (by default)
#Port3 - 192.168.3.1/32
#Port4 - 192.168.4.1/32
#Port5 - 192.168.5.1/32
#Port6 - 192.168.6.1/32

MR5 Build 586 does not fix this error. But I found that the changes (adding or removing) host/net in Permitted network resources (IPv4) will be reflected in the OpenVPN client (pushed routes) only after the reload SFOS (reboot appliance).

I could reproduce this and reported it back to the Team. 

PS: Restart of the appliance was not needed: Simply restart of the service is fine to push the new routes. service sslvpn:restart -ds nosync

Thank you!

PS: I didn't know exactly which service causes it. Restart of the appliance was a solution.

This issue will be listed on the known issue list for this release. 

See: https://docs.sophos.com/releasenotes/index.html?productGroupID=nsg&productID=xg&versionID=18.0

Only affected is adding of new networks. Deleting works fine. 

Restart of the service will add all future networks. 

See: https://support.sophos.com/support/s/article/KB-000041768?language=en_US

Strange because in my lab appliance with MR5 Build 586 are affected both cases i.e. adding of new and deleting existing networks.

Same here adding/deletiing recourses are affected in "Live" XG210 and "Lab" VM