OpenVPN interface + IDS/IPS

[elektroinside]

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.

[franco]

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

[elektroinside]

Bloody netmap (kidding of course)

Thanks for the info Franco

[franco]

Like many good things (in life and tech) it's a great tool but only within its limited scope.


Cheers,
Franco

[elektroinside]

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.

[franco]

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

[elektroinside]

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?

[franco]

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

[elektroinside]

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

[franco]

If you use a modem in router mode that would work too in front of the OPNsense.


Cheers,
Franco

[elektroinside]

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

[NilsS]

How about implementing atleast something like snort2c.

[franco]

https://github.com/opnsense/core/commit/f326e38

[elektroinside]

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'

[hutiucip]

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?!?!