Topics

1

General Discussion / SLAAC: which OPNsense settings are relevant?

« on: January 30, 2024, 10:40:31 am »

Hi, I have been struggling for two weeks now to get IPv6 to work. The initial problem was with my provider, and now I seemingly have everything working, but most apps on my android devices appear to fall back to IPv4 after 30s of trying.

The test at https://ipv6-test.com/ results in a score of 18 or 19/20, even on my android 14 phone, but the 'SLAAC' option always results in a (green) 'NO'. My devices do report having a fe80:...ff:fe... address, which I believe is formatted like a SLAAC address.

I have a very simple network, with 1 single subnet and no VLANs. My ISP assigns me a fixed /56 block, so I have set:
* WAN IPv6 to DHVPv6
* LAN IPv6 to 'Track interface: WAN'
* Assigned a fixed Virtual IP to my LAN interface aaaa:bbbb:cccc:dddd::1/128 -> now changed to /64 (thx to Maurice)

These are the options I have tried, without success:

* "Automatic mode":
      * simply disable the "Manually adjust router advertisements in the Track Interface section" - IIRC, Maurice posted on this forum that OPNsense then automatically advertises SLAAC.
      * disable radvd and DHCPv6 on the LAN interface
* "Unmanaged mode":
      * enable "Manually adjust router advertisements in the Track Interface section"
      * enable radvd daemon and configure it as Unmanaged
      * disable radvd and DHCPv6 on the LAN interface
* "Assisted mode" / "SLAAC mode":
      * enable "Manually adjust router advertisements in the Track Interface section"
      * enable radvd daemon and configure it as Assisted
      * enable the DHCPv6 server on my LAN interface (tried with and without setting a dhcp range)

In the radvd service section, I have tried with and without setting a prefix - if I did, I made sure that it was a /64 prefix.
I have used radvdump on my laptop to test the RA's I receive, both on my network and a similar network in my neighbourhood (only difference being OPNsense versus Unifi Router), and have been able to align the RA's perfectly.
I have tried running a radvd daemon on a RaspberryPi, making sure that that one did not advertise itself as the router/gateway on the network.

My questions:
1. I always restarted the services after changing settings - but I did not always restart OPNsense entirely - should I?
2. Where else can I look or what else can I try (in OPNsense, I think) for relevant settings?

2

General Discussion / [SOLVED] IPv6: provider issues address outside of fixed /56 block

« on: January 19, 2024, 06:14:38 pm »

Hi,
Short and maybe stupid question, but my service provider is ignoring my requests to solve my issue (and I am not entirely sure that my configuration is not the culprit).

A few months ago, I requested a fixed IPv6 address and shared the DUID of my OpnSense appliance. The provider confirmed that all was set up correctly on their end. However, the IPv6 address that my OpnSense appliance receives through DHCPv6 is outside of the block that is supposed to be reserved for me, and it does not match the IPv6 prefix that OpnSense tells me it has received:

OpnSense interfaces overview:
IPv6 link-local   fe80::20d:b9ff:fe45:cc08/64
IPv6 address   2a02:xxxf:0:80e1:b032:6391:eea0:89df/128
IPv6 prefix   2a02:xxx2:1c0c:4800::/56
IPv6 gateway   auto-detected: fe80::217:10ff:fe87:b386

-> 1. The address is outside of the prefix
-> 2. The address actually has changed already at least once, so whatever they have issued to me, it is not a fixed IPv6
-> 3. The prefix is not the same as the one I was told I would receive (2a02:xxy7:1020:900::/56)

I have already released/renewed the IPv6 and IPv4 addresses, and have also rebooted twice. I have asked my provider to double check the modem ID in their systems (/my account), and they always confirm everything is set up correctly.

I can make outbound things work (as confirmed by an ipv6test website) by adding a virtual IP address inside the prefix and manually setting up a route, but inbound, computers on my LAN are not reachable from outside with that setup.

My configuration is pretty standard, I believe:
1. the WAN interface is configured to use DHCPv6, with 'send prefix hint' set and 'prefix delegation size' set to 56
2. the LAN interface is set to track the WAN interface, and I have tried both with the option to manually adjust RA and without.

Is there anything I could be doing wrong, or can I firmly demand a solution from my provider?

3

17.1 Legacy Series / Newbie install and configuration experience

« on: May 15, 2017, 05:11:30 pm »

Dear all,

First of all, thank you for the OPNsense software - I have it more or less up and running by now, but as I have had some issues, I'd like to document them here. Maybe in my ignorance I have stumbled across a bug or two, and who knows maybe this leads to the bugs being squashed.

Secondly: The reason why I ordered a new PC Engines APU2C4 board and chose OPNsense is that I thought my Linksys EA3500 router had started dying on me: I received complaints of frequent drops in connections (http and sip), but today I must admit now that it seems that these drops have been caused by internal DHCP-issues: one of my devices used a fixed IP that was conflicting with a statically attributed address. Now this has been resolved, I don't see the connection drops anymore, so I hope I can mark the issue solved .

My setup: MODEM - ROUTER (only NAT) - SG200 SWITCH - internal network, including a Debian Jessie server with IPTABLES, FAIL2BAN, DHCPD and BIND9.

In this setup, changing routers should be very straightforward, but it proved not that straightforward:
1. Installation was painless (once I had the correct null modem cable) with the 'serial'-image on a USB stick and installation to an mSATA disk
2. Configuration of the Intel ethernet ports was easy: igb0=WAN=DHCPv4 + igb1=LAN=fixed IPv4
3. In the webgui, I spoofed the former Linksys MAC Address to receive my fixed IPv4 address on WAN
4. Again in the webgui, I setup port forwarding for ~15 destinations, carefully leaving the 'bind to firewall rule'-option unchanged
5. I setup disk cache as per the instructions

Still thinking I had solved the issue with the dropped packets, I was very satisfied: the old router configuration (NAT only) was manually copied to the new device, and everything was accessible. At that moment, I witnessed only:
* a constantly high CPU load (30%+, although a max of 5 low-traffic clients were active on the LAN)
* a hanging JS-script when opening the "Interfaces > LAN" -page
* the NTPD service failed quite often

24 hours later, the connection drops reared their ugly head again, and I moved the old router back into place, which seemed to solve the issue in the short term. Yesterday I found the issue, but I had made a few changes to the router:
1. I moved all DHCPD-rules to the OPNsense router and disabled the DHCPD on the Debian Jessie server
2. I reset the SG200-switch as well as some other switches
3. I unplugged a lot of cables from the switch
4. I removed the igb0-interface and moved WAN to igb2, to move it back 30 minutes later
5. I stopped spoofing the MAC address of the old router
6. I tried to login into all the managed switches and resolved the dual use of one IP address for two devices
7. I stopped the Intrusion Detection and WebProxy services
8. I rebooted the modem and the router

Then suddenly,
* the CPU load dropped to 1%-3%
* the packet loss was gone
* the NTPD service was constantly up
* the LAN-page did not have the issue with the hanging JS-script any longer

Today I learnt that, although the port forwarding rules were still 'there', the corresponding firewall rules were 'gone' - in the firewall logs all attempts to forward traffic to the local server were 'blocked by the default deny rule'. To change this, it did not suffice to change the port forward rule to set the corresponding firewall rule to 'pass' - nor did it help to add an explicit firewall rule to allow the specific traffic on a certain port. Only after removing all specific firewall rules AND port forwarding rules, I could re-add port forwarding rules with the expected consequence that such traffic would be allowed to pass through the firewall.

Firewalling and routing network traffic are not entirely new to me, but my knowledge/experience is quite high level. Still, if I may cautiously conclude:
1. the above would not have happened if I did not have any collisions on the internal network, but I think OPNsense 'sensed' these issues while it was not able (or willing to tell me what was wrong (or at least something was wrong - it even reported '0 collisions' and '0 packets lost'). If at all possible, this would be a great feature...
2. maybe I have messed up the NAT/Firewall rules myself by deleting the igb0/WAN interface, but given the consequences if the situation is restored (all rules have to be deleted and reconfigured anyway), wouldn't it be a useful action to automatically delete all NAT+FW rules that had been added to the network interface upon deletion of the network interface assignment?

Thank you for reading this long post - I hope my experiences with this distro can help making it even more newbie-proof

Kr,
Vincent