> > Of course, I'm a tiny bit of a skeptic, as I really can't see how a stateful > firewall can know which other connections / packets are related without a > lot of the same dodgy shenanigans that goes on now, but at least if you've > gotten rid of the 1-to-N address mangling a fundamental stumbling block is > removed and people can get on and solve the remaining (tractable) problems. > > - Matt
Some applications will still require ALG functionality (or modification) to manage the state in the stateful firewall. The beauty is that this is much simpler if the address and port number on the outside of the stateful firewall are the same as the address and port number inside. It can be reduced, for example to: A->B Connect from A/tcp/29199 to B/tcp/9009 SYN B->A From B/tcp/9009 to A/tcp/29199 SYN ACK A->B From A/tcp/29199 to B/tcp/9009 ACK A->B From A/tcp/29199 to B/tcp/9009 INVITE A/tcp/54450 B->A From A/tcp/9009 to A/tcp/29199 ACCEPT B/tcp/9229 (for A/tcp/54450) B->A From B/tcp/9229 to A/tcp/54450 SYN (ignores if RST in response) A->B From A/tcp/54450 to B/TCP/9229 SYN B->A From B/TCP/9229 to A/tcp/54450 SYN ACK ... Notice how the application was able to poke the holes in both sides because it easily knew the address and port number information since it isn't modified. Both firewalls think that the secondary channel is an outbound connection on both sides. There might be some additional signaling required between the host and the firewall in order to let the firewall know that this is a negotiated connection and the funky combination of states (SYN/SYNACK) is acceptable, but, I think that can be worked around fairly easily. Owen
