Cannot access SSLVPN protected application in Kiosk mode due to Firewall issues

  • 7001474
  • 02-Oct-2008
  • 26-Apr-2012

Environment

Novell Access Manager 3 SSLVPN Server
Novell Access Manager 3 Support Pack 4 applied
SSLVPN server has 3 IP addresses (primary and two aliased)
SSLVPN server protecting back end Citrix server
Firewall sitting between SSLVPN server and Citrix server and only allowing packets through with a specific IP address. This IP address is NOT the primary IP address of the SSLVPN server, but one of the aliased IP addresses

Situation

When connection request comes in from SSLVPN client in Kiosk mode, everything appears to be healthy 
- the policies for that user also indicate that the CItrix server is available. When the user then
tries to access the Citrix server, a connection failed message is returned to the application ie.
the user cannot connect to the Citrix server. Everything works fine in Enterprise mode.

Trying to netcat to TCP 1494 from the SSLVPN server also results in the lack of connectivity. In Kiosk mode
if the SSLVPN server cannot connect to the back end application, the client will never be able to do so. Using
tcpdump (tcpdump -i any -na port 1494) to check the requests, the administrator could see that the source IP
address of the outbound requests was the primary interface IP address. The intermediate firewall was blocking the
request as it only allowed requests with the aliased IP address thru.

Resolution

Add an entry to the routing table so that requests going to a specific destination (the Citrix server)
use the non default primary IP address. The option is available for all systems running the iproute2
packages.

We added a route entry to the local table using the following command (the 'src' IP address is the IP
address that the Citrix server expects requests to come in on)

> # ip route add 172.66.95.17 via 172.2.22.248 src 172.2.22.243 table local

We can confirm the route is added using the following

> # ip route list table local
> broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
> broadcast 172.22.2.255 dev eth0 proto kernel scope link src 172.22.2.246
> local
172.66.95.17 dev eth0 proto kernel scope host src 172.2.22.248 <-----> this is what gets added
> local 172.22.2.243 dev eth0 proto kernel scope host src 172.22.2.246
> local 172.22.2.248 dev eth0 proto kernel scope host src 172.22.2.243
> local 172.22.2.246 dev eth0 proto kernel scope host src 172.22.2.246
> broadcast 172.22.2.0 dev eth0 proto kernel scope link src 172.22.2.246
> broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
> local 172.22.2.244 dev eth0 proto kernel scope host src 172.22.2.246
> local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1

From this point on, the request from the SSLVPN server to the Citrix server used the aliased source IP
address, which the firewall allowed through.