Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - afk

#1
Hi and thank you very much for your support.

I think i figured out via SSH that the rules were not correclty created by the system.
When i did my last TCP-Flag change, neither connecting to the internet nor communicating with the firewall was possible - but that's nothing bad because I just wanted to test the rules and wanted to know how the system works.
But when i set the change back, the system still didnt come back to normal and the firewall blocked every traffic on each interface - like in an arbitrary way.

After I set the system back to factory settings, everything was fine again.

When I created a "deny all" rule, the access to the internet was still possible but i wasn't able to connect via SSH to the OPNsense.

The point is, that my rule isn't a big deal, but the firewall maybe is not able to deal with the rule.

It's really a pity.
There were so much issues indepently to each other.

I think I will try pfSense now, just to go sure, although I like 100% Open Source Software.


Thank you very much for your support
#2
Hi,
thank you for your help.

I've read something about this and i tried each variation included yours.
But it simply doesn't work for some reason.

I've already read this article as well:
https://forum.netgate.com/topic/124171/when-to-enable-the-tcp-flag-out-of

QuoteIn nearly all cases, you will never need to touch that. It's for making sure some flags are set and others are unset.

So if you have "S" out of "SA" checked it will only match if SYN is set and ACK is not set. This way it can match the first packet of a TCP handshake but not the later packets. That example is the default choice when that control is left alone at the default and the rule is for TCP. 
#3
Hello and thank you for ur support.

I've attached the screenshots


Regards
#4
Hello and thank you very much for your help,

I am just wondering about, that my first rule (Block all incoming traffic which contains just one SYN-Flag) doesn't apply.
I've set the default rules temporary off to check my SYN rule.


Regards
#5
21.1 Legacy Series / How to Block only SYN Flags
May 04, 2021, 07:42:04 PM
Hello,

I've configured a rule which should blocks any incoming TCP traffic on WAN with just a (1) SYN Flag.
So, i checked in the "Advanced Options" in the category "set" just the SYN-Flag and "out of" any other flags.
But if I try to connect via telnet, then it works.

Can anyone please help me? I think this config should be right

Thank you in advance
#6
Solved: There is no way to download the traffic log via Web Gui.

You need to install a syslog server which fetches the logs regarding your OPNsense.
#7
Hi,

is there a way to download the log file with blocked traffic?
I didn't find any article via google regarding this case.


Thank you for your help in advance

Regards
#8
Hi and thank you very much for your help.

You are right - the problem is because of my AP.
After a while, the same problem occurs when I connect to my AP which is in turn directly connected to the router.

I figuerd out, that there r some issues with my AP serie regarding OpenWrt-Software.

Thank you for your help.
I'll close this case now.
#9
Hi,

I've installed OpnSense 21.1 and I got high - non-periodically - problems with the latency.
Additionally, all of my LAN traffic was blocked with my last setup of OpnSense.
But when i did a reinstall, then the LAN traffic wasn't blocked - although i didn't change my settings before.

I have the following connection:  PC -- AP -- OpnSense -- Router -- Internet

My WAN-Port regarding OpnSense is connected to the LAN-Port of the router.

And the ping looks like this (PC ---> Internet):



64 Bytes von 142.250.185.227: icmp_seq=1 ttl=118 Zeit=29.6 ms
64 Bytes von 142.250.185.227: icmp_seq=2 ttl=118 Zeit=190 ms
64 Bytes von 142.250.185.227: icmp_seq=4 ttl=118 Zeit=22.6 ms
64 Bytes von 142.250.185.227: icmp_seq=5 ttl=118 Zeit=23.1 ms
64 Bytes von 142.250.185.227: icmp_seq=6 ttl=118 Zeit=41.2 ms
64 Bytes von 142.250.185.227: icmp_seq=7 ttl=118 Zeit=19.1 ms
64 Bytes von 142.250.185.227: icmp_seq=8 ttl=118 Zeit=22.7 ms
64 Bytes von 142.250.185.227: icmp_seq=9 ttl=118 Zeit=21.3 ms
64 Bytes von 142.250.185.227: icmp_seq=10 ttl=118 Zeit=25.5 ms
64 Bytes von 142.250.185.227: icmp_seq=11 ttl=118 Zeit=21.7 ms
64 Bytes von 142.250.185.227: icmp_seq=12 ttl=118 Zeit=99.2 ms
64 Bytes von 142.250.185.227: icmp_seq=13 ttl=118 Zeit=168 ms
64 Bytes von 142.250.185.227: icmp_seq=14 ttl=118 Zeit=25.5 ms
64 Bytes von 142.250.185.227: icmp_seq=15 ttl=118 Zeit=21.7 ms

--> It's google

the traceroute to the AP looks like this:



64 Bytes von 192.168.1.2: icmp_seq=1 ttl=64 Zeit=200 ms
64 Bytes von 192.168.1.2: icmp_seq=2 ttl=64 Zeit=10.2 ms
64 Bytes von 192.168.1.2: icmp_seq=3 ttl=64 Zeit=6.83 ms
64 Bytes von 192.168.1.2: icmp_seq=4 ttl=64 Zeit=5.21 ms
64 Bytes von 192.168.1.2: icmp_seq=5 ttl=64 Zeit=9.03 ms
64 Bytes von 192.168.1.2: icmp_seq=6 ttl=64 Zeit=5.94 ms
64 Bytes von 192.168.1.2: icmp_seq=7 ttl=64 Zeit=5.96 ms
64 Bytes von 192.168.1.2: icmp_seq=8 ttl=64 Zeit=2.33 ms
64 Bytes von 192.168.1.2: icmp_seq=9 ttl=64 Zeit=5.81 ms
64 Bytes von 192.168.1.2: icmp_seq=10 ttl=64 Zeit=40.7 ms
64 Bytes von 192.168.1.2: icmp_seq=11 ttl=64 Zeit=222 ms
64 Bytes von 192.168.1.2: icmp_seq=12 ttl=64 Zeit=17.9 ms
64 Bytes von 192.168.1.2: icmp_seq=13 ttl=64 Zeit=5.19 ms
 

--> Yes, i thought it could be a problem with my AP but it isn't. The AP works fine if it's directly connected to the router.


Now, you see the latency of the LAN interface, if i ping from my PC:



PING 192.168.1.1 (192.168.1.1) 56(84) Bytes Daten.
64 Bytes von 192.168.1.1: icmp_seq=1 ttl=64 Zeit=24.6 ms
64 Bytes von 192.168.1.1: icmp_seq=2 ttl=64 Zeit=2.05 ms
64 Bytes von 192.168.1.1: icmp_seq=3 ttl=64 Zeit=10.8 ms
64 Bytes von 192.168.1.1: icmp_seq=4 ttl=64 Zeit=5.41 ms
64 Bytes von 192.168.1.1: icmp_seq=5 ttl=64 Zeit=5.27 ms
64 Bytes von 192.168.1.1: icmp_seq=6 ttl=64 Zeit=5.38 ms
64 Bytes von 192.168.1.1: icmp_seq=7 ttl=64 Zeit=4.80 ms
64 Bytes von 192.168.1.1: icmp_seq=9 ttl=64 Zeit=209 ms
64 Bytes von 192.168.1.1: icmp_seq=10 ttl=64 Zeit=7.87 ms
64 Bytes von 192.168.1.1: icmp_seq=11 ttl=64 Zeit=5.71 ms
64 Bytes von 192.168.1.1: icmp_seq=12 ttl=64 Zeit=5.37 ms
64 Bytes von 192.168.1.1: icmp_seq=13 ttl=64 Zeit=4.69 ms
64 Bytes von 192.168.1.1: icmp_seq=13 ttl=64 Zeit=5.24 ms (DUP!)
64 Bytes von 192.168.1.1: icmp_seq=14 ttl=64 Zeit=5.33 ms
64 Bytes von 192.168.1.1: icmp_seq=15 ttl=64 Zeit=5.36 ms
64 Bytes von 192.168.1.1: icmp_seq=16 ttl=64 Zeit=6.30 ms
64 Bytes von 192.168.1.1: icmp_seq=17 ttl=64 Zeit=12.6 ms
 



Now, you see the routing table of OpnSense (WAN) when its try to connect to google.



# /sbin/ping -S '192.168.0.143' -c '10' '142.250.185.227'
PING 142.250.185.227 (142.250.185.227) from 192.168.0.143: 56 data bytes
64 bytes from 142.250.185.227: icmp_seq=0 ttl=119 time=16.459 ms
64 bytes from 142.250.185.227: icmp_seq=1 ttl=119 time=16.107 ms
64 bytes from 142.250.185.227: icmp_seq=2 ttl=119 time=16.416 ms
64 bytes from 142.250.185.227: icmp_seq=3 ttl=119 time=16.794 ms
64 bytes from 142.250.185.227: icmp_seq=4 ttl=119 time=16.379 ms
64 bytes from 142.250.185.227: icmp_seq=5 ttl=119 time=16.308 ms
64 bytes from 142.250.185.227: icmp_seq=6 ttl=119 time=17.875 ms
64 bytes from 142.250.185.227: icmp_seq=7 ttl=119 time=17.599 ms
64 bytes from 142.250.185.227: icmp_seq=8 ttl=119 time=16.238 ms
64 bytes from 142.250.185.227: icmp_seq=9 ttl=119 time=15.693 ms

--> The ping looks okay.

Well, It's also curious when i did a reinstall of OpnSense and the connection to the internet came back without changing anything.

Thank you for your help in advance.