Topics

The current "IDS" package in OPNsense, (Suricata IDS) is fresh enough that I don't understand where the packets get filtered.

I'm curious about the interaction between the Suricata IDS, and PF, when using the package in "IPS" mode?

• Does PF filter the packet first, or does the IPS?
  
• 
  Can the Suricata rules be picked up by PF rules, (particularly rules which redirect the packet in some way- not block or deny?)
  
• 
  Is Suricata really best to stand alone, (perhaps as an inline transparent bridge?)
  

The idea of filtering packets based on various packet content matches is obviously quite a powerful tool, and I'd love to know where the edges are here in OPNsense!

Dipping my toe in, content-based deny is quite sweet to see in action here!  The IPS feature is just plain awesome.  I've never used suricata before, so I've got a few questions about how it works on OPNsense before I dive into suricata itself.

Regarding hardware offloading, it's not entirely clear to me which offloading would affect which rulesets.  For example applied use, blocking Bittorrent on a network with rules concerning user-agent detection,

"ET P2P Bittorrent P2P Client User-Agent (Bittorrent/5.x.x)"
http://doc.emergingthreats.net/bin/view/Main/2006372

For matches like this based on packet conent, I'd love to know if the hardware offloading really gets in the way?

• - packet checksum offloading will obviously break packet known-signature rules, but would it affect content based rules?
  
• 
  - TSO and LRO offloading obviously will obviously break packet signature and rules looking for specific packet fragmentation, but will they affect content rules?
  

The reason I'm asking here is that this new Suricata implementation opens up a whole new world of content-based packet filtering, and I'm looking to find the lines where it plays nicely with other features I care about, (hardware offloading becomes important to me on large and small networks alike!)

Excited to be using this now, and to see this feature set become more refined as more people use it!

Based on the prior work of Chie Taguchi, JP is in the home stretch!

http://dotike.github.io/opnsense.core.ja_JP.UTF8/
https://github.com/opnsense/core/blob/b18c8589ede06ab850a5c768400e0939a0690dc4/lang/ja_JP.po

The JP project needs translator help to get it over the line!

Por favor, desculpe esta tradução automática:

Eu sei que há um número de pessoas Portugueses brasileiros que pode estar interessado em OPNsense em sua língua nativa.

Eu estou trabalhando atualmente na reconstrução do Inglês .pot / arquivo de tradução gettext, aqui:

https://github.com/dotike/opnsense.core.ja_JP.UTF8/blob/locale.EN.canonical/src/share/locale/en/LC_MESSAGES/OPNsense.pot

Ela pode servir como base para traduzir a interface do usuário OPNsense para qualquer idioma. Quando estiver completo, eu vou acompanhar esta discussão!

--
I know there are a number of Brazilian Portugese people who may be interested in OPNsense in their native language.

I am currently working on rebuilding the English .pot/gettext translation file, here:

https://github.com/dotike/opnsense.core.ja_JP.UTF8/blob/locale.EN.canonical/src/share/locale/en/LC_MESSAGES/OPNsense.pot

It can serve as the base for translating the OPNsense user interface into any language.  When it is complete, I'll follow up on this thread!

Best,
.ike

Re-generating EN canonical .pot file, building from the ground up.
By the end, a completely fresh, and code-accurate .pot file will exist- (but will still need some hacking to make the UI php/gettext pick up the right .pot file)

The old .pot files were discarded, (fresh start for OPNsense), a new English gettext .pot file needs to be created as a canonical base, (for all other languages to follow).  Perhaps if other languages dominate, 'en' won't be canonical- but at the moment, it most certainly is.

再生成するゼロから構築、EN標準的な.POTファイルを。
年末までに、完全に新鮮な、とコードの正確な.POTファイルが既存します（まだUIのPHPを作るためにいくつかのハッキングが必要になります/右.POTファイルを拾うのgettext）

古い.POTファイルは、（新たなスタートOPNsense用）、（他のすべての言語が従うことのために）ファイル.POT新しい英語のgettextは、標準的なベースとして作成する必要があり、廃棄した。他の言語が支配している場合、おそらく、「EN」canonical-されませんが、現時点では、それは最も確かにある。

--
Before work can really be unleashed on JA translation, the EN base really needs to get done.
作業は本当にJA翻訳に解き放たれる前に、ENベースは本当に片付ける必要がある。

This en first pass is in progress here, I'll keep chipping at it as I can make time this week:
このEN最初のパスは、私はこの週時間を作ることができますように私はそれを欠けておこう、ここで進行中です。

https://github.com/dotike/opnsense.core.ja_JP.UTF8/commits/381eeb644fc223412e17927aff98a925f3477022/src/share/locale/en/LC_MESSAGES/OPNsense.pot

On the wiki page,

Additional suggestion for USB media install lines, the OpenBSD line is just how it works, but the MacOSX line is an optional (yet arguably more reliable) method.

--
OpenBSD:

  dd if=OPNsense-XXX-memstick-amd64.img of=/dev/rsd6c bs=16k

The device must be the ENTIRE device (in BSD language, the 'c' partition), and a raw I/O device (the 'r' in front of the device "sd6"), not a block mode device.

--
MacOSX

  sudo dd  if=OPNsense-XXX-memstick-amd64.img of=/dev/rdiskX bs=64k

where r = raw device, and where X = the disk device number of your CF card (check Disk Utility) (ignore the warning about trailing garbage - it's because of the digital signature)

全体OPNsenseプロジェクトにあった、すべてのJP翻訳作業のためのライセンスは、2条項BSDライセンスの下で落ちる必要があります。
In accord with the entire OPNsense project, the licence for all JP translation work should fall under the 2-clause BSD licence.

古いpfSense JPの翻訳作業の用語はambigiousであるため、そのことを、このOPNsenseの翻訳作業は、新鮮な開始されます。
With that, because the terms of the old pfSense JP translation work is ambigious, this OPNsense translation work will be starting fresh.


古い作品をここで参照することができます。
The old work can be referenced here:
https://raw.githubusercontent.com/pfsense/pfsense/07cf6e6e0454dc730f2916e54bbf2b9a569fc812/usr/local/share/locale/ja/LC_MESSAGES/pfSense.po
（Taguchiさんはほとんど重い翻訳作業のすべてをした！）
(Taguchi-san did almost all of the the heavy translation work!)

[ワークフロー | Workflow :]

こんにちは！  Welcome everybody!

OPNsenseの主催者のおかげで、新しい日本フォーラムが作成されました。
Thanks to the OPNsense organizers, a new Japanese forum has been created.

ワークフロー | Workflow :

メインプロジェクトの邪魔にならないように私たちの仕事を保つために、私は「仕事フォーク」を作成しました。我々は戻って引き渡すための翻訳作業ができたら、それはGitHubのプル要求 - を作成したり、gitのフォーマット - パッチ/ gitの-AMを使用してOPNsenseの人々へのパッチを送信することと同じくらい簡単なのです。
To keep our work out of the way of the main project, I have created a 'work fork'.  Once we have translation work to hand back over, it's as trivial as creating a github pull request- or sending patches to the OPNsense folks using git-format-patch/git-am.

https://github.com/dotike/opnsense.core.ja_JP.UTF8

参加したい場合は、このフォーラムに投稿するか、githubのリポジトリの協力者に連絡してください。
If you would like to contribute, please post to this forum, or contact the github repository collaborators.

Best,
.ike

Hi All,

We're eager to focus now on making a working Japanese translation for OPNsense, we did it for pfSense before, but it did not yet work out, (notes below).

- What's the state of internationalization in the OPNsense user interface?

- Is there a plan to use gettext, or is there some other plan?

- I see that all file locations are happily quite different for the UI, as you folks are shearing it away from FreeBSD /src, good work!  But in the meantime, I can only find internationalized files for a few .js files.  (File list noted below, for the record).

- Is it possible to add a Japanese International forum?

Thanks!

Best,
.ike





--
Our history:

Last year, the pfSense user interface had been translated completely into Japanese.  Yet, with no build tools at the time the work was completed, it was never really able to be used, and the work stalled out.

The bulk of our effort can be seen in this one .po file:
https://raw.githubusercontent.com/pfsense/pfsense/07cf6e6e0454dc730f2916e54bbf2b9a569fc812/usr/local/share/locale/ja/LC_MESSAGES/pfSense.po

The overwhelming majority of the translations were completed by Chie Taguchi.

We were able to build on top of the excellent work the Brazilian Portuguese translation, (pt_BR.ISO8859-1)- they did the heavy lifting using gettext for the interface internationalization some years ago- making the translation files simple to find, and start working with.

--
Files list:

In pfSense, the .po gettext translation files were here, for Portuguese (Brazil) and English translations,
<pfsense-repo>./usr/local/share/locale/pt_BR.ISO8859-1/LC_MESSAGES/pfSense.po
<pfsense-repo>./usr/local/share/locale/en/LC_MESSAGES/pfSense.pot

/usr/local/share/locale is not at all a good location for the UI translation files, as it resides in the FreeBSD src base.

Some place more naturally packaged with the UI:
<core>./src/www/themes/locale/
Plus,

The only remnants of pt_BR I can find in the code are currently:

$ find . -name '*pt_BR*' -print
./src/www/themes/opnsense/assets/javascripts/bootstrap-select/js/i18n/defaults-pt_BR.js
./src/www/themes/opnsense/build/js/i18n/defaults-pt_BR.js
./src/www/themes/opnsense/build/js/i18n/defaults-pt_BR.min.js
./src/www/themes/sample/assets/javascripts/bootstrap-select/js/i18n/defaults-pt_BR.js
./src/www/themes/sample/build/js/i18n/defaults-pt_BR.js
./src/www/themes/sample/build/js/i18n/defaults-pt_BR.min.js
$

Hi All,

I'm failing to light up cxgb(4) Chelsio T520-CR 10Gbit fiber cards, (ixgb(4) based cards are working right now).

Running:
15.1.5-4608ae4b6 (amd64)

pfSense dmesg: (working)
http://www.nycbug.org/index.cgi?action=dmesgd&do=view&id=2656
OPNsense dmesg: (not lighting up)
http://www.nycbug.org/index.cgi?action=dmesgd&do=view&id=2657

The drivers don't seem to be compiled into the OPNSense kernel.  Looking at pfSense sources, I'm flummoxed as to where they compile them in, (they must simply be in their internal build tools).

--
I also tried 'if_cxgb_load="YES"' in /boot/loader.conf.local - to no avail, the cards still won't light.
https://www.freebsd.org/cgi/man.cgi?query=cxgb&apropos=0&sektion=4&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html

--
REQUEST FOR DIRECTION FOR WHERE TO FIX THIS (and send patches?):

Are yall' opposed to including the driver in-kernel?
- Downside: if you put one in, why not put *all* network drivers in kernel... (too fat?)
- Upside: OPNSense would support a popular card, right out the box, in-kernel

Or, should I just work on finding the casue of (and resolving) my loader.conf issue, (perhaps with the next 10.1 based build)?

Best,
.ike