NAT of whole subnet
-
Just route 10.16.16.0/20 from the ASA to the captive portal unit and disable NAT on pfSense. There is zero reason to NAT on the inside like that.
Generally: disable outbound NAT on WAN for source 10.16.16.0/20.
So your suggesting that the LAN and WAN interface would have different IP addresses on the same subnet? e.g. perhaps LAN is 10.16.16.1, WAN is 10.16.16.2 and the Firewall is 10.16.16.3 and then hand out 10.16.16.4 - 10.16.31.254 in the DHCP scope?
-
No that is not what he is suggesting..
The wan of pfsense would be a transit network if there is an upstream router/firewall.. Ie your ASA.. So you would have something like this
internet - publicIP asa 172.16.0.1 – transit 172.16.0/30 --- 172.16.0.2/30 pfsense 10.0.0.1/20 -- devices on 10.0.0/20
But I personally would just have multiple segments behind pfsense.. so your not using such a large broadcast domain.. Guess the one advantage to using such a large segment for your clients is if you had clients jumping from AP to AP that were on different segments you could run into some dhcp issues..
But there really is no reason to nat between your transit network and your clients at pfsense.
Your asa is what would nat your 10 addresses to your public.
-
If you have an upstream ASA.. why would pfsense wan be a /20?? There should be an transit network to your asa.. like a /30 maybe a 29 if you have multiple routers on this transit..
The ASA with FirePOWER has UTM capabilities pfSense can only dream of so when a client does reach it, it's important that it's the client's real IP address (or something that is derivative of it). They want all the APs on the same subnet so seamless roaming can happen and there will be a couple if Wifi SIP phones that need to hand off from one AP to another without changing IP address as that would drop the call in progress. We do it in another building and the phones really do roam from one AP to another and keep the call going but that certainly won't be the case if I break up the broadcast domain.
It's not often that there will be thousands of people in the building but at times there will be thousands of people in the building and every one of them on the Wifi if they can be.
-
"it's important that it's the client's real IP address"
Yeah ok, which is why you wouldn't nat at pfsense.. And just route the traffic to your asa via a transit.
In this scenario
internet - publicIP asa 172.16.0.1 – transit 172.16.0/30 --- 172.16.0.2/30 pfsense 10.0.0.1/20 -- devices on 10.0.0/20Your ASA would see the 10.0.0.x address of your client directly..
Doing a 1to1 nat of rfc1918networkA/20 to network1918networkB/20 is completely pointless.. The only reason you would ever need to do such a thing is for example you had 2 companies that need to talk to each other and they were using the same rfc1918 address space and neither of them were willing to change to a different address space.
-
Yeah ok, which is why you wouldn't nat at pfsense.. And just route the traffic to your asa via a transit.
In this scenario
internet - publicIP asa 172.16.0.1 – transit 172.16.0/30 --- 172.16.0.2/30 pfsense 10.0.0.1/20 -- devices on 10.0.0/20
Your ASA would see the 10.0.0.x address of your client directly..OK! I'm going to give it a try that way and see if I can make it work. Thanks for the help! I'll post back here and let you know how it worked out.
-
Multiple segments on a public wifi like that gets problematic because there is no requirement to renew dhcp when you roam from AP to AP so users end up with the wrong IP address for the segment they're now connected to.
Some of the controllers have the ability to roam the VLAN with the users and some even talk to the switch to enable/disable VLANs on specific ports as necessary. But reducing the broadcast domain from one into several can help even if all the VLANs go to all APs all the time because the object is generally to get the broadcast traffic off the air, not off the gig switchports to the APs. Some tunnel all traffic to the controller via L2TP and roam users around that way. It's a non-trivial problem.
At a minimum you can get different broadcast domains needing to broadcast at different times and not everything everywhere all at once.
-
Yeah I understand if you have clients roaming from AP to AP the different segments can be an issue. I mention that in my post ;)
So sure use of larger network is a simple solution to the yes completely agree can be non-trivial problem. The cisco WLC normally tunnel all the traffic back to the controller.
Since he has a large area where users most likely do a lot of moving around it would be more of an issue than in say an office building where users are tied more to a specific location and only few AP in the area. In his scenario guessing they could be roaming to multiple AP as they skate around the ice even..
-
Caught perusing instead of reading.
-
Yeah it's about 40 X 802.11ac wireless access points for a guest network in a huge building
I hope you're not planning on doing this with a bunch of independent APs. The proper way to do this is with dumb access points and a central controller. Cisco gear can provide this, though there are others. That way, no matter what AP you're connected to, you're logged into the controller and can move seamlessly among APs. With Cisco APs, you'd also need a switch with the controller software loaded. Also, make sure the access points have a suitable radiation pattern. Most APs are designed for use without a lot of vertical separation from users. Arenas tend to have very high ceilings.
-
And just route the traffic to your asa via a transit.
Your ASA would see the 10.0.0.x address of your client directly..Yes, I have to agree that is a better approach and it even worked! Thanks again!
-
I hope you're not planning on doing this with a bunch of independent APs. The proper way to do this is with dumb access points and a central controller. Cisco gear can provide this, though there are others. That way, no matter what AP you're connected to, you're logged into the controller and can move seamlessly among APs. With Cisco APs, you'd also need a switch with the controller software loaded. Also, make sure the access points have a suitable radiation pattern. Most APs are designed for use without a lot of vertical separation from users. Arenas tend to have very high ceilings.
No, nothing that silly. It's Ubiquity APs with a controller. I might have been Cisco's biggest fan (our networks otherwise are pure Cisco) but they lost us with the 1852i Mobility Express fiasco where the whole thing kept going down, it was a known problem, it was fixed in version whatever but Cisco TAC couldn't provide the fixed software. That was at least 9 months ago and I just saw another person fall victim to the same issue and the fixed software still isn't available.
We ended up returning them all as defective under the 90 day warranty.We did many years ago have autonomous APs from Cisco and our phones roamed seamlessly with no controller. It was only a matter of using the same SSID and having them all on the same layer-2 segment.
-
-
Glad to hear, but really there was never a question that it was a better approach and would work ;)
Natting has always been a workaround/hack to networks that overlap or napt when you need to have many IPs share the use of single ip. This work around sometimes is useful in rfc1918 space a quick and dirty way to get something done.
But in general if there is no absolute reason to nat, then you shouldn't.. If its rfc1918 to rfc1918 and you control both sides then not the way to do it.. And transit networks you would think were some new concept or something. I don't really understand the almost daily posts where they come up, the most common being asymmetrical routing issues because they didn't use a transit.
