I've never used SecureClient or anything else by the same vendor, but I have seen the same issue with a completely different vendor, Cisco. In the Cisco case, whether you can reach the local network or not is something that is configured on the firewall you are connecting to -- the remote device has control over whether you can reach your local network.
This kind of situation is deliberate in IPSec, to allow security administrators to enforce access policies designed to prevent third parties from attacking the secure network by having control over your PC and exploiting the PC's trust relationship with the secure network. If your PC#1 trusts local PC#2, and PC#1 is connected to secure network B.A.N.K, but PC#2 is under the live control of Evil Doctor Mumblebot (because the client on PC#1 cannot shut down PC#2's internet access), then the Evil Doctor can connect remotely to PC#2, use that to connect to PC#1, and use PC#1 to connect to the secure network B.A.N.K as a trusted user. To prevent this possibility, IPSec security gateways can often be configured to force upon the client (PC#1) that the client cannot talk to any other machine at the same time that it is talking to the secure network.
The existing policy makes with that all the local traffic also is crypt with IPSec. Therefore I cann't communicate with none local host. My Network Security Group does not have the interest to help me to configure the local access, they understand that this would be one security risk. But I would like to be connected and to be able to print documents, for example, in my local net.
I need to discover a way to modify the policy that is downloaded in my workstation so that the local traffic is not cript.
As indicated, with Secureclient you will have to have your security adminiistrator modify the client policy to allow this. Part of the design is that you are not allowed to modify the policy. (The ability to enforce a desktop policy on a client attached to the corporate network is a major reason for implementing Secureclient rather than Secureremote).
It sounds like you have been informed that your company has a policy that they are not willing to modify. The best approach is to provide them with a business case of exactly what capabilities you need to allow you to do your job. I suspect they will not allow you to simply bypass the policy for the reasons outlined and if you attempt to subvert the policy your company wants you to use when attached to their network you may be subject to sanctions (up to termination of your employment).