Question on Firewall/Port Forward confusion
-
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 combinedThe 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
-
http://forum.pfsense.org/index.php/topic,8464.msg47484.html#msg47484