topic Re: Multiple SSL VPN tunnels to same endpoint - possible? in General Topics

Multiple SSL VPN tunnels to same endpoint - possible?

dagibbs — Thu, 25 Nov 2010 01:57:34 GMT

Hi.

I run a pair of PA 2050's on my internet edge, and currently use them for terminating an SSL VPN for staff to remote access internal resources.

I want to put in a second SSL VPN, different IP range, different security zone, much more restricted for contractors/external support staff so I can let them logon and access specific services without giving carte blanche access to the rest of the network.

I tried building another SSL VPN and setting it up on the same external IP (our outside interface), but the OS wouldn't allow me to do so.

Is this possible? Or is there some workaround? Can I use an IP address on another interface (a DMZ) to terminate the second SSl VPN and just have the external staff login to that instead of the main one?

Thanks.

Re: Multiple SSL VPN tunnels to same endpoint - possible?

kbrazil — Thu, 25 Nov 2010 02:14:47 GMT

Hi there,

Yes, this is possible. You can configure multiple SSL VPN Portals on the device but they need to be bound to different IP addresses. One Portal would be for your corporate users and one would be for your external contractors.

You can use any L3 interface or sub-interface, including loopbacks and VLAN Interfaces, to bind the SSL VPN Portals.

Cheers,

Kelly

Re: Multiple SSL VPN tunnels to same endpoint - possible?

dagibbs — Thu, 25 Nov 2010 02:21:22 GMT

Kelly.

OK, so I've got an available IP address on a DMZ interface which is "inside" the normal external address - what security policy would I need to put in place to allow a VPN to terminate on this address? Being that this interface is in the "DMZ" zone?

Or would an interface management profile allowing http/https be sufficient to allow this to work?

Thanks.

Re: Multiple SSL VPN tunnels to same endpoint - possible?

kbrazil — Thu, 25 Nov 2010 04:07:59 GMT

If the IP address in the DMZ is a publicly routable address, then this should be pretty straightforward. You would have a policy from Untrust to DMZ zones allowing any IP to the SSL VPN IP. You would allow SSL, IKE, and IPSEC-ESP-UDP to the IP.

If the IP address is private then you will need a NAT policy in addition to the above Security policy. The NAT policy will be an out-bound source-nat from the SSL VPN IP out to the internet (DMZ to Untrust zone). Make sure the check the "bi-directional" checkbox on the source-nat translation window and you should be set. Put this rule at the top of the NAT policy in case there are other out-bound NAT rules that might take precedence.

Of course you will then need your DMZ to Trust security policies to allow the contractors limited access to the internal resources once the tunnel is established.

Cheers,

Kelly

Re: Multiple SSL VPN tunnels to same endpoint - possible?

dagibbs — Thu, 25 Nov 2010 05:41:36 GMT

hi Kelly.

The DMZ is a public routable IP address, so it should be dead easy.

I just wasn't sure what I'd need to let in from outside to the destination IP address - now I do.

Thanks for your help, and I can go away and set it up now.

Cheers!

Re: Multiple SSL VPN tunnels to same endpoint - possible?

kbrazil — Thu, 25 Nov 2010 20:02:11 GMT

Hey there,

I think my brain was out to lunch - no need for IKE with SSL VPN.

After some digging, here are the correct Apps and Ports to allow for SSL VPN:

web-browsing app-id: this is because the PAN sees the decrypted SSL traffic when the user logs in via the web portal. This will be on TCP port 443. you may optionally wish to allow this on TCP port 80 (in addition to port 443) to allow redirects to port 443 for the user's convenience when they attempt to log into the web portal.

ssl app-id: this is if the user starts the VPN without using the web portal. Also, if SSL transport is being used for the VPN, the tunnel traffic will use this app-id. This will be on TCP port 443

ipsec-esp-udp app-id: this is the how the tunnel traffic will be identified if the IPSEC option is used and successfully negotiated during the session. This will be on UDP port 4501

Cheers,

Kelly