[pfSense] outbound NAT

[j***@millican.us]

Hello,
I have two boxes set up with WAN CARP IP's which are NAT'ed to different
Virtual server pools. This is working slicker than banana peels in a Bug
Bunny cartoon. The only problem is that I would like to be able to have
the outbound traffic NAT'ed to the inbound CARP IPs, but I can not find
how to do this in the outbound NAT settings unless I opt for 1:1 NAT
which I would rather not if possible.

Example:
Inbound to CARP IP 1.2.3.4 is NAT'ed to a virtual server pool at
192.168.1.10 which is load balanced to 192.168.1.11 and 192.168.1.12
Inbound to CARP IP 1.2.3.5 is NAT'ed to to a virtual server pool at
192.168.1.50 which is load balanced to 192.168.1.25 and 192.168.1.26
With no manual outbound NAT all outbound traffic gets the address of the
Firewall WAN interface as is expected.
If I try to use manual outbound NAT I can only set it for an entire
network so I could set outbound to either 1.2.3.4 or 1.2.3.5, not really
optimal.

I would like to have the outbound traffic appear to be returning from
the respective CARP addresses. In other words, when a client makes a
request to 1.2.3.4, the return packets should have the IP of 1.2.3.4.
When a request is made to 1.2.3.5 the return packets should have the IP
of 1.2.3.5. I have only seen the ability to specify an entire network
(or any???) to outbound NAT such that all return packets would have the
IP of either 1.2.3.4 or 1.2.3.5.

In Linux iptables world I would do something like:
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.11 -j SNAT
--to-source 1.2.3.4
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.25 -j SNAT
--to-source 1.2.3.5

Am I mising something? I hope so.

Thank You for any suggestions,
JohnM

[Adam Thompson]

To translate outbound packets to anything other than the interface's primary address, you have to override the default rules.
On the NAT screen, you should see an either-or choice between Automatic rules and manual (maybe called advanced, not sure as I'm not at a computer right now).
You'll have to turn off the automatic NAT rules and use your own. IIRC, when you switch modes, it exposes the automatic rules currently in place, so you can probably just edit them.
-Adam

Post by j***@millican.us
Hello,
I have two boxes set up with WAN CARP IP's which are NAT'ed to different
Virtual server pools. This is working slicker than banana peels in a Bug
Bunny cartoon. The only problem is that I would like to be able to have
the outbound traffic NAT'ed to the inbound CARP IPs, but I can not find
how to do this in the outbound NAT settings unless I opt for 1:1 NAT
which I would rather not if possible.
Inbound to CARP IP 1.2.3.4 is NAT'ed to a virtual server pool at
192.168.1.10 which is load balanced to 192.168.1.11 and 192.168.1.12
Inbound to CARP IP 1.2.3.5 is NAT'ed to to a virtual server pool at
192.168.1.50 which is load balanced to 192.168.1.25 and 192.168.1.26
With no manual outbound NAT all outbound traffic gets the address of the
Firewall WAN interface as is expected.
If I try to use manual outbound NAT I can only set it for an entire
network so I could set outbound to either 1.2.3.4 or 1.2.3.5, not really
optimal.
I would like to have the outbound traffic appear to be returning from
the respective CARP addresses. In other words, when a client makes a
request to 1.2.3.4, the return packets should have the IP of 1.2.3.4.
When a request is made to 1.2.3.5 the return packets should have the IP
of 1.2.3.5. I have only seen the ability to specify an entire network
(or any???) to outbound NAT such that all return packets would have the
IP of either 1.2.3.4 or 1.2.3.5.
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.11 -j SNAT
--to-source 1.2.3.4
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.25 -j SNAT
--to-source 1.2.3.5
Am I mising something? I hope so.
Thank You for any suggestions,
JohnM
_______________________________________________
List mailing list
http://lists.pfsense.org/mailman/listinfo/lis

[j***@millican.us]

Post by j***@millican.us
Hello,
I have two boxes set up with WAN CARP IP's which are NAT'ed to different
Virtual server pools. This is working slicker than banana peels in a Bug
Bunny cartoon. The only problem is that I would like to be able to have
the outbound traffic NAT'ed to the inbound CARP IPs, but I can not find
how to do this in the outbound NAT settings unless I opt for 1:1 NAT
which I would rather not if possible.
Inbound to CARP IP 1.2.3.4 is NAT'ed to a virtual server pool at
192.168.1.10 which is load balanced to 192.168.1.11 and 192.168.1.12
Inbound to CARP IP 1.2.3.5 is NAT'ed to to a virtual server pool at
192.168.1.50 which is load balanced to 192.168.1.25 and 192.168.1.26
With no manual outbound NAT all outbound traffic gets the address of the
Firewall WAN interface as is expected.
If I try to use manual outbound NAT I can only set it for an entire
network so I could set outbound to either 1.2.3.4 or 1.2.3.5, not really
optimal.
I would like to have the outbound traffic appear to be returning from
the respective CARP addresses. In other words, when a client makes a
request to 1.2.3.4, the return packets should have the IP of 1.2.3.4.
When a request is made to 1.2.3.5 the return packets should have the IP
of 1.2.3.5. I have only seen the ability to specify an entire network
(or any???) to outbound NAT such that all return packets would have the
IP of either 1.2.3.4 or 1.2.3.5.
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.11 -j SNAT
--to-source 1.2.3.4
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.25 -j SNAT
--to-source 1.2.3.5
Am I mising something? I hope so.
Thank You for any suggestions,
JohnM

Post by Adam Thompson
To translate outbound packets to anything other than the interface's primary address, you have to override the default rules.
On the NAT screen, you should see an either-or choice between Automatic rules and manual (maybe called advanced, not sure as I'm not at a computer right now).
You'll have to turn off the automatic NAT rules and use your own. IIRC, when you switch modes, it exposes the automatic rules currently in place, so you can probably just edit them.
-Adam

Thank You Adam,
Hope you don't mind I moved to bottom post, answers after question and
all that. It is a personal thing :-)
I had done as you suggested prior to the mail but I am unable to figure
out how to get the manual outbound to apply to anything other than the
entire network. In the outbound NAT rules page there is a drop down
that has only two choices, network or any. Are you saying that I should
use network with a /32 to limit it to a single address?
I would try this before replying but with all the changes made for
testing I seem to have borked my VPN a bit and need to find out what I
messed up so I can get back to a known starting point.
Thanks,
JohnM

[Adam Thompson]

Post by j***@millican.us
Thank You Adam,
Hope you don't mind I moved to bottom post, answers after question
and all that. It is a personal thing :-) I had done as you suggested
prior to the mail but I am unable to figure out how to get the
manual outbound to apply to anything other than the entire network.
In the outbound NAT rules page there is a drop down that has only
two choices, network or any. Are you saying that I should use
network with a /32 to limit it to a single address?
I would try this before replying but with all the changes made for
testing I seem to have borked my VPN a bit and need to find out what
I messed up so I can get back to a known starting point.

And now that I'm back at a real computer, I also have the ability to
bottom-post, yay! I also prefer it, but I'm getting old enough and tired
enough that I no longer feel the need to fight my tools at every step.
(This topic has been beaten to death here already.)

I'm now confused... if you want to NAT a single /32 to a single VIP, why
isn't 1:1 NAT acceptable? Since that's basically what you'd be doing, the
hard way.

What end-result do you actually want, if not the entire network (or a good
chunk of it, anyway)?

Wait, re-reading your original post, you're only concerned about replies
to inbound packets? Pf should be taking care of that for you
automatically without you having to create any additional rules! (And, my
apologies - you said you had already tried AON, but I missed that point
when reading your original mail.)

So you have border firewalls F1 and F2, which each have their primary WAN
and LAN IPs F1(W) and F2(W), together sharing responsibility for two WAN
VIPs (i.e. CARP addresses) V1 and V2.
You have inbound port-forwarding enabled for V1 and V2, respectively
sending those packets to load-balancers L1 and L2.
Load balancers L1 redirects packets to real web servers S1 and S2, while
L2 sends to S3 and S4.

Recap so far: Outside->V1@(F1,F2)->L1->(S1,S2);
Outisde->V2@(F1,F2)->L2->(S3,S4).

So (F1,F2) are performing inbound NAT, re-writing the destination address
V1 into L1 and V2 into L2. Any replies coming back from L1 or L2 matching
existing states will have their source addresses re-written to V1/V2
automatically without you having to do anything special.

Then, L1/L2 are using some sort of load-balancing mechanism:
- If it's L2 packet forwarding, then S1-S4 must have special knowledge of
the cluster IPs and be configured to forge reply packets. This is not a
common deployment anymore, although there are tons of semi-outdated
examples on the 'net. If S1-S4 do MAC address forging as well as IP
address forging, then F1/F2 should not notice the difference, and will
rewrite the (forged) source address (i.e. L1/L2) back to V1/V2
automatically. (If they don't do MAC address forging, this probably
doesn't work well under any circumstance... and security features in your
switches may be canning the replies anyway.)
- If it's packet rewriting (i.e. NAT), then L1 and L2 function the same
way NAT does on pfSense, i.e. automatically rewriting replies.
- If it's reverse-proxying, the TCP conversations L1->(S1,S2) and
L2->(S3,S4) are completely independent of everything else and don't even
come into the picture. Reply packets come from L1/L2's IP address and are
re-written automatically at F1/F2.

So far, it sounds like you should be using two 1:1 NAT entries, one for
V1->L1 and one for V2->L2. Let your load-balancers take care of the
internal L1->(S1,S2) rewriting.

If L1/L2 are actually running directly on F1/F2 then you have a very
complicated problem that I don't know how to solve if it doesn't "just
work" :-). That would require input from someone a LOT more familiar with
how and when FreeBSD's port of pf applies rules!

However, you mention that "all outbound traffic gets the address of the
Firewall WAN interface as is expected"... Yes, that's expected. That also
does NOT represent what happens to INBOUND connections. Completely
different set of NAT rules get involved there depending on who originates
the connection. The only time inbound and outbound follow anything close
to the same NAT rules is when you use 1:1 NAT.

Finally, although I think this is the wrong approach based on your
original post, specifying the network "192.168.0.4/31" does in fact
include both 192.168.0.4 and 192.168.0.5 and no other IPs. The mask
specified in a NAT rule doesn't have to match what's configured on an
interface - you're just using the CIDR notation to express a mathematical
matching operator. Note the implication of binary math that the first IP
address in a two-host range must be an even number, i.e. it's
mathematically impossible to specify a range that includes only
192.168.0.5 & 192.168.0.6... If you're having trouble with that, just use
the online tool at http://www.subnet-calculator.com/cidr.php (or any of
the six thousand similar tools available) to come up with valid
combinations.


-Adam Thompson
***@athompso.net

[j***@millican.us]

Post by Adam Thompson

Post by j***@millican.us
Thank You Adam,
Hope you don't mind I moved to bottom post, answers after question
and all that. It is a personal thing :-) I had done as you suggested
prior to the mail but I am unable to figure out how to get the
manual outbound to apply to anything other than the entire network.
In the outbound NAT rules page there is a drop down that has only
two choices, network or any. Are you saying that I should use
network with a /32 to limit it to a single address?
I would try this before replying but with all the changes made for
testing I seem to have borked my VPN a bit and need to find out what
I messed up so I can get back to a known starting point.

And now that I'm back at a real computer, I also have the ability to
bottom-post, yay! I also prefer it, but I'm getting old enough and tired
enough that I no longer feel the need to fight my tools at every step.
(This topic has been beaten to death here already.)
I'm now confused... if you want to NAT a single /32 to a single VIP, why
isn't 1:1 NAT acceptable? Since that's basically what you'd be doing, the
hard way.
What end-result do you actually want, if not the entire network (or a good
chunk of it, anyway)?
Wait, re-reading your original post, you're only concerned about replies
to inbound packets? Pf should be taking care of that for you
automatically without you having to create any additional rules! (And, my
apologies - you said you had already tried AON, but I missed that point
when reading your original mail.)
So you have border firewalls F1 and F2, which each have their primary WAN
and LAN IPs F1(W) and F2(W), together sharing responsibility for two WAN
VIPs (i.e. CARP addresses) V1 and V2.
You have inbound port-forwarding enabled for V1 and V2, respectively
sending those packets to load-balancers L1 and L2.
Load balancers L1 redirects packets to real web servers S1 and S2, while
L2 sends to S3 and S4.
So (F1,F2) are performing inbound NAT, re-writing the destination address
V1 into L1 and V2 into L2. Any replies coming back from L1 or L2 matching
existing states will have their source addresses re-written to V1/V2
automatically without you having to do anything special.
- If it's L2 packet forwarding, then S1-S4 must have special knowledge of
the cluster IPs and be configured to forge reply packets. This is not a
common deployment anymore, although there are tons of semi-outdated
examples on the 'net. If S1-S4 do MAC address forging as well as IP
address forging, then F1/F2 should not notice the difference, and will
rewrite the (forged) source address (i.e. L1/L2) back to V1/V2
automatically. (If they don't do MAC address forging, this probably
doesn't work well under any circumstance... and security features in your
switches may be canning the replies anyway.)
- If it's packet rewriting (i.e. NAT), then L1 and L2 function the same
way NAT does on pfSense, i.e. automatically rewriting replies.
- If it's reverse-proxying, the TCP conversations L1->(S1,S2) and
L2->(S3,S4) are completely independent of everything else and don't even
come into the picture. Reply packets come from L1/L2's IP address and are
re-written automatically at F1/F2.
So far, it sounds like you should be using two 1:1 NAT entries, one for
V1->L1 and one for V2->L2. Let your load-balancers take care of the
internal L1->(S1,S2) rewriting.
If L1/L2 are actually running directly on F1/F2 then you have a very
complicated problem that I don't know how to solve if it doesn't "just
work" :-). That would require input from someone a LOT more familiar with
how and when FreeBSD's port of pf applies rules!
However, you mention that "all outbound traffic gets the address of the
Firewall WAN interface as is expected"... Yes, that's expected. That also
does NOT represent what happens to INBOUND connections. Completely
different set of NAT rules get involved there depending on who originates
the connection. The only time inbound and outbound follow anything close
to the same NAT rules is when you use 1:1 NAT.
Finally, although I think this is the wrong approach based on your
original post, specifying the network "192.168.0.4/31" does in fact
include both 192.168.0.4 and 192.168.0.5 and no other IPs. The mask
specified in a NAT rule doesn't have to match what's configured on an
interface - you're just using the CIDR notation to express a mathematical
matching operator. Note the implication of binary math that the first IP
address in a two-host range must be an even number, i.e. it's
mathematically impossible to specify a range that includes only
192.168.0.5 & 192.168.0.6... If you're having trouble with that, just use
the online tool at http://www.subnet-calculator.com/cidr.php (or any of
the six thousand similar tools available) to come up with valid
combinations.
-Adam Thompson

Adam,
Thanks once again. I definitly did not want to open old hasing of top
vs bottom post but I did not want to change you replay in any way with
out saying I did so.

I was thinking that the CIDR on the outbound page had to match the
interface configuration. Assuming is almost always bad. When I was
younger I was able to do all that CIDR stuff in my head but age, bad
habits, and lack of practice have put an end to that so I do have a
couple subnet calculators that I refer to.

The two pfSense boxes are doing the load balancing inbound and it is
working well so F1 and L1 are the same box, F2 and L2 are the same box,
so it is more like:

Outside->V1@(FL1,FL2)->(S1,S2);
Outside->V2@(FL1,FL2)->(S3,S4).

Inbound is all sorted and doing what it should. As far as 1:1 NAT I am just planning for the day when I will need to send different services to different servers from the same public IP. Murphy's Law and management usually raise their ugly heads when I do not plan for these things. Based on what you have said I need to look at outbound NAT using the network setting from the drop down with a proper CIDR so that replies to the outside from s1 and s2 are sent out with address V1 address and s3 and s4 replies are sent with V2 address.

so: Outside->V1@(FL1,FL2) gets balanced by (FL1,FL2) to->(S1,S2 private addresses)->(S1,S2 respond to the request)->(FL1,FL2 rewrite S1,S2 address with v1 address)->Outside is what I want while still being able to direct traffic that comes to V1 to a different internal IP should the need arise for say V1:HTTPS to S1, S2 and V1:HTTP to S6,S8.

What I am getting is: Outside->V1@(FL1,FL2) gets balanced by (FL1,FL2) to->(S1,S2 private addresses)->(S1,S2 respond to the request)->(FL1,FL2 rewrite S1,S2 address with actual WAN interface IP)->Outside
This causes a situation where you make the request to 1.2.3.4 but the replies come back to you from 1.2.3.9

I will try using a CIDR to limit the addresses that get snat'ed to each VIP, since I have the whole 192.168.1.x to play with I should be ok.

Thanks,
JohnM

[Adam Thompson]

Post by j***@millican.us
The two pfSense boxes are doing the load balancing inbound and it is
working well so F1 and L1 are the same box, F2 and L2 are the same box,

[Adam Thompson]

OK, that makes it more complicated, as I don't know how pf handles that
situation. I know what happens if the packets actually egress and
re-ingress, but not sure about the short-circuit case.

Post by j***@millican.us
(FL1,FL2) to->(S1,S2 private addresses)->(S1,S2 respond to the
request)->(FL1,FL2 rewrite S1,S2 address with actual WAN interface
IP)->Outside
This causes a situation where you make the request to 1.2.3.4 but
the replies come back to you from 1.2.3.9

That means that, as I suspected, having L1/L2 running on F1/F2 is causing
some sort of unexpected interaction. If you have the ability to
temporarily turn up a physically separate system to do the load-balancing,
I think you will find that everything "just works".

Are you using the TCP Load Balancing feature, or are you using something
like varnish?

If you have to rely on outbound NAT rules to make this work, I suspect
you'll quickly find that pf states expire on you for no apparent reason;
if the outbound NAT isn't being handled by a 'match' statement, then you
aren't matching the original incoming state, which means you'll shortly be
dropping incoming connections.

Trying not to flog a dead horse here, if you have to use AON to accomplish
this, *something else* is *broken*.

-Adam

[j***@millican.us]

Post by Adam Thompson

Post by j***@millican.us
The two pfSense boxes are doing the load balancing inbound and it is
working well so F1 and L1 are the same box, F2 and L2 are the same box,

[Adam Thompson]
OK, that makes it more complicated, as I don't know how pf handles that
situation. I know what happens if the packets actually egress and
re-ingress, but not sure about the short-circuit case.

Post by j***@millican.us
(FL1,FL2) to->(S1,S2 private addresses)->(S1,S2 respond to the
request)->(FL1,FL2 rewrite S1,S2 address with actual WAN interface
IP)->Outside
This causes a situation where you make the request to 1.2.3.4 but
the replies come back to you from 1.2.3.9

That means that, as I suspected, having L1/L2 running on F1/F2 is causing
some sort of unexpected interaction. If you have the ability to
temporarily turn up a physically separate system to do the load-balancing,
I think you will find that everything "just works".
Are you using the TCP Load Balancing feature, or are you using something
like varnish?
If you have to rely on outbound NAT rules to make this work, I suspect
you'll quickly find that pf states expire on you for no apparent reason;
if the outbound NAT isn't being handled by a 'match' statement, then you
aren't matching the original incoming state, which means you'll shortly be
dropping incoming connections.
Trying not to flog a dead horse here, if you have to use AON to accomplish
this, *something else* is *broken*.
-Adam

Silly as this may sound at this point I was "trying" to keep things as
simple as I could by using the TCP load balance feature rather than a
third party app like varnish. I, unfortunately at this time, do not
have the option of a separate box/boxes to turn up for load balancing.
I will be working today to see if the idea you gave me for using a /31
int the network drop down to snat outbound while keeping an eye open for
dropped packets. If this has problems I will go for 1:1 NAT for now and
then get a pair of boxes to load balance with maybe Varnish, HA proxy ,
or possibly Apache traffic server.
Thank You for all the help.
JohnM

[Adam Thompson]

Post by j***@millican.us
Silly as this may sound at this point I was "trying" to keep things
as simple as I could by using the TCP load balance feature rather
than a third party app like varnish. I, unfortunately at this time,
do not have the option of a separate box/boxes to turn up for load
balancing.
I will be working today to see if the idea you gave me for using a
/31 int the network drop down to snat outbound while keeping an eye
open for dropped packets. If this has problems I will go for 1:1
NAT for now and then get a pair of boxes to load balance with maybe
Varnish, HA proxy , or possibly Apache traffic server.
Thank You for all the help.
JohnM

That makes sense... but if all you're load-balancing is HTTP, you'll find
that using a reverse-proxy like Varnish makes your life a LOT easier than
doing it at the TCP or IP level. Using TCP load-balancing to load-balance
web servers is kind of like using a sledgehammer to kill a fly, IMHO. If
all you have is a sledgehammer, I guess it's better than nothing, but in
this case the flyswatter is free, and you're much less likely to hurt
yourself with it :-).
I know sullrich has commented very favourably on varnish in the past, and
I'd have to agree with him. Its only significant limitation is lack of
SSL support, IMHO.

For reverse-proxies on pfSense 2.1, you currently have Apache, HAproxy,
something called "Proxy Server with mod_security" (Apache with a newer
version of mod_security), Squid, Varnish, and Varnish v3. Stunnel can be
used to SSL-enable any of those that don't do SSL natively.
Any of these will take a little bit more setup than TCP load-balancing,
but the biggest headache you'll have (usually) is figuring out what the
various GUI fields mean.
There are some reasons you wouldn't want to use a reverse-proxy - those
mainly center around the web server needing to see the original client IP
address in the packet (and not just in the HTTP headers, where all the
proxies put it IIRC), or the web server needing to terminate SSL
connections instead of having the reverse-proxy do that.

Stretching my analogy a bit too far, the flyswatter may have been designed
by a programmer, and thus may have more adjustable knobs than you know
what to do with...

-Adam

[j***@millican.us]

Post by Adam Thompson

Post by j***@millican.us
Silly as this may sound at this point I was "trying" to keep things
as simple as I could by using the TCP load balance feature rather
than a third party app like varnish. I, unfortunately at this time,
do not have the option of a separate box/boxes to turn up for load
balancing.
I will be working today to see if the idea you gave me for using a
/31 int the network drop down to snat outbound while keeping an eye
open for dropped packets. If this has problems I will go for 1:1
NAT for now and then get a pair of boxes to load balance with maybe
Varnish, HA proxy , or possibly Apache traffic server.
Thank You for all the help.
JohnM

That makes sense... but if all you're load-balancing is HTTP, you'll find
that using a reverse-proxy like Varnish makes your life a LOT easier than
doing it at the TCP or IP level. Using TCP load-balancing to load-balance
web servers is kind of like using a sledgehammer to kill a fly, IMHO. If
all you have is a sledgehammer, I guess it's better than nothing, but in
this case the flyswatter is free, and you're much less likely to hurt
yourself with it :-).
I know sullrich has commented very favourably on varnish in the past, and
I'd have to agree with him. Its only significant limitation is lack of
SSL support, IMHO.
For reverse-proxies on pfSense 2.1, you currently have Apache, HAproxy,
something called "Proxy Server with mod_security" (Apache with a newer
version of mod_security), Squid, Varnish, and Varnish v3. Stunnel can be
used to SSL-enable any of those that don't do SSL natively.
Any of these will take a little bit more setup than TCP load-balancing,
but the biggest headache you'll have (usually) is figuring out what the
various GUI fields mean.
There are some reasons you wouldn't want to use a reverse-proxy - those
mainly center around the web server needing to see the original client IP
address in the packet (and not just in the HTTP headers, where all the
proxies put it IIRC), or the web server needing to terminate SSL
connections instead of having the reverse-proxy do that.
Stretching my analogy a bit too far, the flyswatter may have been designed
by a programmer, and thus may have more adjustable knobs than you know
what to do with...
-Adam

Unfortunately 99% of all traffic will be HTTPS into the DMZ, which will
then relay pertinent info to the app tier which then pushes and pulls
to/from the DB tier. I haven't actually worked with Varnish yet but
have done some with HAProxy for inbound Load balance and it worked
rather well. I have heard many good things about Varnish also. Our web
servers do need to seethe original IP address but I know that HAproxy
has an "X-Forwarded-For" option that can be used for this purpose and I
"believe" Varnish has similar. As far as a fly swatter with to many
knobs, well that could be a very long thread!<g>

I did try using a /29(due to the addresses I wanted to include) CIDR on
the manual outbound NAT and lost all ability to even ping out of the
DMZ. Did not get as far as checking where I was losing packets but, it
was a 100% loss. Will be moving to 1:1 NAT today and will look at
getting a couple LB servers to run Varnish or such on when down the road.

Since I do not ,as of now, have the option of separate boxes for Varnish
or HAProxy, do you think these would be a better option to run on the
pfSense box considering what I would like to accomplish? Or, would I be
trading one headache for another. We currently have very low traffic
volume and due to the type of traffic I do not see it exceeding 20 to 25
meg in the next year. If it does I will have a good reason, and budget,
for more hardware. Yes I know hardware for this would not be a huge
expense but, a budget is a budget.

Thank You for all your help.
JohnM