NAT of whole subnet



  • So I want to NAT a LAN interface 10.16.16.0/20 to WAN 172.16.16.0/20 and I know it's a simple thing to do but I've been trying and can't get it to work. I've even found a lot of questions in the forum asking how to do this and the answer always seems to be that you don't want to, but I really do want/need to.

    When the traffic gets to the real firewall and it tells me the system has a virus, it's not helpful if I can't relate that to the real IP address of the user and it's all 1 IP on the WAN interface by that time. If I bridge it, then I can't do a captive portal.

    Does anyone know how to NAT 4000 address to 4000 address so that 10.16.16.123 becomes 172.16.16.123 and there is a direct relationship?  Very easy to do on a Cisco router or firewall, also easily done on pfSense if you get everything right and obviously I'm missing something.

    Any help appreciated.


  • Rebel Alliance Global Moderator

    Why are you natting rfc1918 to rfc1918 in the first place?  Why not just turn nat off on pfsense??

    At a loss to why anyone would do this??  Also /20 pretty freaking large broadcast domain..  You have 4K devices on the same layer 2??



  • @johnpoz:

    Why are you natting rfc1918 to rfc1918 in the first place?  Why not just turn nat off on pfsense??

    If I don't NAT it then it's BRIDGEd and the captive portal won't work with a bridge interface.

    @johnpoz:

    Also /20 pretty freaking large broadcast domain..  You have 4K devices on the same layer 2??

    Yeah it's about 40 X 802.11ac wireless access points for a guest network in a huge building (skating rink with 3 ice surfaces) so there could be a couple of hundred clients on each of the 40 access points.


  • Netgate

    @smoores:

    @johnpoz:

    Why are you natting rfc1918 to rfc1918 in the first place?  Why not just turn nat off on pfsense??

    If I don't NAT it then it's BRIDGEd and the captive portal won't work with a bridge interface.

    How is this NAT going to eliminate a bridge? More info needed.

    @johnpoz:

    Also /20 pretty freaking large broadcast domain..  You have 4K devices on the same layer 2??

    Yeah it's about 40 X 802.11ac wireless access points for a guest network in a huge building (skating rink with 3 ice surfaces) so there could be a couple of hundred clients on each of the 40 access points.

    Yeah in that case your enemy is going to be DHCP pool size since you will need a lease for everyone who walks in and leaves even if they don't use the internet since after they use it once their phone will probably auto-join every time they come into range. DHCP lease is used even if they do not go through the captive portal. Generally, if you isolate the network properly, the only broadcasts that go out to everyone are those from the central gear itself so you can likely get away with more nodes on a broadcast domain. But a couple hundred is easily doable if your APs can handle it. Your density estimate seems pretty high to me though. But better to estimate high than low.



  • @Derelict:

    How is this NAT going to eliminate a bridge? More info needed.

    If I don't NAT then I don't get to have a captive portal. If I NAT the whole subnet to one IP address then the firewall tells me I have a virus transmitting from that address (which is the same for 2,000 users) so that's not helpful.
    @Derelict:

    Yeah in that case your enemy is going to be DHCP pool size since you will need a lease for everyone who walks in and leaves even if they don't use the internet since after they use it once their phone will probably auto-join every time they come into range. DHCP lease is used even if they do not go through the captive portal. Generally, if you isolate the network properly, the only broadcasts that go out to everyone are those from the central gear itself so you can likely get away with more nodes on a broadcast domain. But a couple hundred is easily doable if your APs can handle it. Your density estimate seems pretty high to me though. But better to estimate high than low.

    If you saw the size of the building and the amount of metal and concrete it's constructed from my density estimate isn't high. We have about 20 APs installed now and coverage is very spotty.  All the APs are run by the same controller that will proactively adjust transmit power and channels to provide the best coverage it can.

    If I can NAT 10.16.16.0/20 to 172.16.16.0/20 at least when the firewall tells me I have a virus on 172.16.18.243, I'll be able to relate that easily to 10.16.18.243, if I NAT it all to one address then it isn't helpful.

    I've tried bridging the interfaces so I don't need NAT and that works great but breaks the captive portal which no longer works.


  • Netgate

    Yeah, more APs lowers client density per AP which is what I was talking about. 4000-8000 simultaneous active users seems high in that case but you know the space better than I do.

    Sorry. I still don't get what NAT brings to the table here other than additional complexity. Are you saying you are currently passing everyone out WAN to an upstream firewall?

    If so just don't NAT at all and that firewall will see traffic from 10.16.18.243 so problem solved.



  • @Derelict:

    Are you saying you are currently passing everyone out WAN to an upstream firewall?

    If so just don't NAT at all and that firewall will see traffic from 10.16.18.243 so problem solved.

    Yes, that's exactly what I am doing, passing it on to a Cisco ASA5545 with FirePOWER which detects traffic from malware and viruses and provides 1 GB of Internet.

    I would love to NOT NAT it, that would be great but then how do we get a captive portal from the pfSense?  If I'm not routing (layer 3, from one netblock to another) through the pfSense system then I don't get to have a captive portal (at layer 2).


  • Netgate

    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.


  • Rebel Alliance Global Moderator

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

    Why do all your guests/AP have to be on the same segment?  Why not break that up in to multiple segments, say 8 /23s or 4 /22's I don't see a reason for /20 just because you have 4000 devices.  What is the reasoning behind a /20?

    Just because your not natting doesn't mean you can not use a CP..  Your nat to the public just happens at your actual edge/border/internet router/firewall not at some downstream router in the midst of your network between 2 rfc1918 segments.



  • @Derelict:

    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?


  • Rebel Alliance Global Moderator

    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.



  • @johnpoz:

    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.


  • Rebel Alliance Global Moderator

    "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/20

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



  • @johnpoz:

    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.


  • Netgate

    @johnpoz

    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.


  • Rebel Alliance Global Moderator

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


  • Netgate

    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.



  • @johnpoz:

    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!



  • @JKnott:

    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.


  • Netgate

    @smoores:

    @johnpoz:

    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!

    Thanks for letting us know.


  • Rebel Alliance Global Moderator

    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.