Automatic NAT Firewall rules create security hole …



  • Greetings All,

    I'm using pfSense v.1.2.3.  I'm working on a project for a class.  Here's the basic topology:

    Outside Host (IP: 209.165.150.252/29) <–> pfSense WAN (IP: 209.165.150.254/29) <--> pfSense LAN (IP: 172.31.255.1/24) <--> Inside Web Server (IP: 172.31.255.253/24)

    So, two boxes and one pfSense box to separate them.  All running in VMWare virtual machines.

    I've specified a Virtual IP of 209.165.150.253 for the inside Web server.

    Enabling NAT port forwarding works just fine.  I've got it setup to direct any traffic that hits port 80 on the VIP above to be forwarded to port 80 on the Inside Web Server.
    Again, this works fine: hitting IP: 209.165.150.253 in a Web browser on the outside host takes me to the Web site being hosted on the Inside Web Server.

    However, there's a BIG security hole that gets inserted automatically by the Firewall / NAT generation.  Not only can I access my internal server by the public VIP, I can also get to it directly by typing in the private IP: 172.31.255.253.

    So, unless I'm missing something, this is a very bad bug / hole / problem.  So far, I can't get it to work without having the rule allowing traffic to 172.31.255.254 from the WAN link.
    NOTE: The pfSense NAT configuration added this rule for me.  Moving it below the rules that deny public access to the private networks breaks the NAT port forwarding.

    If anyone sees something I'm missing, please do tell.  Otherwise, hopefully this gets fixed pretty soon.

    Here's the rules:











  • That's not a security hole - that's how port forwarding works. You can access it from inside your network using the private IP because that's how networking works.



  • Any two nodes on the same subnet can directly access each other, provided they are directly connected via crossover cable, hub, or switch.  That's the case even if no firewall or router is connected to the said network.

    The issue here is NOT that the inside hosts can connect to the internal Web server (located on the same subnet).  The issue is that a node on the OUTSIDE network (from the public WAN side) can then access the private IP address of the internal Web server from the WAN port on the pfSense firewall.

    On my Cisco routers, if I setup Port Forwarding while using NAT, I have to add an ACL that allows traffic inbound from the Public WAN destined for the specified port to hit my public IP address at that port, say port 80, and then NAT takes over from there.  The outside host has no idea that it is being redirected by port forwarding to a private IP address.  If someone on the WAN side tries to hit my Web server on the inside by its PRIVATE IP address, the router drops the packet, as all direct access to my private IP addresses is blocked from the outside WAN interface using an ACL statement that denies access to the private network from any sources on the WAN side.

    In pfSense, when you setup port forwarding the firewall automatically places a firewall rule on the WAN interface that ALLOWS traffic from the outside world to hit my private INSIDE IP address directly.  This negates the whole point of Port Forwarding, and presents a very real security hole.

    Placing a Firewall rule that BLOCKS access to my private IP address range from the WAN port effectively breaks the port forwarding.

    So, if this were a real-world scenario, an attacker could gain access to the inside private network by directly accessing the private IP address of the internal Web Server, and the firewall would route the public IP address directly into the inside RFC 1918 network.



  • @dtcostelloe:

    In pfSense, when you setup port forwarding the firewall automatically places a firewall rule on the WAN interface that ALLOWS traffic from the outside world to hit my private INSIDE IP address directly.  This negates the whole point of Port Forwarding, and presents a very real security hole.

    It doesn't negate the point of port forwarding and isn't a security hole. That's how PF functions, NAT applies first, then you allow traffic to the translated destination via rules if you want it to get in. If you can route the private subnet directly in (i.e. if you're on the WAN subnet directly) you can also access it directly by the private IP if the specified traffic is allowed. The traffic allowed is exactly what's allowed in your rules and nothing more. You're permitting the traffic, there is absolutely no difference security-wise between it hitting the rdr first and not hitting it.



  • Exactly.  You've hit it spot on.  The security hole, however, comes into play because the rules (generated by pfSense itself) allow direct access from the WAN network (in this case, a public network that can be accessed freely via the public Internet) to hit the private network.

    Now, you're right - the rules DO allow the traffic, because that's what they show plain and simple.  That's not the issue.  The issue is that, if I add a new rule above the automatically-generated NAT rule, that BLOCKS access to the private network behind the pfSense firewall, NAT port forwarding no longer works.  You can no longer access the Web server either by the public IP of the WAN interface itself OR the private inside address.

    As the rules stand in my original post images, you can type in the public WAN IP address of 209.165.150.254 in a Web browser on a host on the WAN side of the firewall, and NAT perfectly forwards the request to the inside host.  That's, of course, exactly what NAT port forwarding is supposed to do.  However, you can ALSO type in the private IP address, and get to it that way.  Again, that's because pfSense forces you to put a rule in that allows this to happen.

    Having a private RFC1918 address publicly available from the WAN interface is a security hole.  Granted, Internet routers are not even supposed to forward any of the RFC1918 addresses, but in the interest of security, I would never take this for granted.  (And neither does pfSense, evidently, as there's an option to disallow any source IP addresses in the RFC1918 range from coming in on the WAN port to begin with.)

    I don't see how it's NOT a security hole if I cannot block access to the private network directly without killing port forwarding.  This is the first router/firewall appliance I've used that has this issue.

    Now, maybe pfSense is somehow different from all the other stuff out there, but I just don't like the idea of either not using NAT port forwarding at all, or having to open up the firewall to allow the public Internet direct access to my private IP address on the internal network.

    FWIW, I can duplicate this lab topology using Cisco ASAs instead of pfSense boxes, and I can do NAT port forwarding AND block direct access to the Web server by its private IP address without any problems.

    Anyway, I may have to use the ASAs - this is a final exam project for my SEC220 security class, and my instructor will fail me if he can access my private network directly from the public WAN hosts.



  • That's simply how PF functions, if you want to take it up with the OpenBSD guys, have fun with that. It's not a security issue, you're allowing access to that host, what IP you use to access it is irrelevant.

    If your instructor fails you on that, he/she is an idiot. There is no difference between accessing it with the public and private IP. Why even bother figuring out your internal range and routing it to your WAN IP, which is only doable on the WAN subnet which commonly is only your own systems, when you simply can access it from anywhere on the Internet on the public IP with that configuration.



  • It's not a security issue, you're allowing access to that host

    The pfSense firewall rules ARE allowing the access.  Unfortunately, as I've stated multiple times before now, you cannot plug this hole in the firewall without breaking the NAT port forwarding.  So, in other words, you don't have any choice.  You either have port forwarding along with allowing any hosts that might be connected to your WAN subnet to directly access the private IP directly, or you don't have NAT port forwarding at all.

    what IP you use to access it is irrelevant

    The IP you use IS relevant if you are given specific instructions that direct access is NOT to be allowed.  Then it is very relevant.  If my employer had a public and private network, and did not want ANY access to the private network directly from the public network, this would again become a very relevant issue.

    Why even bother figuring out your internal range and routing it to your WAN IP, which is only doable on the WAN subnet which commonly is only your own systems, when you simply can access it from anywhere on the Internet on the public IP with that configuration.

    I don't know.  But then again, I don't know why hackers do most of the things they do.  I personally wouldn't go to the trouble … but it's not about what I would or would not do.  The point of this assignment was for me to think of any and all scenarios where an uninvited guest might try to gain access to the private network, and block that said access point.

    In the end, I just replaced the PF box with an ASA, and used it to do the NAT port forwarding and such.  The ASA has no problems denying direct access to the private network while still allowing NAT port forwarding to forward port 80 to the inside Web server.  With the ASA, you can ONLY hit the inside Web server via the public IP address assigned to the WAN port on the ASA, you cannot access it via its private address at all, unless you're on the inside subnet with the machine itself.

    FWIW, I had hoped to use pfSense throughout the topology, because honestly, I like it much better than I do the ASA.



  • I don't understand your concerns - can you explain why the IP address you use matters (beyond what the instructor wants)? You're limited to accessing the same host, on the same port whether you use the WAN IP or the LAN IP. There is no security weakness in being able to use the LAN IP. Indeed, they'll have to work out that LAN IP to be able to reach it directly - if you've selected something random, not just 192.168.0.x then it'll take a brute force search of all 3 RFC 1918 ranges to find it.

    People such as your instructor need to remember that NAT is not a security feature, and it's going away with IPv6 anyway. My entire LAN is directly accessible via IPv6 right now, protected simply by firewall rules. That doesn't make it any less secure than with IPv4 and NAT.


  • Rebel Alliance Developer Netgate

    That "trick", as was stated earlier, only works from inside of your WAN subnet, and iff the "attacker" has a static route which directs the private network at the firewall's WAN IP as a gateway.

    If you think that's a problem, use a /30 on WAN so nobody can effectively use that method.

    pf can't differentiate at that level between a connection coming from a port forward and one that is coming directly, since NAT happens before the firewall rules get applied.

    It doesn't appear pf's NAT rules support the tag parameter or pf could tag the packet as it passed through the rdr and the firewall rule could check that it was tagged with the proper tag.

    You might give the "pass" associated firewall rule type on 2.0 a try, I wonder if it works the same way because it doesn't use a separate firewall rule, just "rdr pass …".



  • I don't understand your concerns - can you explain why the IP address you use matters (beyond what the instructor wants)?

    Honestly, and I might have said this before now, but I don't think that in a real-world scenario that this would matter at all.  Internet routers aren't supposed to even route traffic for RFC 1918 addresses in the first place.  The only instance where it would matter AFAIK, is if a "boss" gave specific instructions that said access was to be prohibited.  But then again, those kind of circumstances would likely be rare.

    The main reason that PF didn't work in my case is because of the nature of the assignment.  The actual assignment wasn't really about NAT or even firewalls at all - the class is about VPNs.  Where NAT became an issue, and where the firewall came into play, is because we had to setup a "fake" Internet using the PF boxes, with two Web servers (one a public server, the other a private intranet server).  So, the whole point really was that the access had to be very limited unless the traffic was coming in through one of the VPN tunnels.  This was why I would have failed had the instructor had direct access to the private network.  The main root of my problem was that the fake "Internet" host was directly connected to the WAN interface on the PF box hosting the Web server, so, PF kept routing the traffic, and there wasn't anything I could do with the rules to make it stop.  (Without breaking NAT.)  Like you said, NAT itself is not a security mechanism, but being unable to Firewall that traffic made it a security hole in this context.

    Beyond the assignment, the only real-world scenario I could think of is if a company had multiple LAN subnets connected via a PF box, with certain subnets using NAT for whatever reason, and a requirement being that one LAN cannot directly access the other LAN.

    Indeed, they'll have to work out that LAN IP to be able to reach it directly - if you've selected something random, not just 192.168.0.x then it'll take a brute force search of all 3 RFC 1918 ranges to find it.

    Unless this was a company that fired their network administrator and you had a disgruntled ex-employee with intricate knowledge of the private network.  I would hope most people would not drop to this level, but in Information Security, they cover all possible aspects.  When my school competed in the Computer Cyber Defense Competition this year, we had to defend our network from an entire team (about 30 - 40 people) who were trained expert penetration testers.  Some of the things I saw at that competition are still a whirlwind in my brain.  Let's just put it this way, out of 8 teams competing at the Regional Competition, zero of them had functioning networks on Day 3 of the 3-day competition.

    Getting back on topic, I don't have the super-expertise of how to break into networks … to the average random script kiddie or the like, there would likely be no issue here.  But, being a security class, I was forced to cover as many bases as possible, defense in depth and layers, so to speak.

    People such as your instructor need to remember that NAT is not a security feature, and it's going away with IPv6 anyway.

    Amen to that!

    Anyway, I got an 'A' on the assignment, so I'm happy.  I was just mentioning the issue I had here because I couldn't find anything anywhere when I was pulling my hair out trying to figure out why I could access the private IP of the Web server with my VPN tunnels down.

    You might give the "pass" associated firewall rule type on 2.0 a try, I wonder if it works the same way because it doesn't use a separate firewall rule, just "rdr pass …".

    I've used PF 2.0 a couple times, and I really like where the project is headed.  2.0 made it so much easier to adjust the max number of simultaneous PPTP users right from the WebGUI.  I'll fire up the 2.0 VM sometime and try this NAT thing out on that and see how it goes.


Locked