OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of xaxero »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

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.

  • Messages
  • Topics
  • Attachments

Messages - xaxero

Pages: [1] 2
1
23.7 Legacy Series / Re: Monit Start Delay not working
« on: November 01, 2023, 03:46:40 pm »
Looking deeper it appears that Monit is detecting a shutdown. The event started just before reboot so the delay is probably working not sure why the behavior is different to all my other firewalls.

2
23.7 Legacy Series / Monit Start Delay not working
« on: November 01, 2023, 03:19:52 pm »
I am having an issue with monit failing to access the Postfix server.

I have tried a start delay from 120 to 1000 and it appears that Monit always tries to access the mail server before the system is fully booted and Postfix is not running.

As soon as I get access to the Gui I see Monit has already tried and failed to send a message:

2023-11-01T14:09:40   Error   monit   Cannot connect to [localhost]:25 -- Connection timed out   
2023-11-01T14:00:02   Error   monit   Cannot open a connection to the mailserver localhost:25 -- Permission denied

When I can access the server is accessible:
root@OADStarlink:~ # telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 oadstarlink ESMTP Postfix
HELO localhost
250 oadstarlink



Monit config follows:

root@OADStarlink:~ # cat /usr/local/etc/monitrc
# DO NOT EDIT THIS FILE -- OPNsense auto-generated file

set httpd unixsocket /var/run/monit.sock
    allow localhost

set daemon 120 with start delay 120

set logfile syslog facility log_daemon



set mailserver localhost,10.10.11.1 port 25   

set alert jon@xaxero.com  { instance,resource }  reminder on 10 cycles

check system $HOST
   if memory usage is greater than 75% then alert
   if cpu usage is greater than 75% then alert
   if loadavg (1min) is greater than 16 then alert
   if loadavg (5min) is greater than 12 then alert

check filesystem RootFs with path "/"
   if space usage is greater than 75% then alert




include /usr/local/etc/monit.opnsense.d/*.conf

3
23.7 Legacy Series / DPinger and Starlink ongoing issues
« on: August 24, 2023, 09:53:57 pm »
Still having issues with Dpinger dropping gateways when Starlink goes offline. Restarting the dpinger service brings it back up.
I have sledgehammered a solution while not ideal works. I am asking for this feature to be added to OPNSense:

I created a file /usr/local/opnsense/service/conf/actions.d/actions_dpinger.conf

And added the following code:



[restart]
command:/usr/local/sbin/pluginctl -s dpinger restart
parameters:
type:script
message:Restarting Dpinger
description:Restart Dpinger service

I was then able to create a Cron Job via the web interface:
*/5     *       *       *       *       (/usr/local/sbin/pluginctl -s dpinger restart

If this could be added to the main build I think it would benefit the OPNSense community.

4
23.1 Legacy Series / Re: Weird problem with DPinger Fixed
« on: August 24, 2023, 09:48:16 pm »
Movistar Uruguay - got it down to 32 bytes

5
23.1 Legacy Series / Weird problem with DPinger Fixed
« on: August 02, 2023, 10:19:50 am »
I am using a 4G modem and everything was working fine except DPinger. Gateway is always shown as down. Doing a TCP Dump I see ping returned when I do a normal ping all works fine.

I tried to use ChatGPT to debug and it suggested among other ideas to do a packet capture. Pings with 64 bytes were working but Dpinger's 8 were not.

Upping the packet count to 64 fixed it. - Must be an issue on the ISP end.

08:02:17.325629 IP 192.168.0.173 > 151.101.195.5: ICMP echo request, id 59929, seq 39, length 8
08:02:18.326719 IP 192.168.0.173 > 151.101.195.5: ICMP echo request, id 59929, seq 40, length 8
08:04:14.840672 IP 192.168.0.173 > 151.101.195.5: ICMP echo request, id 45724, seq 1, length 64
08:04:14.884388 IP 151.101.195.5 > 192.168.0.173: ICMP echo reply, id 45724, seq 1, length 64
08:04:15.842099 IP 192.168.0.173 > 151.101.195.5: ICMP echo request, id 45724, seq 2, length 64
08:04:15.879343 IP 151.101.195.5 > 192.168.0.173: ICMP echo reply, id 45724, seq 2, length 64

6
23.1 Legacy Series / DHCP Client Buffer Overflow with Starlink
« on: June 11, 2023, 12:32:03 pm »
We have a ship at 80 N using Starling that occasionally has drop outs. Normally everything recovers and we go our merry way. However we have seen as we are operating in high terrain at times the router becoming unavailable and needing to be rebooted via a cold restart.

A post mortem shows the logs continually chucking out the following message:

Error   dhclient   send_packet: No buffer space available

It would appear BSD has got itself in a loop in which we cannot get in. Is there a workaround here ?

7
23.1 Legacy Series / Re: Multi WAN Dpinger needs restarting after gateway outage Workaround
« on: May 12, 2023, 06:46:18 am »
Last thought - perhaps we could include httping as an option in the future as well as dpinger. http has much higher priority.

8
23.1 Legacy Series / Re: Multi WAN Dpinger needs restarting after gateway outage Workaround
« on: May 12, 2023, 06:03:27 am »
I am collating the data from this post and others Applies to Starlink only but may be useful elsewhere. Applied the following fixes  from everyone's suggestions and the gateways are stable - We are having frequent outages as we are in laser link territory however the link is stable overall.

1/. Wan Definition Reject leases from 192.168.100.1 (note gateways are on separate router in my case)
2/. Gateway - Disable host route.
3/. Monitor IP that is not 1.1.1.1 (In my case open DNS) and bind each interface to DNS via Settings General.

Interfaces have been going up and down last 24 hours and the gateways (so far) are behaving and the routes are changing dynamically

9
23.1 Legacy Series / Re: Multi WAN Dpinger needs restarting after gateway outage
« on: May 07, 2023, 09:29:10 am »
Good Morning
    Changing to openDNS has resulted in a big improvement. 48 hours with no issues. However SL has been very stable. The second  unit I simply use the SL Gateway address.

Note: As I am using the Dual antenna setup I have put in a second router at the front end simply to NAT the traffic and so I have a unique gateway for each antenna and tagging the packets onto separate VLANS to our main router several decks down. 2 WANS with the same gateway was problematic if we had to do a full system power cycle.
With the front end router I am disabling gateway monitoring and I am doing all the DPinger stuff on the main router. Also Disable host route may have helped as well.

Another slimy hack is to force all passenger traffic through the 4G-Starlink-Primary interface via the firewall so this bypasses dpinger completely. The more critical ship traffic goes through the Gateway failover and the worst case scenario is that we are stuck on the VSAT until I can restart Dpinger.

I have attached the gateway configuration of the front and and the core routers. So far it has been working well.

10
23.1 Legacy Series / Re: Multi WAN Dpinger needs restarting after gateway outage
« on: May 05, 2023, 09:42:04 am »
OK Done as you suggested on the one interface (main) Will see how it goes.    



Name    Interface    Protocol    Priority    Gateway    Monitor IP    RTT    RTTd    Loss    Status    Description    
      StarlinkBackup_GWv4 (active)    StarlinkBackup    IPv4    199    192.168.192.1    100.64.0.1    46.8 ms    11.7 ms    0.0 %    Online
   StarBK    
      StarMain_VLAN_GWv4    4G_VLAN    IPv4    201    192.168.191.1    208.67.222.222    36.3 ms    7.8 ms    0.0 %    Online
   StrMain    
   

11
23.1 Legacy Series / Re: Multi WAN Dpinger needs restarting after gateway outage
« on: May 05, 2023, 07:25:18 am »
Good Morning
  I am trying this 2 ways (I use 2 Starlink Maritime interfaces)

StarlinkBackup_GWv4 (active)    StarlinkBackup    IPv4    199    192.168.192.1    100.64.0.1    40.0 ms    9.0 ms    0.0 %    Online
   
      Starmain_VLAN_GWv4    4G_VLAN    IPv4    201    192.168.191.1    1.1.1.1    0.0 ms    0.0 ms    100.0 %    Offline
   StrMain    
      
I use the remote gateway IP for one 100.64.0.1 and this works better than 1.1.1.1 that is down every morning.

12
23.1 Legacy Series / Multi WAN Dpinger needs restarting after gateway outage Workaround
« on: May 04, 2023, 08:30:39 am »
I have an issue that seems to be ongoing and I cannot see a fix in the forums. If this has been resolved apologies.

Using starlink where the WAN frequently drops out DPinger needs to be restarted in order for the gateway monitoring to work again and the routes services restarted to get the default route back.

Has anyone found a fix for this yet? I have disabled sticky connections in the firewall settings.

13
23.1 Legacy Series / Unable to use Serial console
« on: April 19, 2023, 08:16:02 am »
I have purchased an Deciso appliance with OPNSense pre installed. I have managed to get the serial console working where I can see the boot sequence but I do not have serial console access.
System -> Administration settings are:
Console    
Console driver    Use the virtual terminal driver (vt)
Primary Console    Serial Console
Secondary Console  Serial Console   
Serial Speed     115200
USB-based serial    Use USB-based serial ports
Console menu    Password protect the console menu

Am I missing something ?


14
General Discussion / Re: VLAN and or DHCP Failing on single vlans after several days
« on: December 14, 2022, 12:42:13 pm »
I have to add that rebooting the router immediately fixes the problem

15
General Discussion / VLAN and or DHCP Failing on single vlans after several days
« on: December 14, 2022, 12:34:34 pm »
I am experiencing a problem on several installations where the DHCP server stops sending out DHCP addresses and if we manually address we still cannot ping the router. It is as if the Interface has suddenly started blocking all traffic on that VLAN.

We started experiencing this after upgrading ZenArmor mid November. I am not sure it is definitely a ZenArmor issue or something else. Nothing in the logs to indicate any issues.

Pages: [1] 2
OPNsense is an OSS project © Deciso B.V. 2015 - 2024 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2