Messages

1

22.1 Legacy Series / OpenVPN uses wrong source IP for firewall originated packages on VPN

« on: June 12, 2022, 08:30:21 pm »

Dear folks,

We have ran into a small issue with a new 22.1 installation regarding theLAN interface.
We have the following configuration

- The LAN interface is on igb0_vlan2
- LAN has an assigned IP address (say 192.168.1.1)
- Filtering is happening only on LAN interface
- Firewall "Shared forwarding" is enabled
   Disabling makes no difference
- OpenVPN client connection is used
- Static route for OpenVPN is added to Routes
 
The problem is that the OPNsense device itself is unable to send any packages via VPN, including ICMP, because the incorrect source IP is used (0.0.0.0) instead of the LAN or OpenVPN IP.

- Client connections from LAN to OpenVPN work
- Connections from remote OpenVPN network to LAN work
- Connections from remote OpenVPN network to LAN interface IP work
> Connections from local device to OpenVPN connection fail
    Here, the remote VPN gateway sees a source IP of 0.0.0.0 for the package, hence the connection fails
   Specififying the source IP manually works well
      ping -S 192.168.1.1 <destination>
      
      
Now, this seems to be specific to the bridging configuration as we have multiple setups (albeit older OPNSense versions) running well in this setup, but they don't have a bridged LAN interface.


What settings are we missing to make this work? Maybe interface metric somewhere?
This is required for scheduled backups for us for example.

Any pointer are greatly appreciated.

I've updated the post as a having a non-bridged interface makes no difference

I have only noticed that the VPN route has the "G" flag set and a gateway instead of link on the 18.1 version and it doesn't on 22.1:

192.168.0.0/16     link#11            US       ovpnc1

192.168.0.0/16     192.168.x.x UGS      ovpnc1

Any pointers would really help, thanks!
   

2

General Discussion / Re: Blocking Europe from attempted rdt logins

« on: December 16, 2020, 04:03:04 pm »

Your place to start would be Aliases.

Specifically, look for the section on how to configure GeoIP alisases.

3

General Discussion / Re: how to set up MTU properly; fragmented UDP packets getting truncated

« on: December 16, 2020, 01:51:33 pm »

Digging this up.

Having run into this exact same problem (UDP SIP; options too large) passing through a transparent filtering bridge, have you ever found a solution to this issue?

4

19.1 Legacy Series / Kernel Panic on boot after clean reboot

« on: June 19, 2019, 12:54:05 pm »

Dear folks,

we have an embedded device running 19.1 i386 nano version.
An admin rebooted the device via WebGUI and it never came back online.

Connecting via serial console, the output shows a failure to load netgraph.ko due to an undefined symbol.

Now we fixed this through reflashing and restoring, but this is very disconcerting to just write off as strange occurence.

We have excluded:
- CF card; it checks out OK
- Unclean shutdown; it was rebooted via webgui and fstab mounted with noatime,sync


We'd appreciate any input as to what might cause this so as to prevent this in the future..

Here's the output:

/boot/kernel/kernel text=0x1409269 data=0xee088+0x28e534 syms=[0x4+0xf6f50+0x4+0x18b906]
/boot/entropy size=0x1000
/boot/kernel/if_gre.ko text=0x3118 data=0x278+0x30 syms=[0x4+0xa30+0x4+0xab9]
/boot/kernel/if_tap.ko text=0x3734 data=0x2dc+0x34 syms=[0x4+0xa70+0x4+0x9f6]
/boot/kernel/pf.ko text=0x35ca8 data=0x4e8+0x1128 syms=[0x4+0x2490+0x4+0x2a0c]
/boot/kernel/carp.ko text=0x8150 data=0x374+0x74 syms=[0x4+0xe90+0x4+0xf1c]
/boot/kernel/if_bridge.ko text=0x7c40 data=0x350+0x3c syms=[0x4+0xff0+0x4+0x11f2]
loading required module 'bridgestp'
/boot/kernel/bridgestp.ko text=0x4994 data=0xe0+0x18 syms=[0x4+0x6d0+0x4+0x66b]
/boot/kernel/if_lagg.ko text=0xa024 data=0x294+0x28 syms=[0x4+0xf20+0x4+0x108a]
/boot/kernel/ng_UI.ko text=0x908 data=0x128 syms=[0x4+0x3a0+0x4+0x352]
loading required module 'netgraph'
/boot/kernel/netgraph.ko text=0xb348 data=0x474+0x8c syms=[0x4+0x14c0+0x4+0x1984]
/boot/kernel/ng_async.ko text=0x1b10 data=0x158 syms=[0x4+0x5b0+0x4+0x5e4]
/boot/kernel/ng_bpf.ko text=0x2370 data=0x158 syms=[0x4+0x5f0+0x4+0x66d]
/boot/kernel/ng_bridge.ko text=0x2604 data=0x158+0x20 syms=[0x4+0x6b0+0x4+0x780]
/boot/kernel/ng_cisco.ko text=0x1814 data=0x128 syms=[0x4+0x540+0x4+0x508]
/boot/kernel/ng_echo.ko text=0x4ec data=0x128 syms=[0x4+0x2f0+0x4+0x2f7]
/boot/kernel/ng_eiface.ko text=0x19f0 data=0x148+0x4 syms=[0x4+0x6e0+0x4+0x707]
/boot/kernel/ng_ether.ko text=0x2398 data=0x14c+0x4 syms=[0x4+0x760+0x4+0x7c9]
/boot/kernel/ng_frame_relay.ko text=0xe90 data=0x128 syms=[0x4+0x3e0+0x4+0x3be]
/boot/kernel/ng_hole.ko text=0x934 data=0x128 syms=[0x4+0x3c0+0x4+0x3b4]
/boot/kernel/ng_iface.ko text=0x1e04 data=0x178+0x4 syms=[0x4+0x6f0+0x4+0x746]
/boot/kernel/ng_ksocket.ko text=0x3208 data=0x158 syms=[0x4+0x850+0x4+0x94f]
/boot/kernel/ng_l2tp.ko text=0x3e64 data=0x158 syms=[0x4+0x720+0x4+0x7ce]
/boot/kernel/ng_l2tp.ko text=0x3e64 data=0x158 syms=[0x4+0x720+0x4+0x7ce]
can't load file '/boot/kernel/ng_l2tp.ko': input/output error
/boot/kernel/ng_lmi.ko text=0x24e0 data=0x128 syms=[0x4+0x4b0+0x4+0x43a]
/boot/kernel/ng_mppc.ko text=0x3ab0 data=0x25c+0x4 syms=[0x4+0x760+0x4+0x89d]
loading required module 'rc4'
/boot/kernel/rc4.ko text=0x3d0 data=0xe0 syms=[0x4+0x250+0x4+0x224]
/boot/kernel/ng_one2many.ko text=0x1420 data=0x128 syms=[0x4+0x500+0x4+0x592]
/boot/kernel/ng_ppp.ko text=0x601c data=0x158 syms=[0x4+0x8c0+0x4+0x974]
/boot/kernel/ng_pppoe.ko text=0x534c data=0x15c syms=[0x4+0x740+0x4+0x790]
/boot/kernel/ng_pptpgre.ko text=0x3068 data=0x128 syms=[0x4+0x5c0+0x4+0x5f8]
/boot/kernel/ng_rfc1490.ko text=0x12e8 data=0x128 syms=[0x4+0x440+0x4+0x41e]
/boot/kernel/ng_socket.ko text=0x2830 data=0x4a8+0x18 syms=[0x4+0x9e0+0x4+0xb4b]
/boot/kernel/ng_tee.ko text=0xe7c data=0x128 syms=[0x4+0x440+0x4+0x42b]
/boot/kernel/ng_tty.ko text=0x1724 data=0x148 syms=[0x4+0x570+0x4+0x4d4]
/boot/kernel/ng_vjc.ko text=0x2430 data=0x128 syms=[0x4+0x5c0+0x4+0x5d6]
/boot/kernel/ng_vlan.ko text=0x16d0 data=0x128 syms=[0x4+0x4f0+0x4+0x50e]
/boot/kernel/if_enc.ko text=0x1118 data=0x2b8+0x8 syms=[0x4+0x690+0x4+0x813]
/boot/kernel/pflog.ko text=0x10f0 data=0x11c+0x44 syms=[0x4+0x540+0x4+0x55b]
/boot/kernel/pfsync.ko text=0x7e5c data=0x228+0x160 syms=[0x4+0xd40+0x4+0xd84]
/boot/kernel/ng_car.ko text=0x1c94 data=0x1a0 syms=[0x4+0x540+0x4+0x543]
/boot/kernel/ng_deflate.ko text=0x1b34 data=0x174 syms=[0x4+0x600+0x4+0x6c0]
/boot/kernel/ng_pipe.ko text=0x2b0c data=0x158+0x1c syms=[0x4+0x6b0+0x4+0x6c1]
/boot/kernel/ng_pred1.ko text=0x1ac4 data=0x158 syms=[0x4+0x530+0x4+0x594]
/boot/kernel/ng_tcpmss.ko text=0xe74 data=0x128 syms=[0x4+0x420+0x4+0x465]
Booting...
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.1-RELEASE-p6  6621d681e(stable/18.1) i386
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
VT(vga): resolution 640x480
[HBSD HARDENING] procfs hardening: enabled
[HBSD ASLR] status: opt-out
[HBSD ASLR] mmap: 14 bit
[HBSD ASLR] exec base: 14 bit
[HBSD ASLR] stack: 14 bit
[HBSD ASLR] vdso: 8 bit
[HBSD LOG] logging to system: enabled
[HBSD LOG] logging to user: disabled
[HBSD SEGVGUARD] status: opt-out
[HBSD SEGVGUARD] expiry: 120 sec
[HBSD SEGVGUARD] suspension: 600 sec
[HBSD SEGVGUARD] maxcrashes: 5
link_elf: symbol ▒▒▒▒▒▒▒▒▒▒▒▒U▒▒SWV▒▒]▒▒x▒E▒M▒PQS▒u
▒
 undefined
KLD file netgraph.ko - could not finalize loading
KLD file ng_UI.ko - cannot find dependency "netgraph"
KLD file ng_async.ko - cannot find dependency "netgraph"
KLD file ng_bpf.ko - cannot find dependency "netgraph"
KLD file ng_bridge.ko - cannot find dependency "netgraph"
KLD file ng_cisco.ko - cannot find dependency "netgraph"
KLD file ng_echo.ko - cannot find dependency "netgraph"
KLD file ng_eiface.ko - cannot find dependency "netgraph"
KLD file ng_ether.ko - cannot find dependency "netgraph"
KLD file ng_frame_relay.ko - cannot find dependency "netgraph"
KLD file ng_hole.ko - cannot find dependency "netgraph"
KLD file ng_iface.ko - cannot find dependency "netgraph"
KLD file ng_ksocket.ko - cannot find dependency "netgraph"
KLD file ng_lmi.ko - cannot find dependency "netgraph"
KLD file ng_mppc.ko - cannot find dependency "netgraph"
KLD file ng_one2many.ko - cannot find dependency "netgraph"
KLD file ng_ppp.ko - cannot find dependency "netgraph"
KLD file ng_pppoe.ko - cannot find dependency "netgraph"
KLD file ng_pptpgre.ko - cannot find dependency "netgraph"
KLD file ng_rfc1490.ko - cannot find dependency "netgraph"
KLD file ng_socket.ko - cannot find dependency "netgraph"
KLD file ng_tee.ko - cannot find dependency "netgraph"
KLD file ng_tty.ko - cannot find dependency "netgraph"
KLD file ng_vjc.ko - cannot find dependency "netgraph"
KLD file ng_vlan.ko - cannot find dependency "netgraph"
KLD file ng_car.ko - cannot find dependency "netgraph"
KLD file ng_deflate.ko - cannot find dependency "netgraph"
KLD file ng_pipe.ko - cannot find dependency "netgraph"
KLD file ng_pred1.ko - cannot find dependency "netgraph"
KLD file ng_tcpmss.ko - cannot find dependency "netgraph"
CPU: Geode(TM) Integrated Processor by AMD PCS (498.06-MHz 586-class CPU)
  Origin="AuthenticAMD"  Id=0x5a2  Family=0x5  Model=0xa  Stepping=2
  Features=0x88a93d<FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX>
  AMD Features=0xc0400000<MMX+,3DNow!+,3DNow!>
real memory  = 268435456 (256 MB)
avail memory = 230801408 (220 MB)
pnpbios: Bad PnP BIOS data checksum
random: unblocking device.
Timecounter "TSC" frequency 498061502 Hz quality 800
taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
taskqgroup_adjust failed cnt: 1 stride: 1 mp_ncpus: 1 smp_started: 0
random: entropy device external interface
wlan: mac acl policy registered
kbd0 at kbdmux0
panic: vm_fault: fault on nofault entry, addr: d18a8000
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c2022a7c,56be1d6c,c1ad48f8,c1630899,c2022a44,...) at db_trace_self_wrapper+0x2a/frame 0xc20229a0
kdb_backtrace(0,0,0,d18a8000,d18a8000,...) at kdb_backtrace+0x2e/frame 0xc2022a00
vpanic(c1630899,c2022a44,c2022a44,c2022af8,c0f90355,...) at vpanic+0x10e/frame 0xc2022a24
panic(c1630899,d18a8000,c189c370,7af4800,1,...) at panic+0x14/frame 0xc2022a38
vm_fault_hold(c23e1000,d18a8000,1,0,0) at vm_fault_hold+0x1f55/frame 0xc2022af8
vm_fault(c23e1000,d18a8000,1,0) at vm_fault+0x69/frame 0xc2022b20
trap_pfault(d18a883c) at trap_pfault+0xcc/frame 0xc2022b64
trap(c2022c68) at trap+0x2b3/frame 0xc2022c5c
calltrap() at calltrap+0x6/frame 0xc2022c5c
--- trap 0xc, eip = 0xc0cff500, esp = 0xc2022ca8, ebp = 0xc2022cb4 ---
kobj_class_compile(c18360ac) at kobj_class_compile+0xc0/frame 0xc2022cb4
devclass_add_driver(c3de0b80,c18360ac,7fffffff,c1911b7c,c0cc9179,c1911b28,c1911b10) at devclass_add_driver+0x30/frame 0xc2022ccc
driver_module_handler(c3dab1c0,0,c1836094) at driver_module_handler+0x62/frame 0xc2022cfc
module_register_init(c1836088) at module_register_init+0xa0/frame 0xc2022d1c
mi_startup() at mi_startup+0x78/frame 0xc2022d38
begin() at begin+0x22
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x35: movl    $0,kdb_why
db>

5

19.1 Legacy Series / Re: MultiWAN failback state flushing / VoiP failover

« on: June 05, 2019, 07:48:01 am »

Hi mimugmail,

I filed here: https://github.com/opnsense/core/issues/3516

Thanks!

6

19.1 Legacy Series / Re: MultiWAN failback state flushing / VoiP failover

« on: June 04, 2019, 07:54:14 pm »

Mhh we've tried playing with changing filter.inc, but that seems like a bad idea in general.
Has no one ran into this with Voip?

7

19.1 Legacy Series / Re: MultiWAN failback state flushing / VoiP failover

« on: May 25, 2019, 08:16:15 am »

I had found this link describing the exact issue we're facing: https://forum.netgate.com/topic/58885/sip-trunk-failover-back-on-multi-wan-issues/3

Is there an afterfilterchangeshellcmd equivalent in OPNSense, and under what circumstances will this be executed?

8

19.1 Legacy Series / MultiWAN failback state flushing / VoiP failover

« on: May 24, 2019, 12:54:38 pm »

Dear folks,

we are trying to setup an outgoing failover (Tier1/2) gateway group for a registered VoiP line.
So far this works well.

However, when the registration occurs via tier 2, and tier 1 comes back online, the registration stays on tier 2.

This results in the RTP data going out over tier 1 and hence being in a split state, ruining the system.

So I am wondering
1. Is there any way to kill states on tier 2 once tier 1 returns online?
2. Is there a better way to solve this?

Thank you in advance!

EDIT: Something like a "Disable State Killing on Gateway Reconnect" option, or the ability to run a custom script when a gateway comes online?

9

19.1 Legacy Series / Re: [RESOLVED] OPNSense behind cable modem fails DHCP renewal

« on: March 10, 2019, 08:15:41 am »

We found it much easier to add cron jobs to a custom file at
/usr/local/etc/cron.d/

Doesn't show in the GUI of course but we use this for backup scripts and such.

10

19.1 Legacy Series / Re: [RESOLVED] OPNSense behind cable modem fails DHCP renewal

« on: March 07, 2019, 11:54:35 am »

It's hard to argue with that 

11

19.1 Legacy Series / Re: OPNSense behind cable modem fails DHCP renewal

« on: March 07, 2019, 11:39:45 am »

Thanks for the attachment; this looks like something I can use!

Loks like you try to ifdown/ipup first before trying rebooting. Good idea!

Yes, of course it's the modem. I hate the ones with integrated garbage, too. A plain modem would be nice :}
Just saying that with the predominance of these devices nowadays there are a number of people who would benefit from an integrated solution in OPNSense along the lines of dumbing it down to "

• Infinitely try to reconnect if modem does annoying things".

12

19.1 Legacy Series / Re: OPNSense behind cable modem fails DHCP renewal

« on: March 07, 2019, 08:14:18 am »

Strange that there is no "supported" resolution.

Is an ifup/ifdown enough in that case to trigger repair?
We have monitoring scripts in use, so we could adjust something.

Any possibility of sharing the template?

13

19.1 Legacy Series / [RESOLVED] OPNSense behind cable modem fails DHCP renewal

« on: March 06, 2019, 07:43:21 pm »

I see this has been discussed almost ad nauseam many times, but I could not find a satisfactory solution.

We have a few remotes sites behind OPNSense with cable modems in front of them. If there is a cable outage, OPNSense fails to renew the IP address and becomes unreachable.
Currently, our solution is to call/write the ISP and ask for a remote modem reset. This will cycle the link and nudge OPNSense back online. However, this is not a very satisfying solution.

We have tried the following:

• Corn job as

Code: [Select]

/sbin/dhclient vr1

[/li]

• System->Settings->Cron => Periodic interface reset
     Will this actually do anything if there is an IP?? It seems as if this does nothing

We have also read about gateway monitoring; but this seems moot if no IP is available.
Problem is also that these are remote sites, so we'd like to have a solution that is known to work before we become frisky configuring away at far away sites :}

Is there any better way to fix this?
Thanks in advance...

Code: [Select]

Mar  6 05:19:18 OPNSense_host kernel: igb1: link state changed to DOWN
Mar  6 05:19:22 OPNSense_host kernel: igb1: link state changed to UP
Mar  6 05:20:17 OPNSense_host configd_ctl.py: error in configd communication  Traceback (most recent call last):   File "/usr/local/opnsense/service/configd_ctl.py", line 65, in exec_config_cmd     line = sock.recv(65536) timeout: timed out
Mar  6 05:20:17 OPNSense_host configd.py: [29714829-b357-40fc-8649-acb929050936] Linkup stopping igb1
Mar  6 05:20:17 OPNSense_host opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Mar  6 05:20:17 OPNSense_host opnsense: /usr/local/etc/rc.linkup: The command '/sbin/dhclient -c /var/etc/dhclient_wan.conf igb1 > /tmp/igb1_output 2> /tmp/igb1_error_output' returned exit code '15', the output was ''
Mar  6 05:20:18 OPNSense_host configd.py: [96e26ea3-ff70-4063-a08b-d7aceb4779a9] Linkup starting igb1
Mar  6 05:20:18 OPNSense_host opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for wan
Mar  6 05:20:18 OPNSense_host opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface wan
Mar  6 05:20:38 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb1'
Mar  6 05:20:38 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: On (IP address: 68.200.7.180) (interface: WAN[wan]) (real interface: igb1).
Mar  6 05:20:40 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 68.xxx.xxx.1
Mar  6 05:20:40 OPNSense_host configd.py: [9d6d6ae0-15f1-4bc9-a402-64450a0fea5b] updating dyndns WAN_DHCP
Mar  6 05:20:41 OPNSense_host configd.py: [4c62eb24-69f1-4776-9631-bca3e9cbcab8] Restarting OpenVPN tunnels/interfaces WAN_DHCP
Mar  6 05:20:41 OPNSense_host opnsense: /usr/local/etc/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP.
Mar  6 05:20:41 OPNSense_host configd.py: [9717900f-6043-443b-9cb6-69abc20d10c8] Reloading filter
Mar  6 05:20:42 OPNSense_host configd.py: [9390544f-594d-404d-acf3-54548762a8bd] updating dyndns wan
Mar  6 05:20:42 OPNSense_host configd.py: unable to sendback response [OK ] for [interface][linkup][['start', 'igb1']] {eee6e08b-dfe0-4e72-8249-cdfc3e42dd2e}, message was Traceback (most recent call last):   File "/usr/local/opnsense/service/modules/processhandler.py", line 202, in run     self.connection.sendall('%s\n' % result)   File "/usr/local/lib/python2.7/socket.py", line 228, in meth     return getattr(self._sock,name)(*args) error: [Errno 32] Broken pipe
Mar  6 05:20:43 OPNSense_host configd.py: [25b8c1a1-f6ba-4959-a8ca-ef1aae506d05] generate template OPNsense/Filter
Mar  6 05:20:45 OPNSense_host configd.py: generate template container OPNsense/Filter
Mar  6 05:20:45 OPNSense_host configd.py: [09d48ade-ff54-443b-8326-36f47374ad0d] refresh url table aliases
Mar  6 05:20:46 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN.
Mar  6 05:20:47 OPNSense_host configd.py: [200458c6-8665-4443-a624-6ede43036172] generate template OPNsense/Filter
Mar  6 05:20:49 OPNSense_host configd.py: generate template container OPNsense/Filter
Mar  6 05:20:50 OPNSense_host configd.py: [7b1166eb-c283-40ec-914a-13a58fe45da7] refresh url table aliases
Mar  6 05:20:50 OPNSense_host opnsense: /usr/local/etc/rc.linkup: ROUTING: setting IPv4 default route to 68.xxx.xxx.1
Mar  6 05:20:56 OPNSense_host configd.py: [379827d4-6f69-4c3a-80af-d4468d94eca6] updating dyndns wan
Mar  6 05:20:56 OPNSense_host configd.py: [cf83f0e6-efb9-4afa-a90a-7a14a2599016] Linkup stopping igb1
Mar  6 05:20:57 OPNSense_host opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Mar  6 05:20:57 OPNSense_host opnsense: /usr/local/etc/rc.linkup: Clearing states to old gateway 68.xxx.xxx.1.
Mar  6 05:20:57 OPNSense_host configd.py: [9102f59c-4d37-4f80-a4a5-8ec6bc48401e] Linkup starting igb1
Mar  6 05:20:57 OPNSense_host opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for wan
Mar  6 05:20:57 OPNSense_host opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface wan
Mar  6 05:20:58 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb1'
Mar  6 05:20:58 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: On (IP address: 68.200.7.180) (interface: WAN[wan]) (real interface: igb1).
Mar  6 05:21:00 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 68.xxx.xxx.1
Mar  6 05:21:00 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN.
Mar  6 05:21:01 OPNSense_host configd.py: [4c6b0b2f-24a2-4df8-8363-c1d212c46552] generate template OPNsense/Filter
Mar  6 05:21:03 OPNSense_host configd.py: generate template container OPNsense/Filter
Mar  6 05:21:04 OPNSense_host configd.py: [13e0811e-1138-41ba-ad1a-003e217e568c] refresh url table aliases
Mar  6 05:21:04 OPNSense_host opnsense: /usr/local/etc/rc.linkup: ROUTING: setting IPv4 default route to 68.xxx.xxx.1
Mar  6 05:21:04 OPNSense_host kernel: igb1: link state changed to DOWN
Mar  6 05:21:13 OPNSense_host kernel: igb1: link state changed to UP
Mar  6 05:21:13 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb1'
Mar  6 05:21:14 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: On (IP address: 68.200.7.180) (interface: WAN[wan]) (real interface: igb1).
Mar  6 05:21:15 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 68.xxx.xxx.1
Mar  6 05:21:15 OPNSense_host configd.py: [d7b02eb3-ae54-43ae-acb9-5796be605e19] updating dyndns WAN_DHCP
Mar  6 05:21:15 OPNSense_host configd.py: [f11a16c5-ef55-4c2c-b3c9-a51ca87b4f13] updating dyndns wan
Mar  6 05:21:16 OPNSense_host configd.py: [174a3144-61ff-41f2-8569-37bf793f7bec] Restarting OpenVPN tunnels/interfaces WAN_DHCP
Mar  6 05:21:16 OPNSense_host opnsense: /usr/local/etc/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP.
Mar  6 05:21:16 OPNSense_host configd.py: [3963ef40-3dc3-4d1a-9a0c-7af23c86764b] Reloading filter
Mar  6 05:21:16 OPNSense_host configd.py: [a4d0c284-3ae3-4dc6-aafd-fb6f4e0e99ee] Linkup stopping igb1
Mar  6 05:21:17 OPNSense_host opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Mar  6 05:21:17 OPNSense_host opnsense: /usr/local/etc/rc.linkup: Clearing states to old gateway 68.xxx.xxx.1.
Mar  6 05:21:17 OPNSense_host configd.py: [1862f0c0-7438-4181-8d4c-20c779d11096] Linkup starting igb1
Mar  6 05:21:18 OPNSense_host opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for wan
Mar  6 05:21:18 OPNSense_host opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface wan
Mar  6 05:21:18 OPNSense_host opnsense: /usr/local/etc/rc.linkup: The command '/sbin/dhclient -c /var/etc/dhclient_wan.conf igb1 > /tmp/igb1_output 2> /tmp/igb1_error_output' returned exit code '1', the output was ''
Mar  6 05:21:18 OPNSense_host opnsense: /usr/local/etc/rc.filter_configure: New alert found: There were error(s) loading the rules: /tmp/rules.debug:40: no translation address with matching address family found. - The line in question reads [40]: nat on igb1 inet from 192.168.0.0/16 to any -> igb1 port 1024:65535
Mar  6 05:21:18 OPNSense_host configd.py: [08c18255-1933-49d9-a1b3-00a4f47b8d31] updating dyndns WAN_DHCP
Mar  6 05:21:19 OPNSense_host configd.py: [c7d391b1-9398-478b-8729-b003c37ec261] Restarting OpenVPN tunnels/interfaces WAN_DHCP
Mar  6 05:21:19 OPNSense_host opnsense: /usr/local/etc/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP.
Mar  6 05:21:19 OPNSense_host configd.py: [8740017c-a677-49dc-823f-2017f3557e7d] Reloading filter
Mar  6 05:21:21 OPNSense_host configd.py: [70aedf01-8786-4d41-b047-eb7d1762a864] generate template OPNsense/Filter
Mar  6 05:21:23 OPNSense_host configd.py: generate template container OPNsense/Filter
Mar  6 05:21:24 OPNSense_host configd.py: [d662204e-29cf-49b4-b969-f2edaa62f3ff] updating dyndns wan
Mar  6 05:21:24 OPNSense_host configd.py: [4d1fd158-5a4e-4b45-b16a-5c38cddf0c56] refresh url table aliases
Mar  6 05:21:24 OPNSense_host opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN.
Mar  6 05:21:26 OPNSense_host configd.py: [a94f1b68-f244-4dae-8586-a6f6fe61db02] generate template OPNsense/Filter
Mar  6 05:21:28 OPNSense_host configd.py: generate template container OPNsense/Filter
Mar  6 05:21:28 OPNSense_host configd.py: [2a58af7b-f4a0-4040-b859-019fdd55e47f] refresh url table aliases

14

19.1 Legacy Series / Re: Kernel panic after upgrade

« on: February 12, 2019, 08:16:35 am »

@Aloist

Maybe if it is such an ultra critical device for you you should invest in a CARP cluster; possibly with the Dell as slave for the new device for example.

Even in case of updates; if the primary gets messed up the secondary can take over until the first gets fixed.

For 99% of workloads it would be best to maybe virtualize the device for quick BMR backup. For failed updates, snapshot restore is an extra bonus.

Virtualization would also make a test environment for major changes and updates feasible, especially with spare server laying around as you said.

15

18.7 Legacy Series / Re: Backup API Method

« on: September 18, 2018, 08:25:18 am »

We are using the following to push config.xml + some other stuff via FTPS.

You can modify the upload logic to push elsewhere instead, like via ssh or git or something.

EDIT: When we migrated to opnsense, we changed from pull to push because we felt while more inconvenient it was best the firewalls initiate the backup rather than allowing external access that would be able to pull config.xml and such.