NATTing can't be this hard
-
Increadable product with great throughput. I love Freebsd, and all of our products are baseed on it, and pfsense seems very flexible. maybe too flexible.
Or, maybe I have just set things up too complex and should start small.
I may have a misunderstanding on how your NAT engine works, and am having intermittent success. Intermittent because the same exact rules for one host don't always seem to work on another.
I have a 10mb, burst able to 100mb metro e (and pfsense keeps up with it!)
I have tried the standard 1:1 NAT with AON, and I think the trick is to add each public ip first as a virtual ip, then add the natting, then the firewall rule (with destination the private ip)If I disable AON, things get really complicated.
200 users (can all go out natted to the WAN public ip .254).
40 servers, all with a average of 5 listening services. MUST GO BACK OUT ON THE SAME PUBLIC IP so vendors, etc see and can match the right up.
(which I think means I would need 4025 individual nat pinhole,port forwarding rules)I had HOPED that just adding the 1:1 NAT, public ip to private ip would do a true, one to 1 nat, in and out on the public ip to and from private ip, but, like I said intermittent success.
Maybe someone can tell me where I am wrong before I give on on what may be the most flexible and powerful opensource firewall package:
WAN: xxx.xxx.xxx.0/24 public class c address. Router is at .1. pfsense WAN IP at .254
LAN: 192.168.1/24. pfsense LAN ip on 192.168.1.1
DMZ: Bridged with WAN
VOICE: 192.168.2/24, pfsense VOICE ip is on 192.168.2.1, using dhcp range 2-254.
WIRELESS: Bridged with WAN.of the 40 servers, some server web sites (80 and 443), some email (25, 587, 993, 995, 465)
One is a voip box (which means I can't mess with the inbound or outbound port mapping. port 31000 on the inside ip has to be 31000 on outside, etc)I began with one:
I set up firewall rule on WAN, allow, source any, dst port 25 on the private ip associated with the public server.
1:1 natting didn't do it, so I read you needed virtual ip's. I deleted the 1:1 rule (applied changed). added the virtual ip, added the 1:1 rule, applied and it worked.
Further, outbound port 80 on the private ip outbound used the public ip in the 1:1 natting.
BINGO, got it.Added another one. worked fine.
Two more, none of them worked.
Did I forget to wave the magic wand?
shouldn't 1:1 natting be one to one natting?
-
fixed it myself, maybe.
standard 1:1 natting worked, EXCEPT for VOIP.tcpdump shows packets going out the right ip, static and all, but the PACKETS (SIP info) contained the wrong 'reply-address' (contained the public ip for the WAN)
I deleted the 1:1 natting for the voip, and entered a manual inbound (portmap) and outbound rule,set them for 'static' and moved the outbound rule above the default manual natting rule.
don't know who or what was messing with the sip packets, but the packets themselves were being rewritten.
(that and I might have gotten it right, but was missing a firewall rule. :-(
Great product, lots of features, but NATTING could use its own book.