Jump to content
Welcome to our new Citrix community!

Full SSLVPN no outbound internet connectivity


Carlos Pedro

Recommended Posts

Hello everyone,

 

Need some help with this Full(split tunnel off) ssl vpn.  

 

Once VPN is established all intranet traffic/services work as desired however i have no internet outbound access.  I've literally spent days on the phone with Citrix support and no one can tell me how to get this working.  

 

On firewall logs, can see IIP hitting DMZ_UNTRUST to OUTSIDE and being logged but the Palo is saying the data is incomplete and drops it.  

 

Also to note, if i SSH to the netscaler, i am unable to ping google for example, and at which point I see nothing being logged on the Paloalto.

 

I understand this question is bare with minimal info, just wanted to start from scratch, happy to provide any screenshots and config.

 

thanks for your help

 

cheers

Seb

Link to comment
Share on other sites

Do you want your endpoints to do corporate network and internet at the same time, while the internet is not going through the vpn?,  Then you need split tunnel enabled.

Split tunnel would allow the non-vpn traffic to be handled by the client-side network; define intranet apps to determine the traffic the vpn handles.

 

If you are trying to get all user traffic through the vpn, and then the vpn decides what to allow or deny, then you would keep split tunnel OFF, but then you would have to make sure the VPN is passing your internet traffic.  You may need to configure authorization policies (or session policies with authorizations) and configure the NetScaler for which internet traffic to pass. Which could also require a public facing snip possibly and external DNS.

 

Check the session policy under Client Experience > Advanced and make sure no settings restricting access to local networks are in effect.

Check status of Split Tunnel settings.

And look for conflicting allow/deny decisions in both session policies and in authorization policies bound to groups.

 

Check the NetScaler syslog for specific alerts/events related to denying traffic that may indicate if something else is happening:

shell

cd /var/log

tail -f ns.log | grep -v CMD_EXECUTED

(This will keep the syslog as live output, but exclude GUI/CLI configuration tasks)

 

Link to comment
Share on other sites

  • 2 weeks later...

I have the exact same problem with 12.0.56.20 and 12.0.57.19 fw.  I've made sure SDX, VPX, and the nsvpn client are all the same firmware. I have had a case open for two months. I just sent my  last client logs in yesterday as they wanted one more set for confirmation.  They recognize an issue and are saying they could possibly give me a private fix.  

 

In the interim, I've rolled back to 53.13 and it works well, but obviously there is that security issue.  I don't know about anyone else, but these last two firmware versions that fix their security vulnerabilities have cost me 100's of hours.  Very frustrated right now with a technology I enjoy.

Link to comment
Share on other sites

Not sure regarding the firmware version issues, but have been able to get it working in a way that sort-of ticks our boxes.

 

The immediate issue appeared to be that the Netscaler would send intranet traffic out the DMZ_trust VLAN and internet traffic out the DMZ_untrust VLAN.  Not really an issue except when no SNIP is configured for the DMZ_untrust VLAN and when using IP Pool, the source IP doesn't seem to get NAT'd out of the Netscaler which then breaks the static route which we created on the PaloAlto for the IP Pool.

 

Since Citrix were not able to tell me how to force all traffic to go via the DMZ_trust vlan, we have come up with the following.  

 

Create SNIP for DMZ_untrust vlan,  disable the use of IP pool and apply firewall rules to allow SNIP address to get to the internet.  The current limitations for us with this workaround is that user-ID mapping is not working on the PaloAlto. (hoping to get this working)

 

if anyone can see any issues with this setup, please let me know,

 

cheers

 

 

Link to comment
Share on other sites

  • 11 months later...

We had similar issues when attempting to access external resources where the VPN clients w/ IP Pool addresses were routed directly to the Firewall which detected them as spoofed addresses and therefore were dropped.  Our appliance is configured in a two arm topology so in order to route the VPN clients to the internal gateway we created a Policy Based Routing (PBR) policy.

 

add ns pbr pbr_VPN_Clients  allow -srcip 192.168.0.0-192.168.0.255 -destip 0.0.0.0-255.255.255.255 -nexthop 192.168.1.1

 

Firmware Version = 12.1-50.28

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...