Cisco ASA vpn and HP procurve Vlans

The Spyder

2[H]4U
Joined
Jun 18, 2002
Messages
2,628
I need to clear my head a bit, things are so busy at work I am having trouble sorting out a simple routing issue.

I have a Cisco ASA 5515-x, setup as my router with a split-tunnel SSL VPN for remote users.. It works great, except when connected via VPN I can only access the same subnet the ASA and HP switch reside on. My VLANs provided via my core HP 5406zl L3 switch are inaccessible. This must just be a simple routing issue, but between Cisco and HP I can not wrap my head around it.



Comcast---> Cisco ASA (VPN) 10.20.28.1 ---> HP (vlans)-----> VLAN 1 10.20.28.254 (Works fine over VPN), VLAN 45 -10.20.45.254 (No access over vpn), VLAN 99- 10.20.99.254 (No access over vpn)


Intervlan routing works great, I can access VLAN 99 from VLAN 1 and vise-versa. I have a route on the HP switch for 0.0.0.0 0.0.0.0 10.20.28.1 for internet access. On the Cisco I have a static route of 10.20.0.0 255.255.0.0 10.20.28.254. I believe my issue is that the HP requires your default gateway to be your VLAN IP for the intervlan routing to work. With my split tunnel SSL VPN, I do not believe it uses the correct routes.

My question is: Where and what routes do I need to add so that I can access the other VLANs when connected via VPN?

I have a test environment setup and I am going to start testing by disabling split tunneling to see if I can access the other VLANs.
 
Last edited:

djflow195

Weaksauce
Joined
Sep 6, 2011
Messages
102
Verify connectivity to each VLAN from the ASA itself. ASA has to see all the VLAN subnets to route correctly.

Verify the split tunnel contains the entire 10.20.0.0/16. If it only contains 10.20.28.0/24 that explains why you cannot access the other subnets via the tunnel.

Traceroute the gateway in each VLAN via the tunnel.

What is the tunnel subnet? Is it in 10.20.0.0/16 by any chance? Use more specific static routes: 10.20.45.0 255.255.255.0 10.20.28.254 and 10.20.99.0 255.255.255.0 10.20.28.254
 

Langly

Supreme [H]ardness
Joined
Dec 23, 2002
Messages
4,387
To add to whats being said, What subnets are being tagged by your ACL for the split tunnel itself? Can you post your config as well on your ASA?
 

The Spyder

2[H]4U
Joined
Jun 18, 2002
Messages
2,628
Thanks guys. My lab ended up being very useful. I disabled split tuneling and everything works (except internet- I do not want to feed VPN users internet traffic through the ASA). I will start looking at the suggestions next.

I'll get a scrubbed config up.
 

The Spyder

2[H]4U
Joined
Jun 18, 2002
Messages
2,628
Verify connectivity to each VLAN from the ASA itself. ASA has to see all the VLAN subnets to route correctly.
I can ping each VLAN from the ASA. When not using split-tunneling, it works fine.

Verify the split tunnel contains the entire 10.20.0.0/16. If it only contains 10.20.28.0/24 that explains why you cannot access the other subnets via the tunnel.

10.20.0.0/16 is correct.

Traceroute the gateway in each VLAN via the tunnel.
Nothing, which makes me think I will need to add more specific routes.

What is the tunnel subnet? Is it in 10.20.0.0/16 by any chance? Use more specific static routes: 10.20.45.0 255.255.255.0 10.20.28.254 and 10.20.99.0 255.255.255.0 10.20.28.254

Tunnel subnet is 172.16.1.x 255.255.255.0.
Trying the specific routes now.

Thanks!
 

The Spyder

2[H]4U
Joined
Jun 18, 2002
Messages
2,628
Hahaha, figured it out and even in the production environment. A while back I tried adding the management interface to my IT VLAN (10.20.99.x). There is a bug with HP switches where unless something has been/is on the VLAN, the default gateway will not respond. I was only testing connectivity with the IT VLAN 99. The last time I tested this, I had nothing on other VLAN's. Now that I moved things around and had devices on other VLAN's, I tried VLAN 66 (voice) and VLAN 10 (servers)- both responded. Realizing that there was something wrong with the route for VLAN 99, I pulled the routes from the ASA and saw 10.20.99.0 was bound to management. I shutdown the management interface (not being used ATM) and unbound the 10.20.99.1 address it was assigned. A quick reset, and BAM. Everything is working :D.
 
Top