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

#1
20.7 Legacy Series / Re: 20.7.4 Success!! PPPoE?
October 28, 2020, 08:13:16 AM
Quote from: bunchofreeds on October 24, 2020, 04:47:09 AM
....
I was wondering what that state of play is with PPPoE in the WAN interface.
...

Yes, I would love to know as well :D
#2
Quote from: TheToto318 on August 30, 2020, 02:23:37 PM
I'm on the same subnet, I made this rules just because the HTTPS requests has to be redirceted to the port 4443 of my host
Yes, that's the issue. If you are on the same subnet your packets to the server are never traversing the firewall as no routing is needed. You can either solve this by moving your server to another subnet or your clients and let the firewall route between those (as it's doing for the wan side as well)

Gesendet von meinem MI 9 mit Tapatalk

#3
Is your client on the same subnet as your NAS device? I would assume that you are not traversing the firewall for a local connection to your NAS and therefore this is not working.

Gesendet von meinem MI 9 mit Tapatalk

#4
Quote from: mb on August 23, 2020, 06:05:59 PM
Quote from: Quetschwalze on August 23, 2020, 09:31:17 AM
Tested with igb interfaces and pppoe on wan (removed VLAN for testing)
Suricata seems to start fine:

..
..

However, it doesn't alert or block on anything.
Then I tried Sensei on the WAN Interface. It starts, but afterwards Internet is gone.
Reports do not show any sessions or blocks.

Hi @Quetschwalze, thanks. Any chances that you can also send a pcap trace? - Sensei is not meant for WAN right now.
Thanks @mb
Yes, No Problem. Just to make sure, you'll need a pcap of suricata/pppoe wan interface traffic?

Gesendet von meinem MI 9 mit Tapatalk

#5
Tested with igb interfaces and pppoe on wan (removed VLAN for testing)
Suricata seems to start fine:

2020-08-23T09:02:28 suricata[76340] [100106] <Notice> -- all 2 packet processing threads, 4 management threads initialized, engine started.
2020-08-23T09:02:28 suricata[76340] [100805] <Notice> -- opened netmap:pppoe1/T from pppoe1: 0x172871fd300
2020-08-23T09:02:28 suricata[76340] [100805] <Notice> -- opened netmap:pppoe1^ from pppoe1^: 0x172871fd000
2020-08-23T09:02:28 suricata[76340] [100798] <Notice> -- opened netmap:pppoe1^ from pppoe1^: 0x17236be4300
2020-08-23T09:02:28 suricata[76340] [100798] <Notice> -- opened netmap:pppoe1/R from pppoe1: 0x17236be4000


However, it doesn't alert or block on anything.
Then I tried Sensei on the WAN Interface. It starts, but afterwards Internet is gone.
Reports do not show any sessions or blocks.
#6
Quote from: bunchofreeds on June 13, 2020, 10:50:56 PM
Thanks for looking into this @mb

I have put the 20.7 proxmox virtual instance of OPNsense inline with PPPoE by backing up my 20.1 config and restoring to 20.7. Really easy to do and was up and running quickly.

Suricata runs successfully and alerts on the LAN interface (Virtio)
Switched to run on the WAN interface and am not receiving alerts. The new log view with v5 Suricata is different and seems to cycle with this when trying to establish IPS on the PPPoE WAN

   Counter | TM Name | Value
   ------------------------------------------------------------------------------------
   Date: 6/14/2020 -- 08:49:09 (uptime: 0d, 00h 08m 17s)
   ------------------------------------------------------------------------------------
   flow.memuse | Total | 7154304
   tcp.reassembly_memuse | Total | 196608
   tcp.memuse | Total | 1146880
   flow_mgr.rows_skipped | Total | 65536
   flow_mgr.rows_checked | Total | 65536
   flow.spare | Total | 10000
   ------------------------------------------------------------------------------------
   Counter | TM Name | Value
   ------------------------------------------------------------------------------------
   Date: 6/14/2020 -- 08:49:01 (uptime: 0d, 00h 08m 09s)
   ------------------------------------------------------------------------------------
   flow.memuse | Total | 7154304
   tcp.reassembly_memuse | Total | 196608
   tcp.memuse | Total | 1146880
   flow_mgr.rows_skipped | Total | 65536
   flow_mgr.rows_checked | Total | 65536
   flow.spare | Total | 10000
   ------------------------------------------------------------------------------------

I am getting the ifconfig -a to you via PM

Here is the log when it successfully runs on the LAN interface

   flow.memuse | Total | 7177096
   tcp.reassembly_memuse | Total | 231424
   tcp.memuse | Total | 1146880
   flow_mgr.rows_maxlen | Total | 1
   flow_mgr.rows_skipped | Total | 65534
   flow_mgr.rows_checked | Total | 65536
   flow_mgr.flows_notimeout | Total | 2
   flow_mgr.flows_checked | Total | 2
   flow.spare | Total | 10000
   flow_mgr.new_pruned | Total | 9
   app_layer.flow.failed_udp | Total | 40
   app_layer.tx.dns_udp | Total | 20
   app_layer.flow.dns_udp | Total | 6
   app_layer.flow.failed_tcp | Total | 4
   app_layer.tx.dhcp | Total | 2
   app_layer.flow.dhcp | Total | 1
   app_layer.flow.tls | Total | 3
   tcp.overlap | Total | 1
   tcp.rst | Total | 16
   tcp.synack | Total | 9
   tcp.syn | Total | 9
   tcp.sessions | Total | 9
   flow.udp | Total | 47
   flow.tcp | Total | 39
   decoder.max_pkt_size | Total | 1514
   decoder.avg_pkt_size | Total | 474
   decoder.udp | Total | 320
   decoder.tcp | Total | 988
   decoder.ethernet | Total | 1594
   decoder.ipv6 | Total | 2
   decoder.ipv4 | Total | 1306
   decoder.bytes | Total | 756423
   decoder.pkts | Total | 1594
   capture.kernel_packets | Total | 1594
   ------------------------------------------------------------------------------------
   Counter | TM Name | Value
   ------------------------------------------------------------------------------------
   Date: 6/14/2020 -- 09:10:57 (uptime: 0d, 00h 01m 52s)
   -----------------------------------------------------------------------------------

I'm having the same result on my Qotom Installation with intel interfaces. I'm using pppoe over VLAN as WAN Interface. It would be really awesome to have netmap support for setups like that :)
#7
It still say's pending when I hover my selected language (German)
Since it's been like this since I registered (almost a month ago), I'm not sure whether I need to do anything else?
#8
Great, will do!

Gesendet von meinem MI 9 mit Tapatalk

#9
Quote from: franco on May 20, 2020, 08:55:13 AM
German is only at 75% translated although it has the most translators assigned. All non-translated strings are displayed in English. What you are seeing is the result of the situation.


Cheers,
Franco
How could one help with the translation?

Gesendet von meinem MI 9 mit Tapatalk

#10
Quote from: qarkhs on May 08, 2020, 05:14:33 PM
Take a look at Fitlet2 with J3455: https://fit-iot.com/web/products/fitlet2/
I can recommend that as well, great devices!

Gesendet von meinem MI 9 mit Tapatalk

#11
Quote from: scrensen on March 22, 2020, 02:27:18 PM
Ok, makes sense.

So I got Sensei to work, but then I found my wifi access point (Unifi AP-HD) stopped working right after.

And after some troubleshooting I saw that it could not reach the controller anymore (running on server in same LAN). Since Sensei was the only and most recent change in my network I disabled it and within seconds the UAP-HD came online again an I was able to adopt it again in the controller.

So it seems Sensei is blocking my Unifi AP to reach the controller (http://ip-of-controller:8080/inform) somehow. I'm using the hostname.domain of my controller, perhaps it's something to do with DNS being blocked or so?
Pretty sure that's the cause. You probably need to whitelist that URL. Verify that sensei is the cause via Reports-Blocked-Live blocked sessions
This will show everything being blocked right now. If you see your unifi URL there just whitelist it.

Gesendet von meinem MI 9 mit Tapatalk

#12
@mb sensei is still running very smooth for me [emoji3]
Any news/eta on those botnet and DNS tunneling features already shown in the policy?

Gesendet von meinem MI 9 mit Tapatalk

#13
19.7 Legacy Series / Re: IPsec traffic dissapearing?!
December 30, 2019, 04:34:42 PM
If it's a route-based IPsec you might want to check your routes and your Firewall ruleset.
If it's policy-based check if your Security Associations are correct.

Gesendet von meinem MI 9 mit Tapatalk

#14
I was playing around with the feature a bit and only got it to work properly when using the FlowQueue-CoDel scheduler type (Firewall -> Shaper -> Settings -> Pipes -> Edit Pipe in advanced mode). However it was never really shaping to the target rate I set but to some values around that - might need more playing around with it :)
Also you may want to try and set the direction in the ruleset: "Out" for Upload Pipes and in for Download
#15
Got it, so PPPoE is not the problem here. You mentioned that your WAN Interface is a VLAN. Did you try to run suricata on the parent interface? It may be worth a try.