quietly....

Thu Feb 3 06:40:02 UTC 2011

> 
> 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