On 2013-05-29 14:16, [email protected] wrote:
Hello all,
Well I asked this question a few days back under a sanity check
subject and it turned into more of a discussion on running pfSense in
a virtual environment so I am rephrasing the original question.
Running pfSense 2.0.3 on dedicated Hardware and I am working with my
current ISP to build a scenario like the following:
ISP ->pfSense WAN interface(redundant with CARP) listening on
65.251.xxx.xxx/29 -> LAN interface 69.169.xxx.xxx/27
The ISP will use one of the /29 host IPs for their router and
obviously I will need one IP for each of the WAN interfaces on the
two
pfSense boxes and one for the first CARP ip.
That leaves me 2 "spare" addresses to use later. I am planning to
use th ese down the road as a network segmentation scheme.
So, the ISP will configure their routers to direct all
69.169.xxx.xxx/27 traffic to my WAN interface at 65.251.xxx.xxx/29.
Here's the rub. If they have a *route* to 69.169.x.x/27 with a
next-hop gateway of 65.251.a.b (your CARP IP, the subnet mask is
irrelevant here), then this will work without forwarding at all - this
is simply called "routing" and it happens magically once everything is
set up - subject to firewall rules, that is.
I am "assuming" that from there I can simply port forward to the
69.169.xxx.xxx/27 addresses same as if they were private
192.168.0.0/24 addresses but with out NAT but, thisis where I am
unsure. Do I set the forwarding rules destination as the
69.169.xxx.xxx/27 address even though this is on the LAN interface?
How to i tel the WAN interface that it is supposed to be listening
for
the 69.169.xxx.xxx/27 addresses?
No. If you're routing, you are not port-forwarding. If you are
port-forwarding from public IPs to (internal, unreachable) public IPs,
you need to be shot - even a /27 is a valuable resource at this time.
Also, port-forwarding REQUIRES NAT. It's inherent in the very nature of
what port-forwarding is.
Am I missing anything that is gong to make this plan unfeasible?
Unfortunately, a good grasp of IP routing. You obviously understand
NAT, which is a (very!) special case of IP routing. However, you are
moving beyond the corner-case of NAT and you will learn that
In fact, your email could be used as an argument for "NAT is harmful to
the internet" in various fora I've seen... oh, well, those horses are
long gone and that barn door not only is still hanging wide open, it's
been torched, stolen, dismantled and vaporized.
There is a good reason for doing this involving services (such as
sip) that do not play well with NAT and the fact that due to
architecture some virtual servers may be behind NAT within the
internal environment which would mean NAT'ing a NAT'ed address, never
a good thing.
Double-NATing actually works surprisingly well for most applications.
SIP can be NAT'd quite successfully nowadays. I hope you aren't
planning on making SIP phones connect directly to the internet?
Nonetheless, avoiding NAT is always a good thing (IMHO).
You've got about 90% of the picture correct, but at this point you need
to stop and figure out how to make this work with a router, not a
firewall. Once you understand the router-only model, add the firewall
notion back into the picture.
A firewall with NAT turned off and
Allow-All-From-Any-To-Any-In-All-Directions rules is, essentially, just
a router. Every firewall must be a router, inherently[1], so you don't
need to go buy a router to do this: pfSense can do it quite nicely. In
fact, on the System-->Advanced-->Firewall/NAT page, you'll find a
checkbox "Disable all packet filtering" that does exactly this.
I strongly recommend you turn on that checkbox (at least in concept),
and completely ignore the Firewall section of the GUI until you have
everything figured out. This might be dangerous in reality, since that
leaves you without a firewall... but I think you'll need to set up a lab
system anyway to figure out how this will work.
I apologize, I don't know how to explain routing in one email (but I'd
be happy to come teach a one-day seminar on it); it will actually be
more difficult to understand routing because you *do* have experience
with NAT... you will have to un-learn NAT before figuring out routing.
-Adam
[1]Application proxy firewalls, e.g. Gauntlet, are a different story.
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
