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).