PfSense & Quagga OSPF Authentication (and other options)

[node-nine_inc]

Howdy.

First & foremost - thanks tremendously for the awesome project!  pfSense rocks!!!

Anyway, have some questions/issues with the way pfSense is managing quagga ospfd (& some zebra) settings.

1. OSPF authentication
In my dev environment, I'm running OSPF between some Cisco kit and several Linux systems.  I've just added a pfSense system to the fray and am running into a problem with the way pfSense is applying settings for OSPF authentication.  This env is not running MD5.  I've applied a password in the GUI page under "Services -> Quagga OSPFd -> Interface settings".  This does in fact apply the setting 'ip ospf authentication-key xxxxx' to the /var/etc/quagga/ospfd.conf file.  Trouble is, for OSPF authentication to actually be enabled, quagga also requires the setting 'ip ospf authentication' to be applied at the interface level as well.  pfSense's configuration routine needs to add this line, or OSPF authentication doesn't actually get enabled.  A neighborship never forms because OSPF authentication doesn't actually get turned on.

This is proven by the Cisco gear reporting the following during debugs:
Feb  7 00:10:59.518: OSPF: Rcv pkt from 192.168.255.11, FastEthernet0/0 : Mismatch Authentication type. Input packet specified type 0, we use type 1

For reference, this Cisco forum page succinctly explains that this debug output states that authentication is required, but the received packet does not have it set.
https://supportforums.cisco.com/docs/DOC-4663

Although I realize the settings in ospfd get dynamically generated, if you telnet to the ospfd daemon on pfSense and apply the missing auth setting, neighborships successfully establish (until the settings get overwritten again).

2. Quagga options - enable password
As a matter of 'best operational practice', each quagga component has some common settings that really should be applied for security-sake.  Granted, the quagga sockets are only reachable from the local system by default, but still…it's only a couple lines to help increase security.

First thing to note is that applying a password via "Services -> Quagga OSPFd -> Global Settings [Master Password]" sets the 'password' value that is applied to vtys in Zebra & Quagga.  This is great.  I'd like to request that the 'enable password' also get set.  It would ROCK to be able to set this to a separate value.  This way, lower-level operational staff could be granted access to the exec-level prompt in Zebra & Quagga for first-level access and diagnostic ability.

3. Quagga options - service password-encryption
Again, simple one-liner mod requested.  Applying the setting 'service password-encryption' by default (doesn't even need to be a toggleable setting) obfuscates the credentials contained in the Zebra & Quagga settings.  If this trivial option is not set, then credentials are clear-text readable in the running-config of zebra/quagga and the related config-text-files in /var/etc/quagga.

The first point is a 'broken' implementation.  The second two points are just best to have, so not critical, but definitely preferred settings.

I haven't yet started digging through developer docs, but if someone could point me to where these settings are controlled in the backend, I'll gladly submit patches to correct these settings.

Cheers,
-Chris

[trendchiller]

Fix is on its way…
i have it working here...
now i hope it will be approved as a pkg-update ;-)