"default deny rule", the nightmare.

[Anyel]

Hello,

Since update to version 22.1, the firewall that worked perfectly, started to work in a chaotic way. The most diverse possible problems. Ok, with patience, workarounds were done, however, in version 22.1.1, I have a problem that I can't solve, some rules just don't work. For example, I've already released port 443 anyway and it always falls into "default deny rule".

What can I do? Do you need I tell/show you something else? What?

Thanks.

[Patrick M. Hausen]

Please show all details of the rule that is suposed to "catch" those packets and all details of one of the packets.

[Anyel]

Pmhausen, thank u for ur reply and for ur time.

Details below.

If u need any more information, just let me know.

Tks.

Code Select Expand



Frame 70: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 17, 2022 03:46:07.586047000 Hora oficial do Brasil
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1645080367.586047000 seconds
    [Time delta from previous captured frame: 0.005240000 seconds]
    [Time delta from previous displayed frame: 0.005240000 seconds]
    [Time since reference or first frame: 2.178101000 seconds]
    Frame Number: 70
    Frame Length: 74 bytes (592 bits)
    Capture Length: 74 bytes (592 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp]
    [Coloring Rule Name: Bad TCP]
    [Coloring Rule String: tcp.analysis.flags && !tcp.analysis.window_update && !tcp.analysis.keep_alive && !tcp.analysis.keep_alive_ack]
Ethernet II, Src: 86:00:00:c5:5b:c3 (86:00:00:c5:5b:c3), Dst: 86:00:00:ba:44:a8 (86:00:00:ba:44:a8)
    Destination: 86:00:00:ba:44:a8 (86:00:00:ba:44:a8)
        Address: 86:00:00:ba:44:a8 (86:00:00:ba:44:a8)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: 86:00:00:c5:5b:c3 (86:00:00:c5:5b:c3)
        Address: 86:00:00:c5:5b:c3 (86:00:00:c5:5b:c3)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.0.0.4, Dst: 163.181.56.154
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 60
    Identification: 0x7d94 (32148)
    Flags: 0x40, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 63
    Protocol: TCP (6)
    Header Checksum: 0xd7d4 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 10.0.0.4
    Destination Address: 163.181.56.154
Transmission Control Protocol, Src Port: 59868, Dst Port: 443, Seq: 0, Len: 0
    Source Port: 59868
    Destination Port: 443
    [Stream index: 4]
    [Conversation completeness: Incomplete, SYN_SENT (1)]
    [TCP Segment Len: 0]
    Sequence Number: 0    (relative sequence number)
    Sequence Number (raw): 1180875598
    [Next Sequence Number: 1    (relative sequence number)]
    Acknowledgment Number: 0
    Acknowledgment number (raw): 0
    1010 .... = Header Length: 40 bytes (10)
    Flags: 0x002 (SYN)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...0 .... = Acknowledgment: Not set
        .... .... 0... = Push: Not set
        .... .... .0.. = Reset: Not set
        .... .... ..1. = Syn: Set
            [Expert Info (Chat/Sequence): Connection establish request (SYN): server port 443]
                [Connection establish request (SYN): server port 443]
                [Severity level: Chat]
                [Group: Sequence]
        .... .... ...0 = Fin: Not set
        [TCP Flags: ··········S·]
    Window: 64860
    [Calculated window size: 64860]
    Checksum: 0xee2f [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    Options: (20 bytes), Maximum segment size, SACK permitted, Timestamps, No-Operation (NOP), Window scale
        TCP Option - Maximum segment size: 1410 bytes
            Kind: Maximum Segment Size (2)
            Length: 4
            MSS Value: 1410
        TCP Option - SACK permitted
            Kind: SACK Permitted (4)
            Length: 2
        TCP Option - Timestamps: TSval 1877874971, TSecr 0
            Kind: Time Stamp Option (8)
            Length: 10
            Timestamp value: 1877874971
            Timestamp echo reply: 0
        TCP Option - No-Operation (NOP)
            Kind: No-Operation (1)
        TCP Option - Window scale: 7 (multiply by 128)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 7
            [Multiplier: 128]
    [Timestamps]
        [Time since first frame in this TCP stream: 1.010634000 seconds]
        [Time since previous frame in this TCP stream: 1.010634000 seconds]
    [SEQ/ACK analysis]
        [TCP Analysis Flags]
            [Expert Info (Note/Sequence): A new tcp session is started with the same ports as an earlier session in this trace]
                [A new tcp session is started with the same ports as an earlier session in this trace]
                [Severity level: Note]
                [Group: Sequence]
            [Expert Info (Note/Sequence): This frame is a (suspected) retransmission]
                [This frame is a (suspected) retransmission]
                [Severity level: Note]
                [Group: Sequence]
            [The RTO for this segment was: 1.010634000 seconds]
            [RTO based on delta from frame: 61]




[Anyel]

Just letting u know, dns, http etc work normally, ports like https don't. It doesn't matter what I do.

[Anyel]

Nobody?

[Fright]

hi
how server response arrives on lan inerafce as a ingress packet? or i missing something?

[Patrick M. Hausen]

What's in that "Presto" alias?

[Anyel]

Hello, guys. Thanks for replys.

Pmhausen - about Presto: a single host (Ubuntu Server 20.04) isolated for tests (10.0.0.4).

Fright - it's a good question, i don't know. Nothing has changed on our network, only change was the update to version 22.1 and, later, 22.1.1. NAT was set correctly and everything worked.

I did some more tests a little while ago and realized that when I set state type to NONE, just in 443 port, it works, everything works. Also, the wan address appears in log again instead of local address, just this unique change, nothing more.

Now, the most important: why is this happening? What do we miss in terms of security, or what problems might we have by disabling state tracking in this or other rules?

Thanks,

[Fright]

about Presto: a single host (Ubuntu Server 20.04) isolated for tests (10.0.0.4).

shouldn't it be in Source in this case?

what problems might we have by disabling state tracking in this or other rules?

in general it should be applied in exceptional cases. using states will increase security and speed

[Patrick M. Hausen]

@Anyel your first screen shot shows SYN packets FROM 10.0.0.4 to some external hosts. Why should those be allowed if you have a rule using "Presto" as the destination?

Is this about inbound or about outbound traffic?

[Anyel]

I thought no one would ask, I had highlighted it in the images to see if someone could tell me anything about it. Because this is one of the behaviors that I thought bizarre from this version 22.1, we've seen several and I'm not understanding what happens, just trying get it to work, it's the first time I need to set a rule like this. If I don't set this rule there, doesn't work. The general rule above was just for testing, the problem, in this simple configuration, has been on HTTPS port; if I don't set a rule for the destination, deny. (I created dozens of rules, in LAN/Floating and tried countless things, before)

I came up with the idea to create it, as the log pointed to "default deny rule" on my LAN side for packets sent from the server to Presto.

My test has been to do downloads via cli, ping, consume apis etc.

See in the image below what happens if I disable the rule that has presto as destination (https).

If you have ideas or need more information, just let me know.

[Fright]

it looks like some routing\redirection issue - not pass\drop rules.
the server response appears on the wrong interface from which the clien request left and therefore the packet is perceived as "out-of-state" (see SA tcp flag). so first you have to figure out why the server response appears on the lan interface imho

[Anyel]

Hey Fright! Thanks for your reply.

I had to stop and get some sleep. Okay, I'll look for something along those lines.

I'll post later what I find.

[Anyel]

Hey, guyz.

I didn't have to do anything. Version _3 eliminated a good part of the "crazy things" that happened. One last question: is the resolution to problem above the highlighted item?

Tks!

[Fright]

is the resolution to problem above the highlighted item?

your network configuration is still not clear, but i have no idea how this change could affect your issue. I think it was intended more to improve the reliability of internal communications (such as syslog) during states manipulations (like states killing, states table flushing etc.)