Wireless Access

I am (was) trying to design a VPN solution where I would assign VPN addresses to VIA clients from 3 different pools based on user roles, then use our existing firewalls to manage traffic based on those IPs. The idea was something like this:  (Of course these are fake addresses, but it is still all public IP space.)

 

External (edge router) connection 1.1.1.1/30

LAN connection 2.2.2.1/30

 

Default route 1.1.1.2

Internal networks learned via OSPF.

 

VPN pools 3.3.3.0, 4.4.4.0, 5.5.5.0

Static routes back to these pools in core.

 

After much head scratching and an assist from TAC, the only way we could get even one pool to pass traffic was to use NAT. Not just any NAT either, but a single IP NAT pool that translates everything to the outgoing interface address.

 

Now, I can see how to set things up so that each role goes to a different interface/NAT address.  But I cannot for the life of me understand why there is an option to have multiple VPN address pools if the clients have to be translated anyway.  Am I missing something?  Better yet, does anyone here know something TAC didn't?

Andrew Bell,

 

In the simplest form, for clients to work without NAT translation  (source nat), you should just be able to give your controller a routable VLAN interface in whatever pool you want, and your infrastructure would need a static route back to the controller for that to work.

 

If your pool is 2.2.2.2-2.2.2.5, you would need an ip interface:

 

config t

interface vlan 20

ip address 2.2.2.2 255.255.255.0

 

You would just put you clients into that 2.2.2.2 pool and as long as there is a route from your infrastructure back to the controller for 2.2.2.x, and your VIA client has an ip address in the pool, the controller will answer for any address that is in the pool.  I am not sure about layering OSPF on top of it the way you want it, but this basic configuration should work without NAT first...

 

Hi Colin;

 

That's exactly how I expected it to work.

 

My really simple base config for testing is this:

 

2.2.2.192/26 is the network.  .193 is the VLAN interface.  .194 is the attached switch interface.  .195-.254 is the address pool. From the 7010, I can ping the switch and vice versa.

 

NAT all to 2.2.2.193 - everything works as expected.  No NAT - can't ping even the switch interface from the client.

 

Tried with static routes and with OSPF, makes no difference.

 

Anything jump out at you?

Are you doing anything like split tunneling? What are the acls on the user's final role?

Split tunnelling makes no difference.  ACLs are allowall.

I just set up something similar that seems to works without any issues. (still busy testing it all though)

 

2 different pools: ie. 10.10.10.0/24 and 20.20.20.0/24

The controller has no interface in these ranges. The controller only has a single  /30 interface (lets say 30.30.30.1) to the firewall (30.30.30.2)

The controller only has a default gateway to 30.30.30.2.

The firewall has 2 static routes for 10.10.10.0/24 and 20.20.20.0/24 towards the controller 30.30.30.1.

 

That's it.. Everything has correct connectivity.

The common theme from people who have this working seems to be that their the controller only has a one physical interface with a default gateway out to their LAN.  I have an outside interface with a default route to the internet and an inside interface running OSPF to maintain routes to/from the LAN.

 

I've done a couple more tests with the VPN pool configuration, and the packets from the clients never arrive at their destination.  So, not a problem with routing traffic back to the controller.  

 

My current best guess is that traffic from the VPN is only getting the default gateway and not having the whole routing table applied.  My next step will be replacing OSPF with static routing, and if that fails, a single interface model.

The user traffic should follow the routing of the controller. When you connect t using VPN what role does your user get? Is the pool routable to the rest of your network? You should type "show datapath session table <IP address of your VPN client>" to see if traffic is getting blocked or routed.

Should be, yes.

 

This is the frustrating part.  I have a custom role with vpn-pool1 assigned, and firewall rules are NAT, the allowall. This works.  I switch it to vpn-pool2, which includes the NAT address from before, remove NAT from the policy, and it doesn't work anymore.  Same IP, same role, the only difference is whether it's natted or directly assigned.

 

If I monitor the traffic on an inside host, and ping using the non-NAT configuration, the packets never arrive.  I think this eliminates the return routing from the equation.

 

When I first lab'd this up using a single interface and default gateway, it also worked fine.  

 

 

Do you have an interface on the controller in the subnet of the NAT pool, when you remove the NAT rule?

Thanks to everyone for their input.  At the end of the day, the only way I can get VPN pools to work is to have only a single interface from the controller to the network.  Having both an internal and external network connection simply would not work unless I used NAT.

 

Andrew