Topics

1

General Discussion / Suggestions for a usb console port concentrator for OOBM?

« on: August 14, 2023, 12:04:05 pm »

Hi,
I'm looking for a network accessible device that I can hook the USB consoles of different firewalls to.

• rack mountable
• at least 6 USB ports
• RJ45

Any suggestions?
Thanks a lot

2

Virtual private networks / IPSec: VTI dynamic WAN IP [new config]

« on: August 01, 2023, 12:53:41 pm »

Hi,
I have just tried if I could recreate route based IPSec tunnels with the new configuration interface.
Everything seems to work, but fot the VTI, I have to enter an IP address in the 'Local address' field. How should I handle this when my local IP is dynamic?
In the 'General Settings' of the connection it is possible to leave this field empty.
Thanks and best regards,
Frank

3

22.1 Legacy Series / 'read-onéy' access allows reordering rules

« on: August 12, 2022, 01:47:25 pm »

Hi All,
I have tried to setup a 'read-only' access to the web-gui, with the intention of allowing to allow a given user to look at the config, but not mess with it.
I find that if I give a user access to the gui pages 'without edit' for rules and NAT, he can still reorder the rules.
He can't edit Aliases or rules, but he can still select a rule, and move it around with the <- icon.
Is this expected/known/wanted?
Thanks a lot in advance,
Frank

4

General Discussion / DHCP Static Mapping creates Alias

« on: June 30, 2022, 12:44:38 pm »

Hi,
every time that I do a static mapping in dhcp, I find myself creating a host alias for that IP immediately afterwards, because I will create one or more firewall rule(s) using this IP.
It might be doable to add a 'create host alias'  checkbox that creates an associated host alias when adding a static mapping.
Just an idea...
Thanks,
Frank

5

General Discussion / nrpe check ipsec certificates

« on: June 20, 2022, 04:47:51 pm »

Hi,
I would like to include an nrpe check to warn me before cerrtificates in /usr/local/etc/ipsec.d/certs expire.
However those files are not readable to the nagios user and a sudoers entry to the liking of

Code: [Select]

CHMODIPSECCERTS = /bin/chmod a+r /usr/local/etc/ipsec.d/certs/*is not working (and not desirable). Any other ideas how I could do this?
Thanks a lot
Frank

6

General Discussion / Mysterious "sendto: Permission denied"

« on: February 16, 2022, 11:49:24 am »

Hi,
I have a weird behaviour somehow related to source NAT an route-based IPsec tunnels:

Networks A and B are behind an OPNsense Box (22.1) and should access to resources through a Tunnel.

Network B should be NATted as Network A for this. The NAT itself works.

• I can see the packets leaving through ipsec<X>
• I can see that the source has been correctly replaced with an address from Network A
• Packets really originating from Network A reach the other side
• when I try to generate traffic on the firewall itself (*), i get sendto: Permission denied
   errors
• when I temporarily pfctl -d packets reach the other side
• when I remove the outgoing NAT rule, packets reach the other side, with the undesired source addess

I can't see anything related in pflog, even if I enable logging in the 'permit' rule.

How do I figure out what causes the 'permission denied'? IDS/IPS is disabled.

Thanks a lot,
Frank

(*) either using ping -S Network-A-Addres, or using nc -vz -s

7

22.1 Legacy Series / [Solved] What can replace clog?

« on: January 31, 2022, 02:31:05 pm »

Hi all,
I wonder what I have at my disposal now that clog is gone? I rely on using clog when debugging things and I use it in nrpe  monitoring scripts as well.
Thanks in advance,
Frank

8

21.7 Legacy Series / [Solved] 21.7.3 OpenVPN connects but doesn't set routes

« on: September 23, 2021, 03:32:08 pm »

Hi,
I upgraded a test system to 21.7.3 and I have found that routes are not set on an openvpn client connection issued on the OPNsense appliance.
I can tcpdump on the ovpnc-n interface and see incmoming traffic.
When I add the required routes (as specified in "IPv4 Remote Network") manually, traffic starts flowing correctly.
I have reverted to 21.7.1, and all is well again, using:

Code: [Select]

opnsense-revert -kr 21.7.1 opnsense
opnsense-update -kr 21.7.1
Thanks and regards,

9

General Discussion / Route based IPSec loses 802.1x packets

« on: July 14, 2021, 05:19:47 pm »

Hi,
I have route-based IPSec tunnels from my branches to the center, and I have trouble with remote switches doing 802.1x with EAP, as  the packets seem to get too large (the switch tries to send 1472 bytes to the radius server) (see attached schema).
I have found that on the central Firewall, the (larger) requests seem to arrive on enc0, but are somewhere lost before they are passed to the ipsec<n> interface. Smaller packets go on fine, and for example mac-based auth on the same switch, against the same radius succeeds. The packets seem to disappear silently as I find no ICMP unreachables anywhere which could help PMTUD to work.

tcpdump on Central FW's enc0

Code: [Select]

14:54:46.500486 (authentic,confidential): SPI 0xc9334317: IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Challenge (11), id: 0x90 length: 1368
14:54:46.500516 (authentic,confidential): SPI 0xc9334317: IP 172.27.5.18 > 10.3.137.200: ip-proto-17
14:54:46.509256 (authentic,confidential): SPI 0xc06ab719: IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x91 length: 414
14:54:46.511684 (authentic,confidential): SPI 0xc9334317: IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Challenge (11), id: 0x91 length: 819
14:54:46.535993 (authentic,confidential): SPI 0xc06ab719: IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x92 length: 1368
14:54:46.536032 (authentic,confidential): SPI 0xc06ab719: IP 10.3.137.200 > 172.27.5.18: ip-proto-17
14:54:46.671825 (authentic,confidential): SPI 0xc06ab719: IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x93 length: 363
14:54:47.673778 (authentic,confidential): SPI 0xc9334317: IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Reject (3), id: 0x93 length: 20


tcpdump on Central FW's ipsec<n> you see that the id 0x92 goes missing

Code: [Select]

14:54:46.497772 IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x90 length: 414
14:54:46.500484 IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Challenge (11), id: 0x90 length: 1368
14:54:46.500515 IP 172.27.5.18 > 10.3.137.200: ip-proto-17
14:54:46.509260 IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x91 length: 414
14:54:46.511681 IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Challenge (11), id: 0x91 length: 819
14:54:46.671829 IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x93 length: 363
14:54:47.673775 IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Reject (3), id: 0x93 length: 20

looking at what goes into the firewall at the switch's side, I see that the original size of 0x90 is 1390 bytes, which get split and correctly reassembles, 0x92 is 1472 bytes, gets split and is then somehow lost at the 'end' of the tunnel.

Any ideas what I could do to get this to work?

Thanks and regards,
Frank

10

General Discussion / [SOLVED] API flush alias

« on: June 30, 2021, 11:57:48 am »

Hi,
I can successfully use API calls to list the content and flush an alias,
but after a few seconds, the contents gets restored 'magically'.

After a flush, the /conf/config.xml doesn't reflect that the alias should be empty, whereas a 'list' API call returns
{"total":0,"rowCount":-1,"current":1,"rows":[]}

Am I doing this wrong?

Thanks in advance,
Frank

11

General Discussion / Outgoing NAT fails occasionally (for UDP 500?)

« on: May 19, 2021, 11:50:52 am »

Hi,
I have observed NAT not happening on a single connection several times today.
I have "Hybrid outbound NAT rule generation" enabled but I notice that sometimes I have packets from a host that leaves the WAN interface with its private IP as source address

Code: [Select]

11:16:55.750589 IP 10.6.2.176.500 > 1.2.2.4.500: isakmp: parent_sa ikev2_init[I]
11:16:56.753706 IP 10.6.2.176.500 > 1.2.3.4.500: isakmp: parent_sa ikev2_init[I]
11:16:57.756176 IP 10.6.2.176.500 > 1.2.3.4.500: isakmp: parent_sa ikev2_init[I]
At the same time, this client accesses 'the rest' of the Internet just fine, so NAT is happening there.
When I go to the "States Dump" and kill this single state, all is fine and the client can connect.
I suspected maybe a full table, but that doesn't seem to be the case:

Code: [Select]

root@opnsense-master:~ # pfctl -si
Status: Enabled for 8 days 22:06:38           Debug: Urgent

State Table                          Total             Rate
  current entries                    34377               
  searches                     37178953282        48234.4/s
  inserts                         73241737           95.0/s
  removals                        73207352           95.0/s
Counters
  match                           79776073          103.5/s
  bad-offset                             0            0.0/s
  fragment                            7501            0.0/s
  short                                  2            0.0/s
  normalize                            460            0.0/s
  memory                                 0            0.0/s
  bad-timestamp                          0            0.0/s
  congestion                             0            0.0/s
  ip-option                        1503550            2.0/s
  proto-cksum                            0            0.0/s
  state-mismatch                      6256            0.0/s
  state-insert                          11            0.0/s
  state-limit                            0            0.0/s
  src-limit                              0            0.0/s
  synproxy                               0            0.0/s
  map-failed                             0            0.0/s
root@bo-claurive-master:~ # pfctl -sm
states        hard limit   797000
src-nodes     hard limit   797000
frags         hard limit     5000
table-entries hard limit  1000000
root@opnsense-master:~ #


This is a ha-cluster on OPNsense 21.1.5. At the moment I have only seen this happen for IKE pakets.

Thanks for any hints,

Frank

12

General Discussion / Concurrent api calls

« on: April 27, 2021, 10:24:31 am »

Hi,

I have seen just now for the first time the situation where an API call is done to add an IP to an Alias
(https://$fw/api/firewall/alias_util/$action/$fwtable) and the call replies "status":"done"
but the address is not really added to the Alias.
The address is added to a 13 different Aliases in a loop, and each call reported  "status":"done" but in reality the address had only been added to 10 Aliases.
This series of calls is repeated on two nodes of my ha-cluster, and on the slave it worked as expected.

Can it be a problem if concurrent api calls are made? My users log on to a portal page and the portal makes these api calls to give them access to their resources, so this can happen 'simultaneously'.

Any hints?

Thanks a lot in advance,

Frank

13

21.1 Legacy Series / Static route destination sanity check

« on: April 19, 2021, 08:21:53 am »

Hi,
I have just found out that OPNsense let's me enter nonsensical destinations in the static routes dialogue.
It let me put

10.204.71.0/16

in the destination field (even overriding my larger 10.204.0.0/16 route)
Maybe a check could prevent dummies like me from sabotaging their network ;-)

Thanks

14

21.1 Legacy Series / Upgrade to 21.1.2 from 21.1.1 breaks IPSec

« on: February 26, 2021, 11:38:11 am »

Hi,
the last upgrade breaks IPSec for us. (update + reboot from 21.1.1 to 21.1.2)

This is all I see in the log. Only few udp:500 packets are transmitted.

Code: [Select]

Feb 26 10:18:43 TC-master charon[8392]: 12[KNL] creating acquire job for policy a.b.c.d/32 === x.y.z.t/32 with reqid {109}
Feb 26 10:18:43 TC-master charon[8392]: 05[IKE] <con7|73951> initiating IKE_SA con7[73951] to x.y.z.t
Feb 26 10:18:43 TC-master charon[8392]: 05[NET] <con7|73951> sending packet: from a.b.c.d[500] to x.y.z.t[500] (464 bytes)
Feb 26 10:18:43 TC-master charon[8392]: 05[NET] <con7|73951> received packet: from x.y.z.t[500] to a.b.c.d[500] (36 bytes)
Feb 26 10:19:07 TC-master charon[8392]: 06[KNL] creating acquire job for policy a.b.c.d/32 === x.y.z.t/32 with reqid {109}
Feb 26 10:19:07 TC-master charon[8392]: 11[IKE] <con7|73952> initiating IKE_SA con7[73952] to x.y.z.t
Feb 26 10:19:07 TC-master charon[8392]: 11[NET] <con7|73952> sending packet: from a.b.c.d[500] to x.y.z.t[500] (464 bytes)
Feb 26 10:19:07 TC-master charon[8392]: 11[NET] <con7|73952> received packet: from x.y.z.t[500] to a.b.c.d[500] (36 bytes)
Feb 26 10:19:31 TC-master charon[8392]: 05[KNL] creating acquire job for policy a.b.c.d/32 === x.y.z.t/32 with reqid {109}
Feb 26 10:19:31 TC-master charon[8392]: 14[IKE] <con7|73955> initiating IKE_SA con7[73955] to x.y.z.t


I did
opnsense-revert -r 21.1.1 strongswan
opnsense-update -kr 21.1
and a reboot. That didn't help.
Then, I did
opnsense-revert -r 21.1.1 strongswan
again, and now the connection comes up again.

15

Web Proxy Filtering and Caching / traffic is not passed to haproxy

« on: February 22, 2021, 08:57:12 am »

Hi all,

I have a situation where incoming traffic doesn't seem to be passed to the haproxy process.

• the backends are fine, I see that haproxy contacts them regularly, and they are 'UP'
• when I try to contact publicip:port from outside the OPNsense box, I see the request coming in, and I can see it 'pass', looking at pflog. Nothing shows in haproxy.log
• sockstat shows haproxy is listening at publicip:port
• when I do 'curl publicip:port' on the OPNsense box itself, everything works, and the request shows in the haproxy.log
• to keep things simple, I have used 88 as the public port, so that it nothing interferes with OPNsense's GUI
• I have a rule that accepts traffic to publicip:port on the interface where the request comes in
• publicip is a CARP virtual IP

Any hints on what could be wrong hete?

Thanks a lot in advance,