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

#1
22.1 Legacy Series / Determine reboot reason
April 26, 2022, 02:39:26 PM
Hi

On my APU2 I get a reboot of opnsense about every week, however I haven't found the reason yet. Is there a log file in which the reason could be mentioned?
In /var/log/system I don't see what caused the reboot.

I'm running 22.1.6, APU BIOS v4.14.0.6.

Best,
Marcel
#2
I somehow suspect that your described config adds multiple VLAN tags or just replaces them with 4095.

In general I would recommend to do the VLAN tagging on the vSwitch and use separate vNICs to the VM, see Virtual Switch Tagging (VST) [1]. It has the benefit that you explicitly assign a VLAN to a VM and you don't have to configure anything VLAN related in the VM itself.

Did you configure a trunk port (multiple VLANs on one port) between ESXi and OpenWRT? Do you have any switches in between?

Please also add a diagram of your network (at least physical).

[1] https://kb.vmware.com/s/article/1003806#vstPoints
#3
After testing with the new settings (static DUID and prevent release) bringing re2 (DMZ) up still removes the IPv6 from re1_vlan34 (LAN).
#4
I now have configured a static DUID and set the checkbox for prevent release. The DUID hopefully gives me the same prefix when requesting one as long as the lease still exists. The prevent release should ignore the interface shutdown.

Unfortunately I can't test it until the ISP dhcp offers me new prefixes (there seems to be a hard-limit of prefixes given out)
#5
Hi

I saw a weird issue with opnsense 19.1.8 and IPv6. I have three interfaces (WAN, DMZ, LAN). I request a prefix with DHCPv6 on WAN. On LAN and DMZ I use track interface to configure the dynamic IPv6.

When I plug-in a device at the DMZ interface it gets an IPv6 address with a new prefix. This also changes the currently existing IPv6 address on LAN. This breaks all devices behind that interface as they now have IPv6 addresses based on multiple prefixes configured and opnsense doesn't invalidate the old prefixes.

Config of WAN:
- IPv6 Configuration Type: DHCPv6
- DHCPv6 client configuration
- Configuration Mode: Basic
- Request only an IPv6 prefix: No
- Prefix delegation size: /48
- Send IPv6 prefix hint: Yes
- Directly send SOLICIT: Yes
- Prevent release: No
- Enable debug: Yes
- Use IPv4 connectivity: No

Config of LAN (re1_vlan34) / DMZ (re2)
- IPv6 Configuration Type: Track Interface
- Track IPv6 Interface
- IPv6 Interface: WAN
- IPv6 Prefix ID: 0x34 (LAN), 0x35 (DMZ)
- Manual configuration: No

I'm not sure about the prevent release option. I tried turning that on but after setting it and a reboot I haven't received any prefix at all. (Maybe I have reached the maximum allowed prefixes from the provider).

Is that expected behavior?
Where can I find the dhcp-pd debug logs? -> clog /var/log/system.log | grep dhcp6


clog /var/log/system.log | grep -E 're2|re1_vlan34|dhcp6c'
May 18 13:04:14 opnsense kernel: re2: link state changed to DOWN
May 18 13:04:14 opnsense dhcp6c[52690]: restarting
May 18 13:04:15 opnsense dhcp6c[52690]: Sending Solicit
May 18 13:04:16 opnsense dhcp6c[52690]: Sending Request
May 18 13:04:16 opnsense dhcp6c[52690]: Received REPLY for REQUEST
May 18 13:04:16 opnsense dhcp6c[52690]: add an address 2001:DB8:d65c:35:xxxx:xxxx:xxxx:xx6/64 on re2
May 18 13:04:16 opnsense dhcp6c[52690]: add an address 2001:DB8:d65c:34:xxxx:xxxx:xxxx:xx5/64 on re1_vlan34
May 18 13:04:16 opnsense dhcp6c[52690]: add an address 2001:DB8:xxxx:xx::30/128 on re0
May 18 13:04:16 opnsense dhcp6c: dhcp6c REQUEST on re0
May 18 13:04:16 opnsense dhcp6c: dhcp6c REQUEST on re0 - running newipv6
May 18 13:15:27 opnsense kernel: re2: link state changed to UP
May 18 13:15:28 opnsense dhcp6c[52690]: restarting
May 18 13:15:28 opnsense dhcp6c[52690]: Start address release
May 18 13:15:28 opnsense dhcp6c[52690]: Sending Release
May 18 13:15:28 opnsense dhcp6c[52690]: remove an address 2001:DB8:xxxx:xx::30/128 on re0
May 18 13:15:28 opnsense dhcp6c[52690]: Start address release
May 18 13:15:28 opnsense dhcp6c[52690]: Sending Release
May 18 13:15:28 opnsense dhcp6c[52690]: failed to remove an address on re2: Can't assign requested address
May 18 13:15:28 opnsense dhcp6c[52690]: remove an address 2001:DB8:d65c:34:xxxx:xxxx:xxxx:xx5/64 on re1_vlan34
May 18 13:15:28 opnsense dhcp6c[52690]: Received REPLY for RELEASE
May 18 13:15:28 opnsense dhcp6c[52690]: status code: success
May 18 13:15:28 opnsense dhcp6c: dhcp6c RELEASE on re0
May 18 13:15:28 opnsense dhcp6c: dhcp6c RELEASE on re0 - running newipv6
May 18 13:15:29 opnsense opnsense: /usr/local/etc/rc.newwanipv6: Warning! services_radvd_configure(auto) found no suitable IPv6 address on re2
May 18 13:15:29 opnsense opnsense: /usr/local/etc/rc.newwanipv6: Warning! services_radvd_configure(auto) found no suitable IPv6 address on re1_vlan34
May 18 13:15:29 opnsense kernel: re2: link state changed to DOWN
May 18 13:15:30 opnsense opnsense: /usr/local/etc/rc.linkup: Warning! services_radvd_configure(auto) found no suitable IPv6 address on re2
May 18 13:15:30 opnsense opnsense: /usr/local/etc/rc.linkup: Warning! services_radvd_configure(auto) found no suitable IPv6 address on re1_vlan34
May 18 13:15:34 opnsense dhcp6c[52690]: restarting
May 18 13:15:34 opnsense dhcp6c[52690]: Sending Release
May 18 13:15:34 opnsense dhcp6c[52690]: Received REPLY for RELEASE
May 18 13:15:34 opnsense dhcp6c[52690]: status code: success
May 18 13:15:34 opnsense dhcp6c: dhcp6c RELEASE on re0
May 18 13:15:34 opnsense dhcp6c: dhcp6c RELEASE on re0 - running newipv6
May 18 13:15:35 opnsense opnsense: /usr/local/etc/rc.newwanipv6: Warning! services_radvd_configure(auto) found no suitable IPv6 address on re2
May 18 13:15:35 opnsense opnsense: /usr/local/etc/rc.newwanipv6: Warning! services_radvd_configure(auto) found no suitable IPv6 address on re1_vlan34
May 18 13:15:40 opnsense dhcp6c[52690]: Sending Solicit
May 18 13:15:40 opnsense dhcp6c[52690]: XID mismatch
May 18 13:15:41 opnsense dhcp6c[52690]: Sending Request
May 18 13:15:41 opnsense dhcp6c[52690]: Received REPLY for REQUEST
May 18 13:15:41 opnsense dhcp6c[52690]: add an address 2001:DB8:d65d:35:xxxx:xxxx:xxxx:xx6/64 on re2
May 18 13:15:41 opnsense dhcp6c[52690]: add an address 2001:DB8:d65d:34:xxxx:xxxx:xxxx:xx5/64 on re1_vlan34
May 18 13:15:41 opnsense dhcp6c[52690]: add an address 2001:DB8:xxxx:xx::31/128 on re0
May 18 13:15:41 opnsense dhcp6c: dhcp6c REQUEST on re0
May 18 13:15:41 opnsense dhcp6c: dhcp6c REQUEST on re0 - running newipv6



[EDIT]
Added dhcp6c and link status logs and interface names.
#6
Good to know. Thanks for your help.
#7
Thanks for the hint. With that flag enabled it grabs the IPv6 after boot without the workaround. However with this setting enabled unbound doesn't start anymore. Is this a bug?

opnsense: /status_services.php: The command '/usr/local/sbin/unbound -c '/var/unbound/unbound.conf'' returned exit code '1', the output was '[1518296527] unbound[21470:0] error: can't bind socket: Can't assign requested address for 2001:db8::xxxx [1518296527] unbound[21470:0] fatal error: could not open ports'

I configured unbound to only listen on specific interfaces (it doesn't need to listen for dns requests on the wan interface). If I set Network Interfaces in unbound to all the service starts again.

#8
Directly send SOLICIT is turned off.
#9
No, I only see the IPv4 address.
#10
I run opnsense 18.1.2_2-amd64 with serial console.
#11
Hi

I have an IPv6 connection with DHCPv6-PD from my ISP. IPv6 on WAN is configured with DHCPv6, Prefix delegation size and prefix hint enabled.
LAN is configured with Track Interface WAN and a prefix id.

With that configured, my LAN clients don't receive any prefix information in the router advertisements. After I run
/var/etc/rtsold_intX_vlanY_script.sh
manually, the clients receive prefix information and IPv6 works.

As a workaround I added the line into a shellscript in /usr/local/etc/rc.syshook.d

I run 18.1.2_2-amd64 on a APU. The issue already was in 15.7: https://forum.opnsense.org/index.php?topic=1950.msg6072#msg6072.

Is there something I can change so I don't need the workaround?
#12
Hi

With 16.1.17 the null route fix works. In the meantime I also tried to use the track-interface IPv6 configuration. This works but rtsold still has to be called manually.

Regards
Marcel
#13
Hi Franco

Quote from: franco on May 15, 2016, 11:48:02 PM
Null routes will be fixed in 16.1.14-devel and 16.1.15 release respectively.
I tested it today with 16.1.15, but it doesn't add the null route.

Regards,
Marcel
#14
Quote from: franco on May 21, 2016, 09:11:11 PM
Hi Marcel,

I found this regarding NO_STATE:SINGLE...

https://lists.freebsd.org/pipermail/freebsd-pf/2006-June/002260.html

It doesn't seem to be related to IP options. The firewall lets the outgoing traffic through the gif0 interface, but doesn't allow the replies back in. I also tried it now with this setting, but it doesn't change the behavior.

Is there some kind of antispoofing or uRPF check?

Regarding NPT, I think I first need to be able to send and receive traffic with an assigned interface and policy routing before I add NPT as an additional complexity.
#15
At least now I get RAs every 3 minutes. I could remove the helper script and to check on next boot if it sends RAs before the dhcpv6 request.