Of statefull firewall and what not

Re: Private fw for the non tweeker?

The only time inbound TCP SYN packets from an lower security interface are blocked by the higher security interface,
is when the higher security interface DOES NOT exist an INITIATED OUTBOUND CONNECTION with the lower security
interface. (WAN to LAN).


If the inbound TCP SYN packet is traversing through the clients INITIATED OUTBOUND CONNECTION as an REPLY to the
clients outbound TCP SYN packet, then the inbound TCP SYN packet will not be blocked. (LAN to WAN).


So, in most cases, by default, not "all" inbound TCP SYN packets are blocked.


HKEY1952

 

Re: Private fw for the non tweeker?

A SYN packet coming from "a lower security interface" (whatever that may be) should be blocked every time (unless you run a server),
and not just in that case. Read on.

Wrong. A reply to client's outbound initiated connection (a TCP packet with a SYN flag set) is a TCP packet with an SYN/ACK flags set, not a SYN one.
A three-way handshake's already mentioned in this thread. Take a good hard look at the refs on the net and elsewhere.

 

Re: Private fw for the non tweeker?

A stateful firewall would only block an inbound "TCP SYN" packet as a connection attempt. What you put forward, is that an inbound TCP SYN/ACK would also be blocked as an inbound connection attempt, when that could possibly be a reply to an outbound connection. So you cannot simply block all inbound TCP packets with any flag set.

There is a big difference between "Block inbound connections" which is "Block inbound TCP SYN" and "Block all inbound" which would block all inbound TCP with any flag set as I put forward above.

With windows firewall, with the "Block inbound connection" active, yes it blocks inbound connection attempts(TCP SYN), but it does not block, for example, inbound TCP SYN/ACK, because that could be part of an outbound connection reply, it instead allows the packet and checks to see if it is part of a connection, if it is not, then it will reply with a TCP RST/ACK.


- Stem

 

Re: Private fw for the non tweeker?

Knowledge solves many dilemmas.

I'm sick....

 

Re: Private fw for the non tweeker?

The same goes for you, read the post above.

 

Re: Private fw for the non tweeker?

You are linking "Wikipedia" as a reference

With windows firewall, the "block all connections" is a perimeter rule, it does not process those packets, it simply drops them. If that rule was to block all inbound TCP with any flag, then those packet would not be processed to see if they are part of a current connection, therefore all inbound TCP packets would be blocked, including legitimate replies.

- Stem

 

Re: Private fw for the non tweeker?

You are rude and arrogant, aren't you?
I do appreciate your contribution to WF thread,
(specifically the one with tying the event log entry to a trigger that will then produce a pop-up),
but you need to develop a sense for a moment when you need to step down.
You give some wiki link on firewalls and quote a sentence that does not explain anything
(Wikipedia is awful for networking topics, except the most basic ones).
What's a good and what's a bad packet?
How exactly does a firewall distinguish between good and bad packets?
What happens when a packet is rejected?
What if the bad one goes through, what happens then?
Yes, it may be the case of improper terminology (block inbound attempts/block all inbound),
but we need to set this straight.

What can I say... Excellent advice.

A link now please...?

 

Re: Private fw for the non tweeker?

Carefully read the conversation between me and your helper, maybe you'll find wire.
I see, you take the time to loosen these knots like "block all" or whatever and now your helper with "stateful filtering".
Good luck.

I'm sick, and I wish you all very nice weekend..

 

Re: Private fw for the non tweeker?

I was hoping for another link, but...

Likewise.
See you around.

 

Split from original thread.

 

SPARVIERO bit the syn, syn/nak, nak/can, eot and got sick

SEER syn, syn/ack, ack, ack with STEM

 

Connection still open between us, I like that.

Regards,

- Stem

 

Re: Private fw for the non tweeker?

No, Not Wrong, the SYN+ACK packet is an synchronization packet with the acknowledgement flag set, because, it is the
first packet sent from the lower security interface to the higher security interface.

Opening an TCP initialized outbound connection from the higher security interface to the lower security interface
involves exchanging three packets. Those three packets are commonly labled: SYN, SYN + ACK, and ACK.

The TCP header exists SYN (for synchronize) and ACK (for acknowledge) bits.

The first packet, sent from the higher security interface to the lower security interface,
is an synchronization packet,
has the SYN bit set.

The second packet (first packet), sent from the lower security interface back to the higher security interface,
is an synchronization packet with the acknowledgement flag set,
has both SYN + ACK bits set.

The third packet, sent from the higher security interface back to the lower interface,
is an acknowledgement packet,
only has the ACK bit set.


Only the first packet sent from each end should have the SYN bit flag set, because,
Some other flags change meaning based on this flag, and some are only valid for when it is set,
and still others when it is clear.

Also note, that, ALL packets after the initial SYN packet sent by the CLIENT must have the ACK flag set.

.....Therefore:
Before the reply (SYN + ACK) from the lower security interface back to the higher security interface, as an reply,
will be accepted by the higher security interface, there must be an synchronization on the first packet sent
from the lower security interface, so that both ends can initiate and negotiate separate TCP socket connections at
the same time. Being able to negotiate multiple TCP socket connections in both directions at the same time allows
an single physical network interface (such as ethernet) to be multiplexed.

.....Hence:

After synchronization with the lower security interfaces 'SYN' packet, the acknowledgement (ACK) flag is noted and
then the higher security interface sends an acknowledgement (ACK) packet, minus the (SYN) flag, back to the lower
security interface, and the higher security interfaces initiated TCP initialized outbound connection is established.


WATCH THE MOVIE IN THE GRAPHIC PLAY THE INITIALIZED OUTBOUND CONNECTION

TCP Three Way Handshake
(SYN,SYN+ACK,ACK)


EDIT: clarity/completeness


HKEY1952

 

Jeez, guys.....give it a rest. You're both right. HKEY1952 is describing the handshake in a 'classical' manner, Seer is describing it in the way 99% of people would understand it. Read the original RFC and it describes the response to the initial SYN being a SYN,ACK, but then shows the originator going into state "SYN received" on receipt of the SYN,ACK. So the response to the original SYN is indeed SYN,ACK, but the originator of the SYN, after sending it, goes into a state of "awaiting SYN".

So you're both correct.

 

It simply means that the synchronization is done, and ACK packets are now expected.
Here's from HKEY1952 -

- explains the need for a SYN flag in first and second packet.

What was going on here, was that HKEY1952 claimed (let's not quote it, it's quoted twice already on this page) that a reply from a "lower interface" is a SYN, in an attempt to defend his/her view that SYN packets should be allowed on a "higher interface". Wrong path.
Post #13, though looking like a reference transcript, is correct. Except the false quote.
But I think we'll be OK now.

ack

Cheers,

 

The 3-Way Handshake is clearly explained here along with the animated graphic: http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml