OPNsense Forum
English Forums => Intrusion Detection and Prevention => Topic started by: elektroinside on January 17, 2018, 07:57:44 pm
-
So...
Another issue:
- WAN link is PPPoE (it's known IPS won't work with this, yet, because of the freebsd kernel)
- IDS without IPS will list alerts for WAN (even if PPPoE), LAN and also the VPN interface (if you create one and add it to IDS)
- IDS+IPS is only working on the LAN interface, so the VPN interface is also failing to be scanned
I'm guessing this has something to do with the WAN being PPPoE, but can anybody confirm this, please?
Also attached a screenshot with IDS without IPS...
Thank you.
-
Hi there,
So Netmap in FreeBSD is a technique for "real" hardware NIC drivers, not software drivers like PPPoE or tun/tap (OpenVPN), which means that Netmap fails to work properly with them. In contrast, the non-IPS mode is using PCAP, which has had an implementation for virtually all types of packet-pushing-drivers.
You can still catch the traffic that goes from VPN to LAN and back via IPS on LAN, but not traffic from VPN to WAN.
Cheers,
Franco
-
Bloody netmap (kidding of course) :P
Thanks for the info Franco :)
-
Like many good things (in life and tech) it's a great tool but only within its limited scope.
Cheers,
Franco
-
Indeed. Still, PPPoE at least would be nice to be supported, it's not the usual software driver one might think of. While it's old and whatever, it is widely used in many countries, it's not like it's dying...
Also, PPPoE is single-threaded, another annoying implementation... not OPNsense fault obviously, none of them.
-
Well, the PPPoE-not-for-Netmap issue is a bit elusive. Normally, there would still be PPPoE encapsulated traffic on the physical device, but for one reason or another Netmap and/or Suricata are not able to read that traffic. Last time we checked with the Suricata devs they said PPPoE decapsulation is possible, but then that means PPPoE traffic never reaches Suricata in the first place or is encapsulated in a way that makes no sense to Suricata.
It's not even possible to record traffic, because that uses PCAP, and PCAP is fine as mentioned earlier...
https://redmine.openinfosecfoundation.org/issues/1925
The ticket is pretty blank but there was a lot of discussion between several people leading nowhere in particular.
Cheers,
Franco
-
So basically everybody waits for somebody else to do something, a task that should be an otherwise coordinated effort because many things are involved...
This usually will lead to nothing in my experience, unfortunately. Do you think this is a dead-end and will remain like this?
-
You are right. The chance that this is going to resolve itself is tiny. If nobody with the matching skillset, test setup and a whole week of quality time sits down and takes the issue apart we won't get any further.
Cheers,
Franco
-
Sad day it is...
I would need to talk with my ISP, see if there is any possibility to ditch the PPPoE link, way too many issues with it... well none of them critical, just annoying :)
-
If you use a modem in router mode that would work too in front of the OPNsense.
Cheers,
Franco
-
Normally yes, but i need the wan on the OPNsense box to get the 'real' IP, the one assigned by my ISP, otherwise i can't limit connections, i use aliases, and the modem is to dumb to handle/resolve dynamic DNS names... Otherwise, i could put the OPNsense in DMZ and all would be fine.
But I'm a stubborn bastard, I'm refusing to drop the idea of obscurity :P
-
How about implementing atleast something like snort2c.
-
https://github.com/opnsense/core/commit/f326e38
-
I'm not blocking local clients, i'm dropping connections from the internet to the OPNsense box (mostly for NAT, not necessarily the box itself), except a few, some of them being identified by aliases in form of dynamic dns hostnames. If i put my modem in router mode, all the traffic will come from, let's say, 192.168.1.1, which is the modem's internal ip. My aliases (dynamic dns hostnames) won't work, OPNsense will not be able to identify from whom the traffic comes from, to allow it or to block/drop/reject it, as all the traffic comes from eg. 192.168.1.1. And in this case, i'm also double NATting, which is not a good idea (double maintenance at least)...
I am exposing with NAT quite a few ports (delicate services) from a few LAN clients to the internet... well, to a handful of trusted clients coming from the internet anyway, so i'm trusting pf to do what it does best, but nothing else, with emphasis on 'as few points of failures as possible' :)
-
And in this case, i'm also double NATting, which is not a good idea (double maintenance at least)...
I am exposing with NAT quite a few ports (delicate services) from a few LAN clients to the internet... well, to a handful of trusted clients coming from the internet anyway, so i'm trusting pf to do what it does best, but nothing else, with emphasis on 'as few points of failures as possible' :)
I might be wrong, but if a device works in route mode, this implies that it's not NAT-ing anything: route <> NAT/ PAT.
For the rest of it (not quoted) you're right.
Sad day it is...
I would need to talk with my ISP, see if there is any possibility to ditch the PPPoE link, way too many issues with it... well none of them critical, just annoying :)
[Sorry for the off-topic, I'll keep it short] Tell me if you obtained such a thing from ISP, I have the same ISP and bandwidth as you. Maybe it would be a good idea to be several of us to ask for this?!?! :-\
-
My device has two modes: router and bridge. In router mode, it has a working wifi interface, and works just as any commercially available wifi routers, and it is NAT-ing. In bridge mode (this is how it works now) it's basically a fiber media converter (fiber to ethernet), which is not NAT-ing...
Yes, i did have a conversation with them (the ISP). It is possible, but only for legal entities, to sign a contract for a symmetric link with static IP addresses (no PPPoE). The costs are significantly higher though, and the bandwidth lower...
-
I suppose you do have the same Huawei ”all-in-one” crap as I have, doing Media Conversion (from fiber to UTP) + GW/ NAT + DNS FWD + DHCP + Wi-Fi (2.4 GHz only, crappy throughput).
Again, just to be clear (and again, I might be the one who's wrong), but instead of
My device has two modes: router and bridge
you have
My device has two modes: GW/ FW/ NAT and bridge
Again (did I say ”again” for the third time? :) ), as far as I know, a router never does NAT or port forwarding (PAT) - hence FW stuff - it only routes every packet from one interface (IP address) to another interface (IP address). Am I correct? Or maybe I'm not, and with or without NAT/ PAT, there is only one thing, and it's named ”routing”?!?!
PS. I bring up that even in OPNsense, you have the option to disable ”Firewall”, which states in the help comments that
Warning: This will convert into a routing-only platform!
Warning: This will also turn off NAT!
If you only want to disable NAT, and not firewall rules, visit the Outbound NAT page.
This, again, makes me conclude that a router is a router, and only routes packets from one interface to another based on routing rules - but not FW/ GW/ NAT/ PAT rules - never replacing the source IP address (NAT) and/ or source port (PAT) of the originating packet.
-
Oh, sorry, I did not make myself sufficiently clear.
I have a Fiberhome something device (not a Huawei, as my older Huawei lost 70+% of its packets on its way to the internet after 2-3 days of uptime - so they changed it with this Fiberhome crap).
From its web interface (no ssh access), you only have:
- the wifi interface (On/OFF/SID etc) settings page
- there's a PPPoE settings page (for username or password)
- and a "port forward" page
- some administrative stuff (WebGUI user/password)
Nothing else. You can't change anything else.
You can call RDS and ask the support to change one mode with the other. However, you have only 2 modes to choose from:
- RDS calls it "router mode", which has NAT enabled (whether I like or not... and... you can't disable anything, they can't disable anything, the firmware is supposedly locked) -> I will (because they do) call this mode "RDS router mode"
- and there's the bridge mode
I never saw any other options on my RDS devices in "RDS router" mode, I never used this mode (for more than 5 minutes). But in those 5 minutes of using their "RDS router" mode, I had no access to disable nothing except wifi.
All of my business clients (all legal entities of course) are using their devices in bridge mode, and all have static IP addresses without PPPoE, so I couldn't really say what settings RDS exposes for them if I switch to "RDS router" mode. Maybe there you can disable FW/NAT.
So, concluding, I thought all residential RDS devices behave like this, and that's why I didn't explicitly say you cannot use the devices as a routing platform (because you can't, with mine at least). And because they call GW/ FW/ NAT the "router mode", I also used their description, hence the confusion :)
-
Clear now!
In another beam of light, I wonder what should most of users around here think about us, especially reading your signature stating 1 Gb/s download, 0.5 Gb/s upload, since we keep on firing "crappy devices" our ISP is using for residential. :)
-
Indeed, but we also have some advantages though, fiber cables in our homes, gigabit-ish bandwidth everywhere (not just in the country), DDNS (without software clients), most places the link quality is above average...
And I really do have these speeds most of the times, as in my signature, even though they are "best effort" links.
I can't really complain. If only they could drop this PPPoE crap...
I had to know, so I called them again, asked about the business links and devices, routing only modes etc. They use the same devices and firmware and modes for them as well. Oh well..
-
Indeed, but we also have some advantages though, fiber cables in our homes, gigabit-ish bandwidth everywhere (not just in the country), DDNS (without software clients), most places the link quality is above average...
And I really do have these speeds most of the times, as in my signature, even though they are "best effort" links.
Exactly! This is the reason I said what other people around here would think of us since we are complaining and qualifying as "craps" services and devices that offer like 10 to 20 times the medium bandwidth of Europe & America (as continents). And for less than 10$ NETO (final price). :D
I had to know, so I called them again, asked about the business links and devices, routing only modes etc. They use the same devices and firmware and modes for them as well. Oh well..
No, they're not: I know for sure that business clients I service have a simple and straight Media Converter with only 2 ports: UTP and OF (and power supply, of course). No Wi-Fi antennae, no Web UI, no network services (DHCP, DNS etc...). MCs made to work in bridge mode only.
For residential services it's somehow understandable to use cheap, all-in-one devices, since without them 1) clients would perceive the service as incomplete (gone are the days we used a single UTP internet link connected directly in a PC or Laptop), and 2) 99.9% of residential clients would buy even more crappy devices, like Tenda or Netis, since most of them are not choosy, nor experienced enough to tell the difference.
But I guess we're quite off-topic and quite for a while, so let's get beck to VPN + IDPS (or close the case) :)
-
My clients all have Huawei boxes (in bridge mode). Wasn't sure about the firmware though for business clients.
Yeah, you're probably right, we're off topic. Considering the topic closed :D