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.
(https://i.imgur.com/JoJsgaf.png)
Please show all details of the rule that is suposed to "catch" those packets and all details of one of the packets.
Pmhausen, thank u for ur reply and for ur time.
Details below.
If u need any more information, just let me know.
Tks.
(https://i.imgur.com/w9pYrMh.png)
(https://i.imgur.com/mWNJeBD.png)
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]
Just letting u know, dns, http etc work normally, ports like https don't. It doesn't matter what I do.
Nobody?
hi
how server response arrives on lan inerafce as a ingress packet? or i missing something?
What's in that "Presto" alias?
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,
(https://i.imgur.com/yOC734D.png)
(https://i.imgur.com/A01kYal.png)
Quoteabout Presto: a single host (Ubuntu Server 20.04) isolated for tests (10.0.0.4).
shouldn't it be in Source in this case?
Quotewhat 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
@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?
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.
(https://i.imgur.com/e7TvAjg.png)
(https://i.imgur.com/0vEaCm3.png)
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
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.
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!
(https://i.imgur.com/XRP9VYI.jpg)
Quoteis 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.)
That change should make no difference here. It relates to traffic inbound to loopback address.
Cheers,
Franco
After upgrading to 22.1.2_1. same problem.
Check the order of your firewall rules on each network. By default, rules are followed from top to bottom, so if you have blocked some network gaining access to any hosts on network where your alias hosts lie, you have to move rule allowing the access above the block rule.
If you are trying to get HTTPS work, then go to Firewall ---> NAT, create new rule, interface is the interface of a network to which alias host belongs to, direction is out, source is "XXX net" destination is alias destination port is http, redirect to is your alias and redirect port is https, also set "NAT reflection" to enable, then apply and save changes.
After that you go to Rules ---> select your network where your alias is and make sure the port forwarding rule is there and move it above to any rules that might block the connection
Only point where you need to use firewall rules to allow connections between internal networks, is when network in question don't have "allow all" default rules and / or block rules between eachother.
Oh, and obviously make sure server you are trying to connect to is listening HTTPS port and also it's firewall isn't blocking https <---- has been reason why my servers haven't worked as they should quite a few times ^^
@Fright - Network is very simple.
It is a cloud/kvm environment. There is a mandatory gateway (layer 3), 10.0.0.1, with a NAT for 10.0.0.2 (OPNSENSE). In the environment, there is a route for all destinations to go through 10.0.0.2 (0.0.0.0/0 via 10.0.0.2). DHCP is done by 10.0.0.1 and it is not possible to change that, to get to 10.0.0.2 it is necessary to go through 10.0.0.1, also not possible to change. Everything worked fine for a long time.
Got it, @Vilhonator, and there's already been tested evertything in NAT. It doesn't change anything at all, I spent a couple of hours testing again it now, nothing. What really makes it work is change state tracking to none. Nothing else worked.