Redirect-All OnDemand Tunnel Loses Connection to WorkPlace Site with Custom Host and Domain Name

03/26/2020 5 People found this article helpful 97,096 Views

Download

Print

Share

• LinkedIn
• Twitter
• Facebook
• Email
• Copy URL The link has been copied to clipboard

Description

Redirect-All OnDemand Tunnel Loses Connection to WorkPlace Site with Custom Host and Domain Name

Resolution

Problem Definition:

When a WorkPlace site uses a custom host and domain name, associated with its own virtual IP address, OnDemand Tunnel users may lose access to WorkPlace if OnDemand tunnel is running in redirect-all mode.  This issue can occur in networks where the WorkPlace virtual IP address is obscured behind a NAT device, such as a router or firewall.  OnDemand Tunnel assumes that that NAT'ed virtual IP address should be routed over the tunnel connection.  Once that traffic traverses the tunnel, the appliance cannot route it back to WorkPlace.

Resolution or Workaround:

In the following steps, a firewall is used to route the tunnel traffic back to the external interface of the Aventail appliance.  Followthese steps is a description of the flow of traffic in this configuration.  All of these steps were performed in a lab environment, which explains why private address space was used.

Network environment parameters:

• Aventail appliance is dual-homed and in dual-gateway mode. For our testing, the eth0 (internal) IP is 10.20.100.122, and the eth1 (external) IP is 10.0.100.122. The WorkPlace Virtual IP is at 10.0.100.135 on eth1.
• Aventail appliance external (eth1) default gateway is 10.0.100.1 (NSA appliance DMZEX zone or X3 interface).
• Aventail appliance internal (eth0) default gateway is 10.20.100.1 (NSA appliance DMZIN zone or X2 interface).

Configuration steps:

1. On the appliance, one redirect-all realm was configured, bound to the Workplace VIP site as vip135.testdom2k3.com, which resolves (both externally and internally) to 192.168.200.135. Note that we are assuming redirect-all is being used for Internet access through the appliance, and there is an Any -> Any ACL in the appliance that facilitates access to the Workplace public VIP (192.168.200.135). More on that below.
2. Default Workplace site set to 192.168.200.122, which is where the tunnel will actually be established when OnDemand Tunnel starts up.
3. NSA appliance has a static route for the tunnel pool (172.1.1.0/24) to the DMZIN interface X2.
4. NSA appliance has an ANY source NAT rule that allows traffic such as the following (this translates requests for VIP  ‘vip135.testdom2k3.com’ (192.168.200.135 to 10.0.100.135):
   Source: Any
   Original Destination: 192.168.200.135
   Translated Destination: 10.0.100.135
   Services: TCP/443, TCP/80
5. NSA appliances WAN to DMZEX firewall ACL has an ANY source rule that allows traffic such as the following (this allows external clients to hit the public VIP vip135.testdom2k3.com (192.168.200.135)):
   Source: Any
   Destination: 192.168.200.135
   Service: TCP/443, TCP/80
6. NSA appliances DMZIN to DMZEX firewall ACL has an Tunnel source rule that allows traffic sourced from the tunnel pool (172.1.1.0/24) to get access to the public Workplace VIP (192.168.200.135):
   Source: 172.1.1.0/24
   Destination: 192.168.200.135
   Service: TCP/443, TCP/80

Sequence of events with OnDemand Tunnel + Redirect All + Workplace VIP:

1. Users browse to https://vip135.testdom2k3.com in IE. This resolves to 192.168.200.135, so they reach the front of the NSA, and match items 5 and 6 above.
2. Tunnel is established on 192.168.200.122; they reach WorkPlace with links presented.
3. A user opens a command prompt, and pings something on the backend (LABIN zone on the NSA). The source ICMP packets are from 172.1.1.1 (tunnel IP on client), and the destination is 10.10.100.75 (an AD server on another interface of the NSA, LABIN or X4). Because of this, he or she does not match numbers 5/6/7 above, and gets access to backend resources as usual.
4. A user now clicks on a link in WorkPlace, which spawns a new IE window, and looks something like this (OWA is the alias):
   https://vip135.testdom2k3.com/OWA/exchange/login.aspx
5. Since the tunnel client is connected to a realm with redirect-all enabled, it adds whatever vip135.testdom2k3.com resolves to (in our case 192.168.200.135) to the redirection list, and sends it across the tunnel.
6. The request reaches the Aventail appliance on eth0. The source is 172.1.1.1 (tunnel IP on client), with the destination as 192.168.200.135. Since 192.168.20.135 does not exist on eth1, it follows the standard route to internet gateway rule, and the appliance routes the request out eth0 to the next hop router (10.20.100.1, the NSA firewall).
7. The NSA firewall sees the source as the tunnel pool, with a destination of 192.168.200.135, so the first thing to hit is the firewall ACL (number 7 above). It matches, which allows us access to the public side of the Workplace VIP. The next thing that fires is the NAT rule on the NSA.
8. The NAT rule (number 5 above) triggers a translation for 192.168.200.135 to 10.0.100.135, and sends the request out via DMZEX or X3 interface.
9. The Aventail appliance sees the request as sourced from 172.1.1.1 and destined to 10.0.100.135. Since 172.1.1.0/24 is not referenced in its routing tables anywhere, the appliance (Extraweb) happily responds to the request, and sends the data back the way it came.

Related Articles

• CT with Device Guard is stuck on Identifying when GVC Client is installed
• SMA1000: CT compatibility with 3rd party VPN clients like GVC, Citrix and Fortinet
• How can I upgrade firmware in SMA 1000 series appliance?

Categories

• Secure Mobile Access > SMA 1000 Series