02-12-2014 08:24 PM
Ok here is the situation I have amobility controller plugged into the web, and into an internal network firewall, I have multiple RAP's connected to it via IPSEC, the raps connect and get their vlan/IP information from the mobility controller, where I can asign different gateways, iphelper addresses etc . Pretty straight forward.
here is the sticky part. I want to add VIA Clients to the same controller, useing the same dedicated inbound internet pipe. I want to route all VIA user traffic inbound to the corporate network firewalls and out anopther pipe that has all the wizbang internet firewall and web filtering stuff, a coporation should have infront of their users. I do not want to split tunnel - I want everything coming in and being handled by the controller and passed off to the downstream firewalls.
Do to the fact the Via client configuration utilizes ip addresses assigned by an "ip pool", and not DHCP (either via a helper, or the DHCP server on board the controller) the clients simply get an IP, the DNS settings are provided to the clients by the ipsec profile. Making the default gateway for via clients is essentially the controller itself. (non split tunnel) or the Via Client itself (split tunnel) this is where my problem lies.
The via client can connect, and route to whatever internal vlan's I asign/allow in the profile, however if I open a valid internet address (google.com) on the client machine, the data flows from the controller back out the same internet pipe the VIA Client connection came in on, as it sees itself as conencted to the web.
How can I assign a default gateway other than that of the controller, or the of via client external interface. (Is it even possible)?.
02-13-2014 06:36 AM
All VIA users also get a role. While I have never attempted this, is there a way to edit the role with dst-NAT functions? You would obvioulsly lose client side visiblity but it may work.
Consulting Systems Engineer - ACCX, ACDX, ACMX
If you found my post helpful, please give kudos
02-13-2014 07:15 AM
What I can’t figure is why ARUBA didn’t include an default gateway/router option in the aaa authentication connection-profile or somewhere like “client configuration” “client configuration DNS’ is how you set DNS for the aruba clients, so why not ahve a gateway option.
Seems like as easy add on. But it isn’t available.
02-13-2014 08:34 AM - edited 02-13-2014 10:24 PM
I don't think there's a way to set the DG no, as the traffic is all coming up the IPSEC.
It sounds like what you want is the controller to egress via user traffic in two directions (outbound/inbound) based on where it's heading yes?
I did achieve this in the past as follows.
ip NAT pool aruba-vlan-public-ip <<<PUBLIC IP ADDRESS RANGE HERE>>>
ip NAT pool aruba-vlan-private-ip <<<PRIVATE IP ADDRESS RANGE HERE>>>
network 10.0.0.0 255.0.0.0
network 192.168.0.0 255.255.0.0
network 172.16.0.0 255.240.0.0
ip access-list session src-nat-private-dest-to-inside
user alias private-nets any src-nat pool aruba-vlan-private-ip
ip access-list session src-nat-to-outside
user any any src-nat pool aruba-vlan-public-ip
access-list session src-nat-private-dest-to-inside
access-list session src-nat-to-outside
access-list session v6-allowall
access-list session allowall
EDIT: And then of course add your interior routes (usually all RFC1918 space) via an interior router (static or OSPF), other than the normal default gateway.
02-13-2014 09:17 AM
I want all traffic, minus the traffic needed to to keep the tunnel alive to be pointed to the same gateway. (the router on the private network) The raps work fine as the IP information connected clients get is given out by an internal dhcp server in the private network using a helper address on the vlan interface of the 650 controller (both the 650 and the internal router share a common vlan for routing), the Via clients however get their ip from the ip pool thus there is no way to point them to DHCP.
The Nat Idea might work, if the controller sees all traffic coming from the IPSEC as an internal address. (i think that is what you are telling me)
For instance if my via clients use 18.104.22.168-50 as it's client IP's and a packet destined from 22.214.171.124 is going to google (126.96.36.199) the nat could route it via 188.8.131.52 and I can make sure the router was answering on that IP. Instead of sending it back out the public side of the 650.
02-13-2014 10:03 AM
Ahhh, right I understand what you're trying to achieve now.
No, I don't think this can be done, as you'd need a PBR style function which isn't available.
I might be wrong. Somebody else might have a clever idea?
02-18-2014 04:20 AM
I've just found a command that might be helpful???
In a role, you can (in 184.108.40.206 at least) do a rule like the following...
user any any permit next-hop-list X Y
The X and Y appear to be references to a next-hop-list and hop. I assume these might be defined as netdestinations?
I haven't used this, and I don't know if would work within a VIA user role, but you could look into it? It might resolve your challenge if it does what it sounds like it does?
03-11-2014 04:18 PM
you can do Policy Based Routing Using ESI Group
netdestination student-networks network 10.10.0.0 255.255.0.0 network 172.16.3.0 255.255.255.0 ! esi ping health-30sec frequency 30 timeout 1 retry-count 2 ! esi server student-gateway-1 mode route trusted-ip-addr 172.16.99.7 untrusted-ip-addr 172.16.99.7 ! esi group student-gateway-group ping health-30sec server student-gateway-1 ! ip access-list session "redirect-students" alias student-networks any any redirect esi-group "student-gateway-group" direction forward ! user-role student session-acl logon-control session-acl redirect-students !