Re: transparent squid and load balacing outgoing traffic still not working
On Thu, Feb 17, 2005 at 10:35:50AM -0300, Emilio Lucena wrote: Well, I tried to follow this recommendation, but I noticed that, although PF indeed changed its behaviour and distributed the traffic between both external connections, the packets sent out through the other external connection (not the default gateway interface), had the source IP address of the default interface. As a result, they get lost or discarded by the ISP. Now the question is how to tell PF to change the source IP address when it decides to send the packet through the other interface ? nat on $ext_if1 from $int_if:network to any - ($ext_if1) nat on $ext_if2 from $int_if:network to any - ($ext_if2) What happens is this. The packet first tries to go out through the default interface. The ruleset is evaluated. First, translation rules apply, then filter rules. You have a NAT rule that matches on the default interface, so the source address is replaced with the default interface's address. Then filter rules are evaluated. The route-to rule causes re-routing. Now the packet passes out through the second interface and causes ruleset evaluation. First, translation rules apply. But your NAT rule does not match, because of the source address restriction. The packet, at this point, has the default interface's address as source, not $int_if:network anymore. So no further NAT applies, and that's how the packet passes out. Try these NAT rules instead nat on $ext_if1 from !($ext_if1) to any - ($ext_if1) nat on $ext_if2 from !($ext_if2) to any - ($ext_if2) Daniel
CIDR Networks in recursive Macros
I couldn't find this issue in any of the documentation I could find, so
I thought I'd ask here.
Macros in pf can be defined recursively, but it doesn't seem to work
when the macros that are being expanded are CIDR-style network
specifications.
For instance, while this works:
wibble = { 192.168.1/24 192.168.4/24 }
This does not (fails with a syntax error when trying to load):
muh = 192.168.1/24
fuh = 192.168.4/24
wibble = { $muh $fuh }
I've tried it with commas, with one macro and one literal, with
non-abbreviated style (i.e. 192.168.1.0/24), etc., but nothing seems to
work.
Recursive macros work normally with individual hosts, but not netblocks.
Is this a feature or a bug?
/a
--
Aaron Spanik
Senior Unix Systems Administrator, Computing Services
Acadia University Wolfville, NS Canada B4P 2R6
phone: (902) 585-1121 fax: (902) 585-1066
Re: CIDR Networks in recursive Macros
On Thu, 2005-02-17 at 10:21, Aaron Spanik wrote:
I couldn't find this issue in any of the documentation I could find, so
I thought I'd ask here.
Macros in pf can be defined recursively, but it doesn't seem to work
when the macros that are being expanded are CIDR-style network
specifications.
For instance, while this works:
wibble = { 192.168.1/24 192.168.4/24 }
This does not (fails with a syntax error when trying to load):
muh = 192.168.1/24
fuh = 192.168.4/24
wibble = { $muh $fuh }
I've tried it with commas, with one macro and one literal, with
non-abbreviated style (i.e. 192.168.1.0/24), etc., but nothing seems to
work.
Recursive macros work normally with individual hosts, but not netblocks.
Is this a feature or a bug?
quirk in the parser--need more quotes.
net1 = '172.16.0.0/12'
net2 = '192.168.0.0/16'
net3 = '10.0.0.0/8'
rfc1918 = { $net1 $net2 $net3 }
-j
--
I'll leave the world the same way I came into it - dirty, screaming
and torn away from the woman I love.
--The Simpsons
Re: configuring multiple firewalls
On Thu, Feb 17, 2005 at 02:53:41PM +1300, Russell Fulton wrote: Hi Folks, WE are currently using two pf boxes as perimeter firewalls for our campus network. These are configured between two switches and operate as bridges in spanning tree mode (with pfsync for state sharing). We are considering moving to a situation where each of the firewalls is connected to a separate switch in the core and we use carp to load balance between the two systems. [snip] At this point we will move the FW from bridge to L3 devices and use carp to do load balancing. We will probably run the lower model in bridge mode first. Are there any obvious flaws with this set up? or any thing we should be careful of when moving? I just sort of did this (but it was from SunScreen in L2 mode) to L3 obsd/pf/carp. I'm still waiting around for some hardware to set up the CARP part, but the main things you may run into: - Routing table changes the border router needs to know how to see the rest of the network. Routing protocols would help a lot, but I was using static routes. So I had to put in ip route blah statements in IOS. - time for potential renumbering cutover (ie: there are now two routers stuck in the place where there used to be one) That was really the only stuff I ran into. Do remember to add rules for carp traffic and pfsync traffic in your pf.conf. toodles, -- adam
