Reknamorken wrote:

] Is this a potential mechanism for maintaining state on a
] couple of VRRP'ed OpenBSD pf firewalls???
]
] I know it's not what it's intended for, but you might be able
] to leverage his MAT capability in such a way.

Hrm? I don't see how this helps. Its a proof of concept of the stuff from his defcon talk. The fact that you are "natting at layer 2" really doesn't help you move information between two gateways. Maybe you see something I don't...

Decius wrote:
] Reknamorken wrote:
]
] ] Is this a potential mechanism for maintaining state on a
] ] couple of VRRP'ed OpenBSD pf firewalls???
] ]
] ] I know it's not what it's intended for, but you might be
] able
] ] to leverage his MAT capability in such a way.
]
] Hrm? I don't see how this helps. Its a proof of concept of the
] stuff from his defcon talk. The fact that you are "natting at
] layer 2" really doesn't help you move information between two
] gateways. Maybe you see something I don't...

They will both receive/process packets going through. Just block the packets on the secondary in and out. It will maintain it's own state. Roughly anyway.

Failover by having the secondary just stop being blocked.

Reknamorken wrote:

] They will both receive/process packets going through. Just
] block the packets on the secondary in and out. It will
] maintain it's own state. Roughly anyway.
]
] Failover by having the secondary just stop being blocked.

Thats a novel idea, but this tool doesn't help you do that.

You either put the firewalls on broadcast MACs ala stonebeat or you have hubs. Firewalls see all traffic and perform all functions. Offline firewall can't write anything to the network.

I think this is actually trickier then it sounds. The offline firewall is going to pick certain port numbers/sequence numbers for packets and the responding packets it sees on the network aren't going to correspond to that because the online firewall is making different choices for those things. So you have to coax the offline firewall to store its state information by spying on the online firewall and pulling these peices of information out. I think it probably ends up being easier to just have the online firewall TELL the offline firewall what it needs to know. No screwing around with parsing packets. No possibility that the two get out of sync.

This also doesn't work at all for stuff in encrypted tunnels nor for the actual key data for encrypted tunnels.

BTW, this is the best converstation on memestreams to date. Props. :)

Decius wrote:
] Reknamorken wrote:
]
] ] They will both receive/process packets going through. Just
] ] block the packets on the secondary in and out. It will
] ] maintain it's own state. Roughly anyway.
] ]
] ] Failover by having the secondary just stop being blocked.
]
] Thats a novel idea, but this tool doesn't help you do that.
]
] You either put the firewalls on broadcast MACs ala stonebeat
] or you have hubs. Firewalls see all traffic and perform all
] functions. Offline firewall can't write anything to the
] network.
]
] I think this is actually trickier then it sounds. The offline
] firewall is going to pick certain port numbers/sequence
] numbers for packets and the responding packets it sees on the
] network aren't going to correspond to that because the online
] firewall is making different choices for those things. So you
] have to coax the offline firewall to store its state
] information by spying on the online firewall and pulling these
] peices of information out. I think it probably ends up being
] easier to just have the online firewall TELL the offline
] firewall what it needs to know. No screwing around with
] parsing packets. No possibility that the two get out of sync.
]
]
] This also doesn't work at all for stuff in encrypted tunnels
] nor for the actual key data for encrypted tunnels.
]
] BTW, this is the best converstation on memestreams to date.
] Props. :)

Hrm... Why would the firewall mess with the sequence numbers? I guess it depends on the firewall. A PIX would, but a Checkpoint wouldn't, would it? I mean, the Layer 3+ stuff is all handled by the endpoints isn't it??

Although, now that you bring it up, the spying idea is really good. I bet you $$ this fixes the problems with state updates happening every 100ms (like Checkpoint). The secondary could stay completely up to date. It's not the like the CPU is doing anything important while it's offline anyway. I guess there is a chance of synchronization problems, but it seems unlikely. Also, it doesn't seem like they can get too far out of sync.

This Dan Kaminsky fellow is quite bright. He's in SF. I was thinking about contacting him....

Reknamorken wrote:

] Hrm... Why would the firewall mess with the sequence numbers?
] I guess it depends on the firewall. A PIX would, but a
] Checkpoint wouldn't, would it? I mean, the Layer 3+ stuff is
] all handled by the endpoints isn't it??

You are correct that it depends. If anything, the checkpoint is going to be more trouble then the pix. Things like fragment reassembly and certain kinds of syn defender gateways may cause a little bit of trouble. Eitherway, you are definately going to have to sniff the outbound traffic from the online firewall because you are not going to make the same port number decisions when NATing unless you have a very tight algorithm for this and you can ensure (HA!) that both firewalls are getting all the packets in the SAME ORDER.

] Although, now that you bring it up, the spying idea is really
] good. I bet you $$ this fixes the problems with state updates
] happening every 100ms (like Checkpoint).

I thought that most of the Checkpoints state sync slowness was related to VPN tunnels. If that is the case, this won't help.

] The secondary could
] stay completely up to date. It's not the like the CPU is
] doing anything important while it's offline anyway. I guess
] there is a chance of synchronization problems, but it seems
] unlikely. Also, it doesn't seem like they can get too far out
] of sync.

Far out of sync? One skipped packet will screw up a TCP connnection.
Additional out of syncness has no effect. The question is "How more difficult is this then what people are already doing? How great is the advantage? Does the advantage outweight the cost."

So far I'm not convinced, but I AM playing devils advocate.

] This Dan Kaminsky fellow is quite bright.

Indeed.

Decius wrote:
] Reknamorken wrote:
]
] ] Hrm... Why would the firewall mess with the sequence
] numbers?
] ] I guess it depends on the firewall. A PIX would, but a
] ] Checkpoint wouldn't, would it? I mean, the Layer 3+ stuff
] is
] ] all handled by the endpoints isn't it??
]
] You are correct that it depends. If anything, the checkpoint
] is going to be more trouble then the pix. Things like fragment
] reassembly and certain kinds of syn defender gateways may
] cause a little bit of trouble. Eitherway, you are definately
] going to have to sniff the outbound traffic from the online
] firewall because you are not going to make the same port
] number decisions when NATing unless you have a very tight
] algorithm for this and you can ensure (HA!) that both
] firewalls are getting all the packets in the SAME ORDER.

Ah. You're assuming NAT. I'm assuming a situation without NAT.

Anyway, it's interesting...

Reknamorken wrote:
] Is this a potential mechanism for maintaining state on a
] couple of VRRP'ed OpenBSD pf firewalls???

Connection/state table sharing between netfilter/iptables boxes is currently in the works. There was a BoF on it at the Ottawa Linux Kernel Summit this summer. I forget which dude is currently working on it, but its an active project. I believe people were saying "winter" or "spring" alot in reference to it..

That will enable active/active FWs, SGs & SLB.

- nick