Wireless Access

This behavior seems undesirable. If both vlans are "inside" to the controller, why must all packets get nat'd between them? Is there any way around this?

Currently i have two controllers that are connected to each other and i would like to route between vlans 1 and 2 without nat taking place. All three vlans are marked as nat inside, but all traffic from end user vlans is presented as the closest controllers IP address.

VLAN 10 = 10.1.0.0 / 16

VLAN 20 = 192.168.20.0 / 24

VLAN 4090 = 172.16.0.16/29

VLAN10 <---> Controller 1 <----> VLAN 4090 <----> Controller 2 <----> VLAN 20

A ping running from vlan 20 client 192.168.20.20 destined for vlan 10 10.1.30.17 arrives at the client with the source IP of Controller 1s vlan 10 interface.

10:00:08.039516 IP 10.1.0.1 > 10.1.30.17: ICMP echo request, id 1, seq 176, length 40
10:00:08.039572 IP 10.1.30.17 > 10.1.0.1: ICMP echo reply, id 1, seq 176, length 40

Any ideas? Maybe a firewall policy that will shove traffic to be nat'd one way while "internal" traffic does not get nat'd and is allowed to route? I know other vendors used a "nat outside" statement on external facing interfaces, kinda wish i had that for the interface i need to nat out of.

Something is wrong here.  You should not need that...

Whats the default gateway of the controllers?

Do you have it like it? or do you have a L3 swtich connected to any of those controllers?

Thats your enviroment? no tother things are connected to the controllers???? L3 swtich or anything? because this is a routing issue and i would need a picture of everything to help you to fix it...

You should have something like this, thinking its just that 2 controlelrs connnected each other and nothign else.

VLAN10 <---> Controller 1 <----> VLAN 4090 <----> Controller 2 <----> VLAN 20

Default gateway of controller 1 should be ponting to the controller 2 VLAN 4090 ip address

Default gateway of controller 2 should be pointing to the controllers 1 VLAN 4090 ip address.

You should take out the check box of nat and you should enable routing  on vlan 10 and vlan 20 checkbox and also on vlan 4090 interface vlans, on both controller and it should work.

sorry, i didn't put all the other information in trying to keep it simple. the controllers both have their own default gateway pointing out to the world through a different vlan - 4092 which pulls an ip from their respective ISPs and where i would usually put an ip nat outside statement in other vendors. both vlans 10 and 20 should go out their closest controller as their default gateway headed towards the world.

                                  ISP <--------------Internet---------------> ISP

                                    |                                                                |

                           VLAN 4092                                         VLAN 4092

                                    |                                                                |

VLAN10 <---> Controller 1 <----> VLAN 4090 <----> Controller 2 <----> VLAN 20

Okay so basically both controller and on the same site?

but each controller got their own internet?

If the default gateway is pointing to vlan 4092 all you have to do is adding a route in the routing table which tell the controller for example

On controller 1:

192.168.20.0 / 24 via VLAN 4090 ip address of the controller 2

On controller 2

10.1.0.0 / 16 via VLAN 4090 ip address of the controller 1

You missing the routes on the ip route table.

As far im understanding you want to reach vlan 10 and vlan 20 between each controller without natting you want to reach it routing it.... but going  through the vlan 4090. 

I am righ in what you want to do?

Colin,

I get it. I'm not saying you are doing ip nat inside wrong perse, but am looking for a way around the way it works. Seems that nat should only be applied after the packet has been routed and determined that it is leaving an interface that it needs nat on. ip nat outside would be ideal.

NightShade,

The routes are definately there being shared by ospf... It's not an issue of the traffic not knowing where to go, it's an issue of when the traffic gets nat'd.

Controller 1

S* 0.0.0.0/0 [1/0] via 50.21.205.1*
O 10.0.0.0/16 [2/0] via 172.16.0.22*
O 192.168.20.0/24 [2/0] via 172.16.0.22*
C 10.1.0.0/16 is directly connected, VLAN10
C 50.21.205.0/24 is directly connected, VLAN4092
C 172.16.0.16/29 is directly connected, VLAN4090

Controller 2

S* 0.0.0.0/0 [1/0] via 208.117.126.9*
O 10.1.0.0/16 [2/0] via 172.16.0.17*
C 208.117.126.8/29 is directly connected, VLAN4092
C 192.168.20.0/24 is directly connected, VLAN20
C 172.16.0.16/29 is directly connected, VLAN4090

Jim,

Why don't you have a single device, external to the controller do the natting, so that you can have control over this, then?

The way around this (more complicated) is to have Natting be done by the user role on that subnet, so if traffic is going to a private subnet, just permit, but if traffic is going any where else, Nat it.  IP Nat inside was designed to easily Nat traffic for some subnets and not others at the interface level.  If you need more granularity, use the user's role to do this.

Some of this traffic is wired as well. how about a firewall policy applied to the ingress interface?

I was misunderstanding your point sorry.

I think the same way that Collin does... just have an external device doing the nating so you can get control over that
It seems you got the Controller plugged directly to the internet which is not recommended by any way... Controllers are not a security Device.... if you are able get a firewall, it will do the nat for just the packets going outsite and you will get your routing without natting inside your network.

wait a sec... "controllers are not a security device" when i always hear eal firewall etc?

yes it has an integrated firewall but i dotn think they make it for that reason.... its more for inside the lan security not outside facing to the internet... i dotn know if you get my point? you get many good freatures with the build in firewall like clasifying packets they can do many good stuff.... not really related to security with the build in firewall.

What about if you get a mass DoS attack.  Is your controller prepare to face that?

Controller is just not for that...

Colling correct me here if im wrong becasue then i have been thinking wrong all this time...

Nightshade1,

There are quite a few people that use Aruba controllers for firewalling and it works fine.  You must of course use due dilligence and have it protected based on your security profile.  Those users have an ACL that only allows traffic inbounds for ipsec  for maybe Remote APs and VIA clients, but does not allow anything else inbounds.  They also may or may not want to allow other protocols in for remote management, but understand the risk and protect against that accordingly.

Long story short, the Aruba controller can be used effectively as a firewall, but to ensure the correct level of protection, you need to do your homework to ensure that all your bases are covered.  Those steps are not taken automatically.

---

@james.vaught wrote:

wait a sec... "controllers are not a security device" when i always hear eal firewall etc?

---

Jim,

That is Nightshade1's opinion.  But again, you must use the best tools to accomplish what you need.  If you have a wired+ wireless network and you are doing natting at the border with an external appliance, you should continue using that for consistency in terms of troubleshooting, etc.  If you need to selectively do NAT, you can use an ACL in the role, which provides the greatest flexibility, or ip nat inside, which will NAT all the traffic at the VLAN level indiscriminately.  The choice is yours...

is not htat i dont think is not a security device, it just that i think its not made to face the internet... or connect the controller directly to the internet.

IS the controller prepared for attacks from the internet, like massive DoS attacks and things like it Collin?

What device IS designed to protect against a massive DOS attack and how often do they occur?  If your network is being designed to protect against a wired DOS attack, you need to put the infrastructure in place to protect against that.  I am not a security engineer, but there are very few things you can do to protect against a DOS attack.

Yes it just that it does not have dos sensors like a firewall and stuff like that...

Guess i just wanted to know your opinion about it...  as i really really value your opinion!

But i dont think i would recomend it as a device facing internet, which liek you said its my own opinion

To make it clear, quite a few customers use Aruba controllers as firewalls without issue, because Aruba has a built-in stateful firewall (https://www.icsalabs.com/vendor/aruba-wireless-networks).

 There are some people who need more features and functionality that they are used to with their own traditional firewalls.  Those users should continue to use those traditional firewalls so that they can continue to leverage those specific feaures.

Okay thanks for the info Collin!

So Colin,

In your opinion what would a firewall policy that only src nats outbound traffic for specific subnets look like?

---

@james.vaught wrote:

So Colin,

In your opinion what would a firewall policy that only src nats outbound traffic for specific subnets look like?

---

any network <local networks> any permit <--------------------------------Rule for internal traffic

any any any source-nat <nat pool>  <-------------- Rule to source nat traffic out of the egress interface

and when there is no nat pool since only one address comes from dhcp? this is where i get stuck.

You can have the source-nat parameter without any pool.  It will source-nat out the egress interface of the controller, whatever that is.

If you are using the "ip default-gateway import dhcp" command, it will import the default gateway from DHCP, as well.

Take a look at the article here:  http://community.arubanetworks.com/t5/Command-of-the-Day/COTD-Connect-your-Aruba-Controller-to-a-Cable-Modem/td-p/951

It might give you some clues.

doens't look like it wants to work... and before anyone asks about the 4gig etherchannel, my answer is "why not?". anyway, with the below configs as soon as i remove the "ip nat inside" from vlan 10, my traffic stops going to the net.

interface port-channel 0
add gigabitethernet 1/1
add gigabitethernet 1/2
add gigabitethernet 1/3
add gigabitethernet 1/0
trusted
trusted vlan 1-4094
ip access-group "incoming" session vlan 4092
ip access-group "nat_or_not" session vlan 10
switchport mode trunk
!

ip access-list session incoming
any any tcp 3001 dst-nat ip 10.201.254.254 2001
any any tcp 3002 dst-nat ip 10.201.254.254 2002
any any tcp 3003 dst-nat ip 10.201.254.254 2003
any any tcp 3004 dst-nat ip 10.201.254.254 2004
any any tcp 3005 dst-nat ip 10.201.254.254 2005

!

ip access-list session nat_or_not
any network 10.0.0.0 255.0.0.0 any permit
any network 192.168.0.0 255.255.0.0 any permit
any network 172.16.0.0 255.255.0.0 any permit
any network 224.0.0.0 255.0.0.0 any permit
any any any src-nat

!

interface vlan 10
ip address 10.1.0.1 255.255.0.0
ip nat inside
operstate up
description "***Internal Network***"
!
interface vlan 4092
ip address dhcp-client
operstate up
description "***Internet***"
!

ip default-gateway import dhcp 1

Can you see if the traffic is even hitting that rule (show acl hits)?

i moved the source nat statement between 4092 and 10. on 10 it didn't pick up any hits but it did on 4092. still didn't get any replies from my ping either way.

The any any any source-nat statements need to go in the USER role, NOT on the interface ACL...

All the statements below need to be in the user role:

ip access-list session nat_or_not
any network 10.0.0.0 255.0.0.0 any permit
any network 192.168.0.0 255.255.0.0 any permit
any network 172.16.0.0 255.255.0.0 any permit
any network 224.0.0.0 255.0.0.0 any permit
any any any src-nat

so i need to make my wired vlans all untrusted to get the traffic processing the firewall?

If you have wired traffic, yes, because it has to be processed through the ACL to permit routing.

If this is too much trouble, a border firewall/router  is in your future.

still no luck. wired users in untrusted vlan getting default role authenticated, traffic looks like it is hitting the src nat rule but still not going anywhere.

10.1.30.15 00:23:df:86:9d:ac authenticated 00:00:00 tunnel 1 Wired wired tunnel
10.1.30.17 e8:06:88:ca:e7:3f authenticated 00:00:00 tunnel 1 Wired wired tunnel

show rights authenticated

Derived Role = 'authenticated'
Up BW:No Limit Down BW:No Limit
L2TP Pool = default-l2tp-pool
PPTP Pool = default-pptp-pool
Periodic reauthentication: Disabled
ACL Number = 60/0
Max Sessions = 65535

access-list List
----------------
Position Name Type Location
-------- ---- ---- --------
1 nat_or_not session
2 allowall session
3 v6-allowall session

nat_or_not
----------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6
-------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ ------- ------------- ------
1 any 10.0.0.0 255.0.0.0 any permit Low 4
2 any 192.168.0.0 255.255.0.0 any permit Low 4
3 any 172.16.0.0 255.255.0.0 any permit Low 4
4 any 224.0.0.0 255.0.0.0 any permit Low 4
5 any any any src-nat Low 4
allowall
--------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6
-------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ ------- ------------- ------
1 any any any permit Low 4
v6-allowall
-----------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6
-------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ ------- ------------- ------
1 any any any permit Low

show acl hits

(Jim-3200) (config-subif)#show acl hits

User Role ACL Hits
------------------
Role Policy Src Dst Service Action Dest/Opcode New Hits Total Hits Index
---- ------ --- --- ------- ------ ----------- -------- ---------- -----
authenticated nat_or_not any 10.0.0.0 255.0.0.0 any permit 87 87 8682
authenticated nat_or_not any 224.0.0.0 255.0.0.0 any permit 5 5 8685
authenticated nat_or_not any any any src-nat 444 444 8686

What is the default gateway of all your wired clients?  Can they ping their default gateway?  Can they ping the public ip address of the controller?

yes to both. default gateway of the cilents is the controller vlan 10 interface 10.1.0.1

---

@james.vaught wrote:

yes to both. default gateway of the cilents is the controller vlan 10 interface 10.1.0.1

---

So if a client can ping his default gateway and can ping his next hop, at east that is working.  Can it ping beyond the next hop?

clients cannot ping past the point where traffic should be nat'd.

if the packets dont need nat they can go all the way to destination.

While you are passing traffic, type "show datapath session table <ip address of client>" to see how the traffic is being processed.

---

@james.vaught wrote:

This behavior seems undesirable. If both vlans are "inside" to the controller, why must all packets get nat'd between them? Is there any way around this?

 

Currently i have two controllers that are connected to each other and i would like to route between vlans 1 and 2 without nat taking place. All three vlans are marked as nat inside, but all traffic from end user vlans is presented as the closest controllers IP address.

 

VLAN 10 = 10.1.0.0 / 16

VLAN 20 = 192.168.20.0 / 24

VLAN 4090 = 172.16.0.16/29

 

VLAN10 <---> Controller 1 <----> VLAN 4090 <----> Controller 2 <----> VLAN 20

 

A ping running from vlan 20 client 192.168.20.20 destined for vlan 10 10.1.30.17 arrives at the client with the source IP of Controller 1s vlan 10 interface.

 

10:00:08.039516 IP 10.1.0.1 > 10.1.30.17: ICMP echo request, id 1, seq 176, length 40
10:00:08.039572 IP 10.1.30.17 > 10.1.0.1: ICMP echo reply, id 1, seq 176, length 40

 

Any ideas? Maybe a firewall policy that will shove traffic to be nat'd one way while "internal" traffic does not get nat'd and is allowed to route? I know other vendors used a "nat outside" statement on external facing interfaces, kinda wish i had that for the interface i need to nat out of.

---

James,

This is the definition of "ip nat inside" on every other firewall platform.