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

#1
Hi,
With the replacement of bsnmpd by net-snmp, we lost the support of the BEGEMOT-PF-MIB providing useful metrics related to PFilter.
That's sad...
Any way to support BEGEMOT-PF-MIB in net-snmp ?
Or does it mean that finally a bnsmpd plugin would be necessary ? In the previous version, we could run both SNMP daemons together...
#2
Quote from: lfirewall1243 on July 23, 2019, 11:33:28 AM
But it seems that the new logging feature is buggy.
Suricata Logs aren't working anymore, squid logs etc. are shown.

But even logs are shown that aren't selected.
According to what I observed on the opnsense logs, it seems the logging configuration changes (applications, levels, facilities, transport...) are not correctly taken in account when saved (even with the patch applied). I had to disable the "Logging / targets" feature and enable it again to get the changes applied.

Once that set, the new syslog forwarding feature works correctly including in TCP mode (sent here to a Filebeat/Elastic/Kibana).
And even without using the new "Logging / targets" page, the legacy forwarding feature works now correctly, being compliant with the syslog standards (especially hostname present). In my understanding, syslog-ng is now also involved when using the legacy log forwarding UI / feature.
#3
See the work in progress on the syslog issues here :
https://github.com/opnsense/core/issues/1228
https://github.com/opnsense/core/issues/1857
https://github.com/opnsense/core/issues/2349

Basically, syslogd is being replaced by syslog-ng at least for the remote sending part and the target release is now 19.1.
#4
It is indeed fixed.

Additional note: do not forget to add the iroute statement in a client specific configuration entry to route within OpenVPN the subnet from client side...
#5
Hold on, I found the mistake: bad certificate selected on client side !
#6
Hello all,

I am trying to setup a LAN to LAN OpenVPN connection between two sites now both running OPNsense on APU appliances.
(It worked previously with pfS*nse installations but with slightly different configurations).

I set as well RAS OpenVPN instances which are working fine.
Regarding the LAN to LAN instance, I am not able to get it working, nor troubleshoot it from the logs. Apparently, the connection doesn't succeed but I don't see any error no problem in the logs.
That's why I am asking for help to troubleshoot and hopefully fix it.
I tried various settings: both peer to peer preshared key and TLS with or without TLS authentication and various cyphers. I also tried both client/server ways.

See the resulting configurations below:

server
dev ovpns2
verb 5
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local <localpublicip>
tls-server
server 172.29.0.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/2
ifconfig 172.29.0.1 172.29.0.2
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'fw0.local' 1"
lport 11194
management /var/etc/openvpn/server2.sock unix
push "route 192.168.0.0 255.255.255.0"
route 192.168.1.0 255.255.255.0
ca /var/etc/openvpn/server2.ca
cert /var/etc/openvpn/server2.cert
key /var/etc/openvpn/server2.key
dh /usr/local/etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server2.tls-auth 0
comp-lzo adaptive
persist-remote-ip
float


client
dev ovpnc2
verb 3
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 172.31.0.2
tls-client
client
lport 0
management /var/etc/openvpn/client2.sock unix
remote <serverpublicip> 11194
ca /var/etc/openvpn/client2.ca
cert /var/etc/openvpn/client2.cert
key /var/etc/openvpn/client2.key
tls-auth /var/etc/openvpn/client2.tls-auth 1
comp-lzo adaptive
resolv-retry infinite

(This client OPNsense is connected behind a router with NAT and an interco subnet in private addressing 172.31.0.x.)
#7
Thanks, it works fine !

Added in the custom options:
server:
local-zone: "168.192.in-addr.arpa" transparent
local-zone: "16.172.in-addr.arpa" transparent


Got in the config file:
# Unbound custom options
server:
local-zone: "168.192.in-addr.arpa" transparent
local-zone: "16.172.in-addr.arpa" transparent


What fixes my problem.

I think you should also think at adding the local-zone statement and setting natively as done in pfSense...

Thanks a lot anyway.
#8
pfSense configuration with native local-zone statement.
#9
I've just tried to implement the same configuration in pfSense and surprisingly it now works fine, probably because an option "System Domain Local Zone Type" was added in the General settings.
#10
So, to sum-up, it seems the main problem is that the advanced settings don't work because the spaces (and tabulations) are turned to carriage returns.

In the "Advanced" web configuration:
local-zone: "168.192.in-addr.arpa" nodefault
local-zone: "16.172.in-addr.arpa" nodefault
statistics-interval: 300
statistics-cumulative: no
extended-statistics: yes


In /var/unbound/unbound.conf:
# Unbound custom option
local-zone:
"168.192.in-addr.arpa"
nodefault
local-zone:
"16.172.in-addr.arpa"
nodefault
statistics-interval:
300
statistics-cumulative:
no
extended-statistics:
yes


What of course induces the following Unbound error:


opnsense: /services_unbound.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '/var/unbound/unbound.conf:115: error: syntax error read /var/unbound/unbound.conf failed: 1 errors in configuration file [1465244973] unbound[47952:0] fatal error: Could not read config file: /var/unbound/unbound.conf'


Can this please be fixed ?
#11
Hello all,

I have a setup with a pfSense instance forwarding (with dnsmasq) to two external Unbound resolvers and two external nsd local authoritative NS.

I am trying to move it to an OPNsense instance embedding the name resolution feature with Unbound.

In the past I abandoned the option to use Unbound embedded in pfSense due to limitations.
I am now rechallenging the issue with OPNsense.

It is working partially but I am still facing a problem with the reverse zones locally hosted: they are not forwarded to the local authoritative NS hosting them.
In the file unbound.conf generated by OPNsense, they are defined as stub zones, private-domain and domain-insecure.
In my original working configuration (running in a Linux instance), they are simply defined as stub and local-zones.

The forward internal zone (glrnet) is however correctly resolved.

See the configuration files in the attachments.

Also, I tried to add the local-zones statements to the advanced custom field, but then Unbound fails to restart. It seems the syntax is not good as each space is turned to a carriage return.

Can you help me ?

; <<>> DiG 9.8.1-P1 <<>> opnsense1.glrnet @192.168.1.253
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59323
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;opnsense1.glrnet.              IN      A

;; ANSWER SECTION:
opnsense1.glrnet.       7191    IN      A       192.168.1.253

;; AUTHORITY SECTION:
glrnet.                 86391   IN      NS      ns.glrnet.
glrnet.                 86391   IN      NS      syno.glrnet.

;; ADDITIONAL SECTION:
ns.glrnet.              86391   IN      A       172.16.0.3
syno.glrnet.            7191    IN      A       192.168.0.251

;; Query time: 0 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Tue May 31 22:46:58 2016
;; MSG SIZE  rcvd: 118


; <<>> DiG 9.8.1-P1 <<>> -x 192.168.1.253 @192.168.1.253
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3644
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;253.1.168.192.in-addr.arpa.    IN      PTR

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   10800   IN      SOA     localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 15 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Tue May 31 22:47:10 2016
;; MSG SIZE  rcvd: 103