Question on Firewall/Port Forward confusion



  • I'm hoping someone here can tell me what PFSense is doing. I've heard good things and have installed the PFSense 1.2 version in our environment. This is not serving "LIVE" production services yet…but soon will be.

    I've created Virtual IP's and NAT 1:1 entries for all of the current services our firewall handles. I also created Aliases for those specific services or ports outside of the standard listings. I then created Port Forwarding rules for each needed service and yes...checked the box so it would create the appropriate WAN firewall rule.

    I noticed some other posts on the boards about unchecking the "Disable NAT Reflection" box to properly enable nat services for a scenario like mine (Internet ---- Cisco Router (set to pass all traffic...all the time) --- PFSense Firewall w/ 2 NIC's for WAN & LAN). When I did that and applied the changes, I noticed the following in my firewall rules list:

    TCP  *  *  192.168.XXX.6  21 (FTP)  *      NAT FTP Port for Website 
    TCP * * 12.195.XXX.68         21 (FTP) *   NAT FTP Port for Website 
    TCP * * 192.168.XXX.13 21 (FTP) *   NAT FTP Port 
    TCP * * 12.195.XXX.69       21 (FTP) *   NAT FTP Port 
    TCP * * 192.168.XXX.8       21 (FTP) *   NAT FTP Port for Lawyerfinder Server 
    TCP * * 12.195.XXX.70       21 (FTP) *   NAT FTP Port for Lawyerfinder Server 
    TCP * * 192.168.XXX.27        21 (FTP) *   NAT FTP Port to Broadcast Mail Server 
    TCP * * 12.195.XXX.85       21 (FTP) *   NAT FTP Port to Broadcast Mail Server 
    TCP * * 192.168.XXX.28        21 (FTP) *   NAT FTP Port for Meetings Mail Server 
    TCP * * 12.195.XXX.86       21 (FTP) *   NAT FTP Port for Meetings Mail Server

    This seems to have added a second rule/entry, but only for FTP (Port 21) traffic. Now the rules show both our internal (192.168) and NAT'd external (12.195) as an entry.

    So my questions are:

    (1) Why is this happening...and just for FTP ports?
    (2) Is the "proper" format of the entry for the WAN interface (as created by the port forwarding rule) the Internal address (192.168) or the external address created by this NAT Redirection enable (12.195)?

    We have all outbound traffic on the LAN interface set to pass, regardless of port. Eventually, we may lock that down properly, but I want to ensure the configuration is solid before putting this system into production and then, working, before we lock things down tighter.

    Thanks in advance for your help.

    -Steve



  • http://forum.pfsense.org/index.php/topic,7001.0.html

    You dont use 1:1 NAT and forwardings for the same servers.
    One or the other.
    Read up on how NAT works.

    Unchecking "Disable NAT Reflection" doesnt create any rules.
    I suspect they were autocreated when you added your NAT forwardings.



  • I can tell you definitively that the Port 21 entries were the last Port-Forward/Firewall rules created. I also reviewed the firewall rules after each entry and can tell you none of the duplicate entries were there. I did not uncheck the "Disable NAT Reflection" box until after all of those entries were in and the "apply" button had been clicked. In other words, these duplicate entries didn't show up until after the box had been unchecked.

    Good to know I don't need a 1:1 NAT if I'm using the port forwards. Does it harm anything by having the entry defined though?

    Thanks,

    -Steve



  • Did you read the link i posted above and wikied how the different NAT modes work?

    "Disable NAT Reflection" is in no way connected with the rules you can create in the GUI.
    It must have been something else (cached pages in your browser?).



  • I read through the link and have a pretty fair understanding of NAT already. I guess what I'm saying is that those entries weren't there for ANY OTHER type of port forward I did (and still aren't). If what you're eluding to is that I can run with just port forward entries and virtual IP's on this system, great. If I needed NAT entries, that's now there too. My question still stands…will having specific entries for NAT, along with the port forwards, do any real damage or pose a security risk?

    My impression was that Port Forwards were evaluated for matching before NAT and the Firewall (Port Forward---NAT 1:1----Firewall Rules).

    Thanks for your patience.

    -Steve



  • @http://forum.pfsense.org/index.php/topic:

    For NAT portforwardings: NAT is applied before the Firewall rules.

    1:1 NAT is bidirectional.
    Meaning traffic originating from the Computer that is 1:1 NATed will appear as if from the external IP used in the 1:1 NAT mapping.

    NAT-Reflection does not work with 1:1 NAT
    http://forum.pfsense.org/index.php?topic=7266.msg41244
    quote:
    You most likely need to setup split dns or add a port forward on top of the 1:1 nat to invoke reflection.  Reflection by default does not work with 1:1 nat's.    So your most likely resolving the public IP address which will not forward back across to the 1:1 server.

    If you create a 1:1 NAT entry all ports from the IP you're 1:1NATing from are "used" and can no longer be used in normal NAT forwardings. –> Normal forwardings will no longer work.
    IMO 1:1 NAT is only usefull if you really want to forward ALL ports to a server/anouter router behind pfSense.

    "Best practice" for me (i think some will disagree) is:

    1: Create an alias with all the ports you want to forward to a server.
    2: Use this alias in the NAT-rule
    3: use this alias in the firewall rule.

    And dont bother with 1:1
    If you have multiple server use multiple aliases.

    Like this you even can make use of NAT reflection if you ever need to access your server via the public IP on the pfSense.

    From the post above it seems you need port-forwardings for an FTP-server.
    This "can" be problematic.
    In the link above are some links to solutions.
    My personal "solution" for FTP is:

    1: Disable the ftp-helper on all interfaces.
    2: Define a port-range on your ftp-server for the data-transfer.
    3: forward port 21 and your data-transfer-range to your server.

    and i never had problems with this approach.
    Of course this requires an FTP-Server where you can define a passive port range.



  • When you said below:

    "Best practice" for me (i think some will disagree) is:
    1: Create an alias with all the ports you want to forward to a server.
    2: Use this alias in the NAT-rule
    3: use this alias in the firewall rule.

    I'm assuming here that in #2, you meant for this to be a "Port Forwarded" rule that's NAT-ing the external address to the internal in its setup, yes?

    I took this advice and removed all of the 1:1 NAT entries, ensured my Virtual IP's were set (using ProxyARP, not CARP or OTHER) and that I had an alias for all non-standard ports I'd want to pass to a given interface defined.

    I tried the "cutover" between my old firewall and new one (using PFSense) a short time ago. All outgoing traffic from my network here seemed to be working just fine. Nothing….however, seemed to make it from the Outside World into our network. As a test, I remoted into our Chicago Office and used one of their PC's there to open a web-browser and find our company's homepage. It found the DNS entry and tried to connect, but timed out. Same for any other services that'd be incoming to our office here.

    This remote office is not VPN-d to us, it simply uses a standard router/firewall setup, giving our staff a dhcp address and they use a secure Citrix Desktop to get back to our site for services. In other words, there should be no other barriers for this to work. At this point, I'm a bit stumped and I'm wholly sure this is something simple that I'm missing, but I don't know what it is. As an example, we have the virtual IP set for our website server (12.195.XXX.68) and a port-forwarding rule that's passing traffic to the site as follows:

    WAN (IF)
    TCP  (PROTO)
    WebsitePorts (EXT PORT RANGE)
    192.168.XXX.6 (ext.: 12.195.XXX.68) (NAT IP)
    WebsitePorts (Internal Port Range)
    Website Ports for ISBA Website  (Description)
    ...where "Website Ports" just port 80 & 443 combined

    The firewall rule that was automatically created for this entry is as follows:

    TCP  *  *  192.168.XXX.6  WebsitePorts  *      NAT Website Ports for ISBA Website

    Am I missing something else here or should this work? All of our other rules are designed like this one, so any help you can provide would be great.

    Thanks again all!

    -Steve



  • Yes i meant port-forward rules.

    Could you show a screenshot of your NAT forward rules and your firewall rules?



  • Screen Shots attached. Let me know if you see anything a miss.

    Thanks!










  • Hmmm.
    This should just work.
    In fact i have the exact same setup here right now running…

    Are there any entries in the firewall log?
    You could also try to use a CARP-VIP (this should make no difference).

    Also i think i've read something about rebooting the firewall after creating VIP's, but i think this isnt really need.



  • I'd have to put logging on that rule and take services down/up again to know for sure, but I don't recall seeing any this morning. I will try this off business hours and see what develops.

    No, I hadn't tried the CARP VIP's, in part because I wasn't sure exactly how to set those up. Is each IP then it's own master, or do I need my firewall IP in the list, making that the "Master" and all the others part of that group?

    Let me know if anything else seems likely. Thanks.
    -Steve



  • Per default everything gets blocked.
    If something gets blocked (aka is not beeing allowed by your rules) you should get an entry in the log.

    If you set up a CARP VIP's it's just like you have a failover-setup with just one node.
    –> as you said: your box is always master.

    Just make sure that you set the subnet correctly.
    --> The actual subnet of the main interface instead of a range of IP's as with PARP.



  • Well, I tried the cutover again and it still didn't work. I checked the logs and there wasn't a single entry in the firewall or system log related to traffic to this server being blocked. Nothing whatsoever.

    When I went to change the Virtual IP's into CARP (from Proxy ARP), the system threw itself into a continual reboot cycle that hasn't stopped. Luckily, I have a backup of the config file I can re-load quickly.

    Beyond the above, are there any other key settings I need to make sure are set a certain way to ensure things work?

    Thanks,

    -Steve



  • Well, I came into the office early this morning and noticed that the firewall eventually did come back up on it's own. I was able to remove the Virtual IP for the external interface and change all of the other Virtual IP's to CARP instead of ProxyARP. After doing so, I attempted the switchover again…and Voila, all of the network services are now coming through (Inbound Traffic) as I'd expect. Outbound was always working and still is now...so that's a plus.

    The only thing I did notice however, was in the system log....the following entries were found:

    Sep 27 11:04:28  Kernel: arp_rtrequest: bad gateway 12.195.XXX.81 (!AF_LINK)
    Sep 27 11:04:28 kernel: arp_rtrequest: bad gateway 12.195.XXX.86 (!AF_LINK)
    Sep 27 11:04:27 kernel: arp_rtrequest: bad gateway 12.195.XXX.85 (!AF_LINK)
    Sep 27 11:04:25 kernel: arp_rtrequest: bad gateway 12.195.XXX.80 (!AF_LINK)
    Sep 27 11:04:24 kernel: arp_rtrequest: bad gateway 12.195.XXX.79 (!AF_LINK)
    Sep 27 11:04:23 kernel: arp_rtrequest: bad gateway 12.195.XXX.76 (!AF_LINK)
    Sep 27 11:04:22 kernel: arp_rtrequest: bad gateway 12.195.XXX.74 (!AF_LINK)
    Sep 27 11:04:21 kernel: arp_rtrequest: bad gateway 12.195.XXX.72 (!AF_LINK)
    Sep 27 11:04:20 kernel: arp_rtrequest: bad gateway 12.195.XXX.71 (!AF_LINK)
    Sep 27 11:04:19 kernel: arp_rtrequest: bad gateway 12.195.XXX.70 (!AF_LINK)
    Sep 27 11:04:18 kernel: arp_rtrequest: bad gateway 12.195.XXX.69 (!AF_LINK)
    Sep 27 11:04:17 kernel: arp_rtrequest: bad gateway 12.195.XXX.68 (!AF_LINK)
    Sep 27 11:04:16 kernel: arp_rtrequest: bad gateway 12.195.XXX.67 (!AF_LINK)
    Sep 27 11:04:15 kernel: arp_rtrequest: bad gateway 12.195.XXX.66 (!AF_LINK)

    I'm wondering what this is and what I can do about if...or what I need to do about it rather?

    Thanks.

    -Steve




Locked