Re: perceived strange behavior
On Thu, Sep 09, 2004 at 08:40:23PM -0400, Jason Opperisano wrote: > all use TCP Port 5190. all three connections appear to stay open once > connected. the simple solution appears to be to set a NAT rule that > only uses 1 translation IP for connections on TCP Port 5190. Or use the 'sticky-address' keyword.
pfsync over ppp
What's the best strategy for letting two machines share pfsync data when you can't dedicate a nic card in each machine to a xover network between the two? My situation involves 1U rack mount boxes without sufficient expansion slots. I've fiddled around with ppp over and ssh tunnel but it's not working, and before I get too far into this method of trying to solve my problem, I figured I'd be smart to ask if anyone had any better ideas.
Re: perceived strange behavior
On Thu, Sep 09, 2004 at 08:40:23PM -0400, Jason Opperisano wrote: > all use TCP Port 5190. all three connections appear to stay open once > connected. the simple solution appears to be to set a NAT rule that > only uses 1 translation IP for connections on TCP Port 5190. Or use the 'sticky-address' keyword. I'm actually only using 1 NAT address, although there are 2 addresses that are binatted (other than the 1 nat address) I'll see if I can get them to put it back in place to get some tcpdumps. It's very interesting, I have many, many more of these types of boxes doing similar jobs and this one is the only one having this issue. The only differences are that this one is 3.5 and the others are either 3.3-stable or 3.4-stable. This box is also substantially newer hardware.
Re: rdr rule
ahhh *lightbulb*
Thanks Daniel!
--Bryan
On Fri, 10 Sep 2004 01:27:13 +0200, Daniel Hartmeier
<[EMAIL PROTECTED]> wrote:
> On Thu, Sep 09, 2004 at 03:21:25PM -0700, Bryan Irvine wrote:
>
> > anyone know why this rule doesn't work?
>
> Because of the way {} lists are simply expanded by pfctl into multiple
> rules. If it were accepted,
>
> rdr from any to ! { a, b } -> c
>
> would become (be equivalent to)
>
> rdr from any to ! a -> c
> rdr from any to ! b -> c
>
> which would match any destination address, since any address is either
> different from a or different from b (assuming a != b), becoming
> equivalent to
>
> rdr from any to any -> c
>
> Hence, the construct is useless and refused by pfctl.
>
> Use a table
>
> table { a, b }
> rdr from any to ! -> c
>
> or a 'no rdr' construct
>
> no rdr from any to a
> no rdr from any to b
> rdr from any to any -> c
>
> Daniel
>
Re: perceived strange behavior
On Fri, 2004-09-10 at 03:11, Ryan McBride wrote: > On Thu, Sep 09, 2004 at 08:40:23PM -0400, Jason Opperisano wrote: > > all use TCP Port 5190. all three connections appear to stay open once > > connected. the simple solution appears to be to set a NAT rule that > > only uses 1 translation IP for connections on TCP Port 5190. > > Or use the 'sticky-address' keyword. yes--precisely. the OP on "other firewall mailing list" was essentially asking for pf's sticky-address feature. forgot where i was posting there for second... -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ I hate it when my foot falls asleep during the day cause that means it's going to be up all night. -- Steven Wright =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: pfsync, carp, transparent bridge
I read that "each carp group has a virtual MAC (link layer) address" http://www.countersiege.com/doc/pfsync-carp/ So if you give an ip addres at each bridge, it should work ? And for pfsync, a dedicated network interface with a crossover cable should work too ? Am I wrong ? Sean wrote: Lyle Worthington wrote: Our firewall is ipless, all traffic just runs through it because it is the only way in or out of our network. CARP and pfsync both needs IPs to operate. In pfsync's case, it'll use multicast or a unicast address. For CARP, failover is on a per IP basis and CARP'ed addresses require an address on an existing interface. cheers, Sean
Re: PF without NAT : filtering, but leaving IP address the same
On Fri, 2004-09-10 at 00:02, Miles Keaton wrote: > All the PF examples and even Jacek's book seem to assume you want to > do NAT : the small-office setup : the one public IP and many > 192.168.0.__ IPs inside. > > But how would PF be used as a router with many incoming IP addresses > and many receiving IP addresses? > > Say I have incoming: from 123.45.67.80 to 123.45.67.89 on a T1 connection. > > One OpenBSD/PF machine is receiving that input on a single NIC card, > and wants to send out some traffic on another NIC card connected to a > switch like this: > > incoming 123.45.67.81 allow port 22,80,443 to go to internal 123.45.67.81 > incoming 123.45.67.82 allow port 22 to go to internal 123.45.67.82 > incoming 123.45.67.83 allow port 22,25,110 to go to internal 123.45.67.83 > > Can PF do this kind of filter-and-route without doing NAT? > If so, any URLs of examples? I can only find examples with NAT. > > Thanks! i'm probably totally missing the point of your post, but here goes: read all that same info and ignore the nat, rdr, and binat statements. pf's filtering does not rely on nat in any way, shape or form. -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ We don't smoke and we don't chew, and we don't go with girls that do. -- Walter Summers =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: PF without NAT : filtering, but leaving IP address the same
On Fri, 2004-09-10 at 16:02, Miles Keaton wrote:
> All the PF examples and even Jacek's book seem to assume you want to
> do NAT : the small-office setup : the one public IP and many
> 192.168.0.__ IPs inside.
>
> But how would PF be used as a router with many incoming IP addresses
> and many receiving IP addresses?
>
> Say I have incoming: from 123.45.67.80 to 123.45.67.89 on a T1 connection.
>
> One OpenBSD/PF machine is receiving that input on a single NIC card,
> and wants to send out some traffic on another NIC card connected to a
> switch like this:
>
> incoming 123.45.67.81 allow port 22,80,443 to go to internal 123.45.67.81
> incoming 123.45.67.82 allow port 22 to go to internal 123.45.67.82
> incoming 123.45.67.83 allow port 22,25,110 to go to internal 123.45.67.83
>
> Can PF do this kind of filter-and-route without doing NAT?
> If so, any URLs of examples? I can only find examples with NAT.
Yes, I have a filtering bridge with 10,000 machines on a /16 behind it.
7500 of these have entries on the firewall (in tables of course).
Just don't specify any NAT rules and you will be fine, everything works
as expected.
Check the syntax here, I'm at home and it's early in the morning...
block in on $ext_if any to any
block out on $ext_if any to any
pass in quick on $ext_if proto tcp from 123.45.67.81 to 123.45.67.81 port={22,80,443}
keep state
pass in quick on $ext_if proto tcp from 123.45.67.82 to 123.45.67.83 port= 22 keep
state
pass in quick on $ext_if proto tcp from 123.45.67.83 123.45.67.83 to port={22,25,110}
keep state
--
Russell Fulton, Information Security Officer, The University of Auckland
New Zealand
Re: PF without NAT : filtering, but leaving IP address the same
> block in on $ext_if any to any
> block out on $ext_if any to any
>
> pass in quick on $ext_if proto tcp from 123.45.67.81 to 123.45.67.81
> port={22,80,443} keep state
> pass in quick on $ext_if proto tcp from 123.45.67.82 to 123.45.67.83 port= 22 keep
> state
> pass in quick on $ext_if proto tcp from 123.45.67.83 123.45.67.83 to
> port={22,25,110} keep state
Beautiful! Thanks so much. I didn't realize it was that easy.
Re: pfsync over ppp
Dylan Martin wrote: What's the best strategy for letting two machines share pfsync data when you can't dedicate a nic card in each machine to a xover network between the two? My situation involves 1U rack mount boxes without sufficient expansion slots. I've fiddled around with ppp over and ssh tunnel but it's not working, and before I get too far into this method of trying to solve my problem, I figured I'd be smart to ask if anyone had any better ideas. How about pfsync over IPSec? Ryan committed a patch recently that allows pfsync to use unicast addresses. Seab
