R80.10 Mobile Access - File Share

[David_Herselman]

I configured a file share following the Mobile Access R80.10 Administration Guide (Mobile Access Applications).

When logging in to the SSLVPN portal I'm presented with the following:

If I enter '\\unix-01\public' it denies access:

If I however enter '\\192.168.1.3\public' it works perfectly...

Mobile Access name resolution for the gateway is configured:

Running a tcpdump on 192.168.1.3 (Samba AD Server) shows the DNS query being answered, with no other connections arriving:

[davidh@unix-01 ~]# tcpdump -i eth0 host 100.127.254.1 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
05:45:02.597653 IP 100.127.254.1.58998 > 192.168.1.3.53: 38186+ A? unix-01.lair.co.za. (36)
05:45:02.598026 IP 192.168.1.3.53 > 100.127.254.1.58998: 38186* 1/2/2 A 192.168.1.3 (120)

2 packets captured
2 packets received by filter
0 packets dropped by kernel

Mobile Access log is generated:

Legacy Mobile Access policy should be allowing anything and everything:

Other observations:

• Not sure why it resolves unix-01.lair.co.za when the Mobile Access name resolution is configured for a domain of 'ad.lair.co.za' but both unix-01.lair.co.za and unix-01.ad.lair.co.za resolve to 192.168.1.3 when querying 192.168.1.3 or 192.168.1.5.
• Accessing the UNC path using an IP (\\192.168.1.3\public) results in nothing being logged anywhere.
• Access deny rule record contains the share name twice, as shown above.

[PhoneBoy]

This should be in the Remote Access‌ space.

I'd recommend following the troubleshooting steps for File Shares here: ATRG: Mobile Access Blade 

[David_Herselman]

Many thanks, I followed the debug steps in the 'Troubleshooting Topic: File Shares' section and compared a debug when attempting to access \\unix-01\public to \\192.168.1.3\public. The first instance doesn't record anything whilst the 2nd initiates 'RpcServer::newConnection', which details the following in the Request section:

[CvpnProcServer 11021 4135978768]@fwcp1[12 Sep 21:52:08] Request: (
   :method (RunProcReq)
   :params (RpcProcRequest
      :m_cookie (string
         :value (***)
      )
      :m_processName (string
         :value ("/opt/CPcvpn-R80/bin/Mount")
      )
      :m_args (vector
         : (string
            :value (192.168.1.3)
         )
         : (string
            :value (public)
         )
         : (string
            :value ("/opt/CPcvpn-R80/mnt/cvpn_mnt/ml0")
         )
         : (string
            :value (davidh)
         )
         : (string
            :value (50232a6b27653d4f)
         )
         : (string
            :value (ad.lair.co.za)
         )
      )
   )
)

We run split horizon DNS to resolve names differently outside of our network to within, the problem appears to be that Mobile Access name server definitions simply get added to /etc/resolv.conf, which results in Gaia recursively attempting to resolve the name in the UNC path using the default DNS search domain:

[Expert@fwcp1:0]# cat /etc/resolv.conf
# This file was AUTOMATICALLY GENERATED
# Generated by /bin/resolv_xlate on Mon Sep 10 20:45:34 2018
#
# DO NOT EDIT
#
search lair.co.za
nameserver 41.79.20.1
nameserver 41.79.21.1
#start SSLVPN name servers from Smart Dashboard
nameserver 192.168.1.3
nameserver 192.168.1.5
#end SSLVPN name servers from Smart Dashboard

What's confusing is that Gaia sends DNS queries for 'unix-01.lair.co.za' to both the public caching DNS servers as well as the private AD DNS servers (Samba Active Directory), but then doesn't attempt connecting to either.

Got it working by clearing the Mobile Access Name Resolution settings and configuring the DNS servers to reference the internal DNS servers in 'clish':

clish:

set dns primary 192.168.1.3
set dns secondary 192.168.1.5

Is this the intended behaviour? I would have assumed the gateway to be configured to use public caching DNS servers and the Mobile Access name resolution settings to be used for the SSL VPN portal...

[PhoneBoy]

The above DNS servers are for clients that connect with SNX, not for the MAB portal itself, which would use the Gaia OS settings.

[Hugo_vd_Kooij]

I recommend you login to the gateway in question with SSH and see what happens if you type ping unix01

If that fails you know why it failed in you Mobile Access connection.

[Ozgur]

SMBv2/v3 doesnot support, Once the gateway supports a newer kernel (like is planned for R80.20), it should be possible to support SMBv2/v3. you can find the details at the link below.

https😕/community.checkpoint.com/t5/SandBlast-Mobile/SMBv2-v3-on-Mobile-Access-File-Share-and-not-on...