I finally got my hands on some of the Wing products.
I now have a requirement form a client and require some assistance. (Still new to the product)
The Client currently has a RFS4000 with some AP's deployed.
He is running a Corporate SSID that is natted to the "Uplink port" on the RFS4000
The clients connecting to this Corporate SSID receives a IP from the RFS4000 in the VLAN.
The RFS4000 then NATS the wireless client traffic to the internal LAN via the Uplink port on the RFS4000
The client now wants to add another SSID for guests, this will be a open SSID with not authentication (The client will implement a upstream captive portal). The client wants to route the guest traffic over a completely seperate uplink (ge5) that will ge connected to the same router used for corporate but on a different interface.
This wireless guest traffic must also be natted to this uplink (ge5).
The network diagram below
First question can I specify more than one interface as "NAT outside"?
I have tested using PBR but it seems to always route via the uplink port vlan...
I haven't tried this, so I don't know if it will work, but here's what I would do...
Create two "outside" VLANs:
Enable dhcp in both of them and configure them as ip nat outside.
config self interface vlan100 ip address dhcp ip nat outside interface vlan200 ip address dhcp ip nat outside exit
Create your "inside" vlans:
Configure their local IP addresses and configure them as ip nat inside
config self interface vlan10 ip address 192.168.10.1/24 ip nat inside interface vlan40 ip address 192.168.40.1/24 ip nat inside exit
Configure interface ge1 as trunk including vlans 100 & 200 tagged
config self interface ge1 switchport mode trunk switchport trunk native vlan 1 no switchport trunk native tagged switchport trunk allowed vlan 1,100,200 exit
Create two Access lists:
- nat1-rule: allows ip addresses from vlan 10
- nat2-rule: allows ip addresses from vlan 40
config ip access-list nat1-rule permit ip 192.168.10.0/24 any rule-precedence 10 ip access-list nat2-rule permit ip 192.168.40.0/24 any rule-precedence 10 exit
Create a rule that allows nat from addresses in nat1-rule to vlan100
Create a rule that allows nat from addresses in nat2-rule to vlan200
config self ip nat inside source list nat1-rule precedence 1 interface vlan100 overload ip nat inside source list nat2-rule precedence 2 interface vlan200 overload exit
If everything works as expected, vlan 10 addresses should nat using vlan 100 ip address, and addresses from vlan 40 should nat using vlan 200 ip address.
Let me know if this works as expected.
All CLI commands to do this:
! ip access-list nat1-rule permit ip 192.168.10.0/24 any rule-precedence 10 ! ip access-list nat2-rule permit ip 192.168.40.0/24 any rule-precedence 10 ! vx9000 00-0C-29-CA-0E-38 interface ge1 switchport mode trunk switchport trunk native vlan 1 no switchport trunk native tagged switchport trunk allowed vlan 1,100,200 interface vlan1 ip address 10.1.1.70/24 interface vlan10 ip address 192.168.10.1/24 ip nat inside interface vlan40 ip address 192.168.40.1/24 ip nat inside interface vlan100 ip address dhcp ip nat outside interface vlan200 ip address dhcp ip nat outside
ip nat inside source list nat1-rule precedence 1 interface vlan100 overload ip nat inside source list nat2-rule precedence 2 interface vlan200 overload
The main challenge is that the RFS does not have multiple virtual routers (Extreme: This would be an awesome add-on to the data-plane), meaning that all layer 3 traffic, unless prohibited by ACLs is visible between subnets. (ie: vlan 10 and vlan 20 can "see" each other).
This also explains why NAT outside doesn't do what you expect it to. The router instance in the RFS can only have one default gateway, and PBR is just a kludge to get around the fact that there aren't multiple virtual-routers.
There are several ways to tackle the problem, and Extreme has lots of docs about their captive portal functionality, etc, but personally, I find it much easier to treat any guest traffic as layer 2 only and allow other upstream devices (routers/firewalls/portals) to take care of the nuts and bolts of the layer 3 portion (dhcp/dns/etc). This way, it is completely isolated from the corporate environment. Call me paranoid, but I don't trust the guests and don't want to offer them any exposure to the infrastructure, beyond transporting their traffic at layer 2.
That being said, in your scenario, I would tackle it in one of two ways, preferring the second way as it does not create a bottleneck at the controller :
Tunnel the guest SSID back to the RFS on its own VLAN, and then configure ge5 to be an access port on that particular vlan. This will forward the layer 2 traffic out ge5 and into the router/portal/firewall which would provide the DHCP and NAT services.
Bridge the guest SSID into its own VLAN that is back-hauled through your infrastructure and configure an appropriate switch port in access mode on that VLAN and connect it to the router/portal/firewall interface, which would provide the DHCP and NAT services.
In both cases, because you are potentially setting up multiple layer 2 paths between two devices, be sure that spanning tree is not enabled on the RFS (default is off anyway).