On 9/26/2012 3:47 PM, Adam Thompson wrote:
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
[email protected]
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
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
