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

Topics - xupetas

#1
24.7, 24.10 Legacy Series / API issues. Again.
December 11, 2024, 07:02:26 PM
Hello,

I got around the issue of the api URI.
Now its a new one. I can't get to set an alias via API:

# curl -s --insecure -u megakey:megapass -X POST https://172.16.0.254:8443/api/firewall/alias/setItem/896eaff6-edfb-4b03-9dca-c2e240681dc0 -H 'Content-Type: application/json' -d '{
  "name": "TESTEALIAS",
  "type": "host",
  "content": "172.16.9.9",
  "descr": ""
}'


I get as a response an {"result":"failed"} message and no alias update.
Note that the UUID for that alias is correct and is visible if i do a get of it.

The httpd daemon log states:

Dec 11 17:58:44 blabla lighttpd[26287]: 172.16.0.30 172.16.0.254:8443 - [11/Dec/2024:17:58:44 +0000] "POST /api/firewall/alias/setItem/896eaff6-edfb-4b03-9dca-c2e240681dc0 HTTP/2.0" 200 19 "-" "curl/7.61.1"
Dec 11 17:58:44 blabla lighttpd[26287]: 172.16.0.30 172.16.0.254:8443 - [11/Dec/2024:17:58:44 +0000] "POST /api/firewall/alias/setItem/896eaff6-edfb-4b03-9dca-c2e240681dc0 HTTP/2.0" 200 19 "-" "curl/7.61.1"



If i set the url to set instead of setItem i get an success message but there is no change of the alias itself.

The http log for that operation is:

Dec 11 17:56:03 blabla lighttpd[26287]: 172.16.0.30 172.16.0.254:8443 - [11/Dec/2024:17:56:03 +0000] "POST /api/firewall/alias/set/896eaff6-edfb-4b03?9dca-c2e240681dc0 HTTP/2.0" 200 18 "-" "curl/7.61.1"
Dec 11 17:56:03 blabla lighttpd[26287]: 172.16.0.30 172.16.0.254:8443 - [11/Dec/2024:17:56:03 +0000] "POST /api/firewall/alias/set/896eaff6-edfb-4b03?9dca-c2e240681dc0 HTTP/2.0" 200 18 "-" "curl/7.61.1"


What am i missing? Thanks so much for your help
#2
24.7, 24.10 Legacy Series / [SOLVED] API - Help?
December 11, 2024, 11:53:21 AM
Hi all,

First, let me apologize because i am not very versatile at using apis.

My question is, i have a user, that is properly authenticating, and i am able to get information from curl --insecure -u "$API_KEY:$API_SECRET" -X GET "$OPNSENSE_URL/api/core/menu/search" as expected.


[
  {
    "Id": "Dashboard",
    "Order": "0",
    "VisibleName": "Dashboard",
    "CssClass": "fa fa-dashboard fa-fw",
    "Url": "/ui/core/dashboard",
    "IsExternal": "N",
    "Visibility": "all",
    "Selected": false,
    "isVisible": true,
    "breadcrumb": "Lobby / Dashboard",
    "depth": 2
  },
  {
    "Id": "License",
    "Order": "1",
    "VisibleName": "License",
    "CssClass": "fa fa-balance-scale fa-fw",
    "Url": "/ui/core/license",
    "IsExternal": "N",
    "Visibility": "all",
    "Selected": false,
    "isVisible": true,
    "breadcrumb": "Lobby / License",
    "depth": 2
  },
  {
    "Id": "Password",
    "Order": "2",
    "VisibleName": "Password",
    "CssClass": "fa fa-key fa-fw",
    "Url": "/system_usermanager_passwordmg.php",
    "IsExternal": "N",
    "Visibility": "all",
    "Selected": false,
    "isVisible": true,
    "breadcrumb": "Lobby / Password",
    "depth": 2
  },


... the list goes on and on, so i assume that authentication is working.

However, if i try to access any of the items via postman, and yes i am basic authenticating, i keep getting the auth login page as i was not authenticated.
For example: /ui/core/license i get a login page as i was not authenticated.
The user that is performing the operations has at the user page, the effective permission of  GUI/All pages set.

Also i have tried with curl and got the same results.

What am i missing?

Thanks for your help
#3
Hello all,

I have this configuration, that was working before the upgrade:

PIA --> opnsense (openvpn) --> host.

PIA forwards a port into opnsense via a openvpn interface that get's natted (portforwared) to host.
Since the upgrade, i lost the ability to do a tcp connection from outside the PIA, thru opnsense, to the host on the port that it specified. I am able to exit the host via the pia tunnel without any issue

However i see traffic inside the host as coming from PIA, so it appears that something is working. Just not able to to a proper tcp connection /syn/synack.
There are rules allowing that all traffic from pia reach the host.

This is an extract of my unfiltered tcpdump. Code is reaching and appears to be leaving the host, thru openvpn into pia:


07:28:32.892295 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.892326 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.893405 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.893455 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.893469 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.893499 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.894146 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.894180 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.894192 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.894216 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.894420 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.894451 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.894613 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.894632 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.895104 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.895126 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.897229 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.897284 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.897285 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.897370 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.897938 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.897993 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.898007 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.898040 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.899480 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.899526 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.899602 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.900198 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.900239 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.904513 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.904567 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.904615 IP host-95-237-116-82.retail.telecomitalia.it.61700 > 172.16.3.7.documentum: UDP, length 849
07:28:32.904627 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20
07:28:32.904692 IP 172.16.3.7.documentum > host-95-237-116-82.retail.telecomitalia.it.61700: UDP, length 20



This is an extract from a tcpdump from a tcp connection connecting from a public ip, into the front of the PIA vpn endpoint, on the port specified. It does reach the host vm, but is unable to do a proper tcp connection, and yes the port on the destination is listening and there is no local firewall on that particular host



tcpdump: listening on veth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
07:29:50.612214 IP (tos 0x0, ttl 54, id 11967, offset 0, flags [DF], proto TCP (6), length 60)
    bing.unammed.isp.telecom.7960 > 172.16.3.7.documentum-s: Flags [S], cksum 0x00df (correct), seq 4120766767, win 64240, options [mss 1238,sackOK,TS val 205320036 ecr 0,nop,wscale 7], length 0
07:29:50.612456 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    172.16.3.7.documentum-s > bing.unammed.isp.telecom.7960: Flags [S.], cksum 0x2ca3 (incorrect -> 0xe663), seq 2016981066, ack 4120766768, win 65160, options [mss 1460,sackOK,TS val 46328494 ecr 205320036,nop,wscale 7], length 0
07:29:51.621210 IP (tos 0x0, ttl 54, id 11968, offset 0, flags [DF], proto TCP (6), length 60)
    bing.unammed.isp.telecom.7960 > 172.16.3.7.documentum-s: Flags [S], cksum 0xfcf4 (correct), seq 4120766767, win 64240, options [mss 1238,sackOK,TS val 205321038 ecr 0,nop,wscale 7], length 0
07:29:51.621271 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    172.16.3.7.documentum-s > bing.unammed.isp.telecom.7960: Flags [S.], cksum 0x2ca3 (incorrect -> 0xe272), seq 2016981066, ack 4120766768, win 65160, options [mss 1460,sackOK,TS val 46329503 ecr 205320036,nop,wscale 7], length 0
07:29:52.630136 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    172.16.3.7.documentum-s > bing.unammed.isp.telecom.7960: Flags [S.], cksum 0x2ca3 (incorrect -> 0xde81), seq 2016981066, ack 4120766768, win 65160, options [mss 1460,sackOK,TS val 46330512 ecr 205320036,nop,wscale 7], length 0
07:29:53.646538 IP (tos 0x0, ttl 54, id 11969, offset 0, flags [DF], proto TCP (6), length 60)
    bing.unammed.isp.telecom.7960 > 172.16.3.7.documentum-s: Flags [S], cksum 0xf514 (correct), seq 4120766767, win 64240, options [mss 1238,sackOK,TS val 205323054 ecr 0,nop,wscale 7], length 0
07:29:53.646565 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    172.16.3.7.documentum-s > bing.unammed.isp.telecom.7960: Flags [S.], cksum 0x2ca3 (incorrect -> 0xda89), seq 2016981066, ack 4120766768, win 65160, options [mss 1460,sackOK,TS val 46331528 ecr 205320036,nop,wscale 7], length 0
07:29:55.670131 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    172.16.3.7.documentum-s > bing.unammed.isp.telecom.7960: Flags [S.], cksum 0x2ca3 (incorrect -> 0xd2a1), seq 2016981066, ack 4120766768, win 65160, options [mss 1460,sackOK,TS val 46333552 ecr 205320036,nop,wscale 7], length 0
07:29:57.771595 IP (tos 0x0, ttl 54, id 11970, offset 0, flags [DF], proto TCP (6), length 60)
    bing.unammed.isp.telecom.7960 > 172.16.3.7.documentum-s: Flags [S], cksum 0xe4f4 (correct), seq 4120766767, win 64240, options [mss 1238,sackOK,TS val 205327182 ecr 0,nop,wscale 7], length 0
07:29:57.771636 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    172.16.3.7.documentum-s > bing.unammed.isp.telecom.7960: Flags [S.], cksum 0x2ca3 (incorrect -> 0xca6c), seq 2016981066, ack 4120766768, win 65160, options [mss 1460,sackOK,TS val 46335653 ecr 205320036,nop,wscale 7], length 0
07:30:01.910112 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    172.16.3.7.documentum-s > bing.unammed.isp.telecom.7960: Flags [S.], cksum 0x2ca3 (incorrect -> 0xba41), seq 2016981066, ack 4120766768, win 65160, options [mss 1460,sackOK,TS val 46339792 ecr 205320036,nop,wscale 7], length 0




What is wrong with this picture?
Was there any change that needs to be done to the openvpn client to allow this configuration? Or any mandatory new configuration on opnsense's interface to allow this again?

Thanks for your help
#4
Hello all,

I had a crash on a opnsense 21.7 (powerloss), and when it came back up the geoip alias was not working.

I've tried to see if the download/key for my geoip list was working, and it is:

root@XXXXX:/usr/local/opnsense/scripts/filter/lib # python3
Python 3.8.12 (default, Sep 20 2021, 23:00:57)
[Clang 8.0.1 (tags/RELEASE_801/final 366581)] on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> from geoip import download_geolite
>>> download_geolite()
{'address_count': 775784, 'file_count': 500, 'timestamp': '2021-10-19T09:47:50', 'locations_filename': 'GeoLite2-Country-Locations-en.csv', 'address_sources': {'IPv4': 'GeoLite2-Country-Blocks-IPv4.csv', 'IPv6': 'GeoLite2-Country-Blocks-IPv6.csv'}}
>>>


The list is active, but it does not work - tested with multiple IP's from a IP range that *is* included.
Also, i have enough table entries to acomodate the list:

# pfctl -sm | grep table-entries
table-entries hard limit 4000000000


Is there a way to see using pfctl that the alias is being loaded? The main simptom of this issue is that the list appears that is not being loaded and thus the rule is doing nothing.
#5
Hello all,

I have been experimenting on HA WSS and WS with HAproxy.
Since the webgui does not support the HA, i selected the pass-trought option and wrote this ACL:

acl is_upgrade hdr(connection) -i upgrade
acl is_websocket hdr(upgrade) -i websocket

However i cannot load it pass that page because it gives an error: text validation error

The ACL is correct. What am i missing?

Thanks for your help!
#6
Hello All,

Thanks for spending your time reading this.

I've been following the how to regarding the API interface for creating/modifying an Alias, that is located in https://docs.opnsense.org/manual/aliases.html.

Inside is stated that one can add an Alias like this:

curl \
  --header "Content-Type: application/json" \
  --basic \
  --user "key:secret" \
  --request POST \
  --insecure \
  --verbose \
  --data  '{"address":"10.0.0.2"}' \
  https://opnsense.firewall/api/firewall/alias_util/add/MyAlias

So, i've built my script like this:
curl \
  --header "Content-Type: application/json" \
  --basic \
  --user "XXXXX:YYYYYYY" \
  --request POST \
  --insecure \
  --verbose \
  --data  '{"Ports":"512"}' \
   https://172.16.0.20/api/firewall/alias_util/add/APP_FORWARD_PORTS

And i keep getting this error {"status":"failed"}.

I've tried to validate the script and credentials by using --data  '{"address":"10.0.0.2"}' for the address and it works perfectly.
So it appears that my issue is related do "Ports".
I tried the script with Ports, Port, port, ports and nothing works.

Also, if i try to list ports from the API Alias it will not display any ports even those that exist:

curl -k -u "XXXXXXX":"YYYYYY" https://172.16.0.20/api/firewall/alias_util/list/EXISTING_PORT

i get:

{
  "total": 0,
  "rowCount": -1,
  "current": 1,
  "rows": []
}

If i try to export, i see the ports via API.

What is the syntax i should use? I don't see the ports directive being used in the manual. Is it not supported?

Thanks for your help.


#7
Hello,

I am having issues in editing my current TS config.
When i try to edit the IP on the rules section, or set it to any, the webgui deletes what i have added.
The behavior is the same if i create a new rule for TS.

This happens on chrome, firefox, and IE with or without incognito mode on.

What am i missing here?

PS: this server is part of a opncluster, i removed the config sync, and the issue remains on the other node as well, so i think we can rule out any issue with the config that might be causing this

Thanks,
Nuno
#8
19.7 Legacy Series / haproxy transparent
August 05, 2019, 05:29:31 PM
Hello all,

Does anyone know when this will be implemented on the main tree of opnsense:

https://forum.opnsense.org/index.php?topic=4609.0

It is quite wanted by a lot of people.

Thanks for a kick ass product!
#9
19.1 Legacy Series / IPSEC con selection fail.
June 06, 2019, 10:19:30 AM
Hello,

I think i might be doing something wrong here.

I have two ipsec phase 1 selections:

conn con1
  aggressive = yes
  fragmentation = yes
  keyexchange = ikev1
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = yes
  installpolicy = yes
  type = tunnel
  dpdaction = none
  left = %any
  right = %any
 
  leftid = con1@vpn
  ikelifetime = 1500000000s
  lifetime = 360000s
  rightsourceip = 172.16.8.0/24
  ike = aes128-sha1-modp1024!
  leftauth = psk
  rightauth = psk
  rightauth2 = xauth-pam
  leftsubnet = 0.0.0.0/0
  esp = aes128-sha1!
  auto = add

conn con2
  aggressive = yes
  fragmentation = yes
  keyexchange = ikev1
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = no
  type = tunnel
  dpdaction = none
  left = %any
  right = %any
 
  leftid = con2@vpn
  ikelifetime = 28800s
  lifetime = 3600s
  rightsourceip = 172.16.8.0/24
  ike = aes128-sha1-modp1024!
  leftauth = psk
  rightauth = psk
  rightauth2 = xauth-pam
  leftsubnet = 0.0.0.0/0
  esp = aes128-sha1!
  auto = add


Why does it then, select always CON1, with every possible option in the identifier section: Distinguished name, user distinguished name, ASN.1 dist. Name, KeyID tag

Error:

With shared secret for CON1:

charon: 11[CFG] <6> looking for XAuthInitPSK peer configs matching 10.0.1.1...X.X.XX.X[con1@vpn]
charon: 11[CFG] <6> selected peer config "con1"

With shared secret for CON2:

charon: 11[CFG] <6> looking for XAuthInitPSK peer configs matching 10.0.1.1...X.X.XX.X[con2@vpn]
charon: 11[CFG] <6> selected peer config "con1"

What am i doing wrong? Who does it defaults back to the con1 always?

Thanks for a ubber product!
#10
Hello,

Since my upgrade from 19.1.4 to 19.1.7 my ldap auth with squid stopped working.
I've looked inside my backup's and found that the auth part of squid.conf has changed:

From:
auth_param basic program /usr/local/etc/inc/plugins.inc.d/squid/auth-user.php

To:
auth_param basic program  /usr/local/libexec/squid/basic_pam_auth -o

What happened to the original basic program auth-user.php? Was it discontinued? How was it replaced?

It is still possible to authenticate against a ldap server with a few lines of configuration:

auth_param basic program  /usr/local/libexec/squid/basic_ldap_auth -b "dc=net,dc=xpto" -f "uid=%s" ipa.net.xpto:33389 -D uid=query_squid_bind,cn=users,cn=accounts,dc=net,dc=xpto -w xxxxxxxxx


external_acl_type memberof %LOGIN /usr/local/libexec/squid/ext_ldap_group_acl -P -R -b "dc=net,dc=xpto" -D uid=query_squid_bind,cn=users,cn=accounts,dc=net,dc=xpto -w xxxxxx  -h ipa.net.xpto:33389 -f
"(&(objectclass=*)(memberof=cn=app_squid_users,cn=groups,cn=accounts,dc=net,dc=xpto)(uid=%uid))"


This works fine, but it's a deviation from using the webgui and I would like to avoid it.
How can it be made ldapauth to work with the configuration passed by the gui?
What am I missing?

Can you help me please?
Thanks
#11
Hello All!

I've finally got around to upgrade to the latest version 19.1.3, on my homelab servers, and on a AMD Phenom i am getting an endless panic/reboot cycle.

The OPNsense runs on a Linux/KVM system, and the interaction is trowing an KVM: Guest triggered AMD Erratum 383.
I've done all i knew, on the kvm side (cpu passsthrough) and nothing. Sometimes it boots. Sometimes it reboots endlessy.

What am i missing? To the best of my knowlege this was not happening on 19.1.

EDIT: Tested upgrading it to the Dev version and the issue is not felt here. The only thing i can think of is that freebsd is having a tantrum.
In 19.1 the version is FreeBSD 11.2-RELEASE-p9-HBSD, on 19.7 the version is FreeBSD 11.2-RELEASE-p8-HBSD.
Form p9 to p8. Why the downgrade?

EDIT2: Nope... just crashed again with the same error  KVM: Guest triggered AMD Erratum 383. It appears that is felt also on 19.7.

Can you plesae help me?

Thanks!
#12
18.7 Legacy Series / Nextcloud backup woops?
August 02, 2018, 05:23:16 PM
Hello all,

I'm having issues getting the nextcloud backup plugin to work. I am having this errors:

config[76475]: Error while fetching filelist from Nextcloud
config[93176]: {"url":"https:\/\/cloud.blablabla.com\/remote.php\/dav\/files\/config\/OPNsense-Backup\/config-pfsense01.net.xpto-2018-08-02_15:53:53.xml","content_type":"text\/html; charset=iso8859-1","http_code":403,"header_size":480,"request_size":326,"filetime":-1,"ssl_verify_result":0,"redirect_count":0,"total_time":1.293437,"namelookup_time":7.6e-5,"connect_time":0.003817,"pretransfer_time":0.029171,"size_upload":878690,"size_download":295,"speed_download":228,"speed_upload":679574,"download_content_length":-1,"upload_content_length":878690,"starttransfer_time":0.032878,"redirect_time":0,"redirect_url":"","primary_ip":"104.28.6.80","certinfo":[],"primary_port":443,"local_ip":"192.168.1.20","local_port":38604}

For what i am able to notice i am getting a 403 http error.
However i am able to upload to the nextcloud  instance with that user using either the browser or the native nextcloud client.

The nextcloud IS able to create the destination dir, so it appears not to be permission related. I just am not able to upload the xml file.

I can also see the opnsense logging in with success to the nextcloud instance:

{"reqId":"W2MlzKwQACkAAE3Xt7QAAAAC","level":1,"time":"2018-08-02T15:39:56+00:00","remoteAddr":"172.16.3.161","user":"config","app":"admin_audit","method":"PROPFIND","url":"\/remote.php\/dav\/files\/config\/","message":"Login successful: \"config\"","userAgent":"OPNsense Firewall","version":"13.0.5.2"}

Can you shed some light on this? What am i missing?

Nuno
#13
Hello All,

After updating, I've lost the place where i used to configure access to the opnsense webgui.
It used to be in system--> Access --> Config

After the upgrade the config part disappeared. Where is it now?
I want to give access to an LDAP user to access the webgui.

Thanks for a wonderful product!
Nuno
#14
Hello all,

I have been trying to upgrade my opnsense 18.1.5 to the latest version and i keep getting this error:

Checking integrity...Child process pid=13361 terminated abnormally: Bus error

On my system console the error is more detailed:

[HBSD SEGVGUARD] [/usr/local/sbin/pkg-static (12794)] Suspension expired.
-> pid: 12794 ppid: 12349 p_pax: 0x850<SEGVGUARD,ASLR,NODISALLOWMAP32BIT>
pid 13361 (pkg-static), uid 0: exited on signal 10 (core dumped)

I have tried to execute pkg-static upgrade -y and i keep getting a coredump on the process.

I have rebooted the server but the problem remains

Can you please help me?

Thanks,
Nuno
#15
17.7 Legacy Series / Netflow not working as expected
November 07, 2017, 05:24:53 PM
Hello all,

I've been trying to get my netflow working with my Argus accounting server with no luck.
My configuration is as showned on attach1.png

If i look inside the firewall, there is indeed a process that i suspect that is the flow analyser:

# 0:00.01 /usr/local/bin/samplicate -s 127.0.0.1 -p 2055 172.16.0.155/9666

I have checked and there is a very slow of data being put my the firewall on my argus accounting server.
I have other softflow devices that are recording data correctly with this configuration.
The same for radium/argus native client.

One issue that i've found is that usual netflow network packets (at least the kind that i am used to) are much smaller that thoose produced by the netflow engine of opnsense: opn packets - 1506 bytes versus usual packets 120 to 280 bytes.

What am i missing here?

Thanks for your product and your help!
#16
Hello all!

I'm using the HAProxy plugin and I needed to run it inline, in transparent mode.
I have been digging around on the forum and found this past thread:

https://forum.opnsense.org/index.php?topic=4609

@Franco,

Have you had the time to see the solution presented by Rosu?

Thanks!
#17
 Hello All.

I've installed the latest version of opnsense and tryed to run suricata.
My HW is a 3 vCore QEMU/KVM (tryed on qemu 2.7 and 2.9) with 2GB of ram and several VIRTIO NICs.

I've pulled the latest rules, and checked if there was updates to be installed.
Both suricata and opnsense are on the latest version.

When i boot suricata in IPS configuration, on the WAN interface, i loose conectivity.
Here's a ping form the firewall to the next hop to demonstrate what appends:

64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=1.135 ms
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=0.991 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=0.595 ms
64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=0.749 ms
64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=0.828 ms
64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=0.803 ms
64 bytes from 192.168.1.254: icmp_seq=6 ttl=64 time=0.766 ms
64 bytes from 192.168.1.254: icmp_seq=7 ttl=64 time=68606.310 ms < Suricata boot
64 bytes from 192.168.1.254: icmp_seq=8 ttl=64 time=68300.215 ms
64 bytes from 192.168.1.254: icmp_seq=10 ttl=64 time=67848.197 ms
64 bytes from 192.168.1.254: icmp_seq=14 ttl=64 time=68108.471 ms
64 bytes from 192.168.1.254: icmp_seq=17 ttl=64 time=67052.875 ms
64 bytes from 192.168.1.254: icmp_seq=18 ttl=64 time=67528.361 ms
64 bytes from 192.168.1.254: icmp_seq=19 ttl=64 time=68002.670 ms
64 bytes from 192.168.1.254: icmp_seq=22 ttl=64 time=67999.273 ms
64 bytes from 192.168.1.254: icmp_seq=23 ttl=64 time=67995.854 ms

There are NO rules loaded for this test, I just started the daemon.

If i stop the IPS mode (active defense) it goes back to normal:

64 bytes from 192.168.1.254: icmp_seq=10 ttl=64 time=38098.266 ms
64 bytes from 192.168.1.254: icmp_seq=15 ttl=64 time=36568.727 ms
64 bytes from 192.168.1.254: icmp_seq=16 ttl=64 time=36987.789 ms
64 bytes from 192.168.1.254: icmp_seq=20 ttl=64 time=37390.267 ms
64 bytes from 192.168.1.254: icmp_seq=21 ttl=64 time=36703.024 ms
64 bytes from 192.168.1.254: icmp_seq=24 ttl=64 time=36385.351 ms
64 bytes from 192.168.1.254: icmp_seq=26 ttl=64 time=51639.619 ms
64 bytes from 192.168.1.254: icmp_seq=27 ttl=64 time=52612.838 ms
64 bytes from 192.168.1.254: icmp_seq=29 ttl=64 time=51815.528 ms
64 bytes from 192.168.1.254: icmp_seq=30 ttl=64 time=51632.411 ms
64 bytes from 192.168.1.254: icmp_seq=32 ttl=64 time=50433.146 ms
64 bytes from 192.168.1.254: icmp_seq=85 ttl=64 time=0.504 ms
64 bytes from 192.168.1.254: icmp_seq=86 ttl=64 time=0.473 ms
64 bytes from 192.168.1.254: icmp_seq=87 ttl=64 time=0.462 ms
64 bytes from 192.168.1.254: icmp_seq=88 ttl=64 time=0.404 ms
64 bytes from 192.168.1.254: icmp_seq=89 ttl=64 time=0.502 ms
64 bytes from 192.168.1.254: icmp_seq=90 ttl=64 time=0.444 ms
64 bytes from 192.168.1.254: icmp_seq=91 ttl=64 time=0.474 ms

Am i missing something or is this a bug?
I need the IPS active to do active defense on my system?
Or can it be run with active defence on legacy configuration thru pcap thus being only and IDS and not a IPS?

Thanks,
Nuno