Messages

Installing the legacy firewall plug-in, performing the migration I missed on NAT, and uninstalling the legacy plugin worked.

So maybe :
1. Export the NAT Rules you have now.

I can't export to a CSV because the old rules section isn't there anymore in 26.10.  That's why I was wondering if it is as simple as installing the old rule plugin and then proceeding.

I can easily recreate the rules fresh, but given that they somehow exist, I'm not certain what would happen if I tried that.

I'm on 26.10.  I had upgraded from old to new rules a few months ago in prepartion.

I recently realized that the two Source NAT rules I should have in place are not listed.  However, the rule still works.

Doing a pfctl -s nat lists those two rules.  They survive a reboot.  My assumption is I didn't properly migrate them. 

I'm looking for advice on how to fix this.  My assumption is install the os-firewall-legacy plugin, complete the migration, and remove the plugin.

Just an update, after upgrading to 26.10, making the settings that Monviech suggested, and adding a router advertisement for the interfaces using prefix delegations besides 0, it works.

I can use the full /56 in my broken Comcast/Xfinity Business ipv6 delegation.

No static prefixes listed in business ndp-proxy-go plugin and when I tried your suggestion on the commandline, it complained that --static-prefix was not defined.

Thanks, though.

Thanks. I can wait a few weeks and test the supported version. If not, I'll snapshot and try compiling.

In either case, I'll report back in this thread.

Thanks.  Saying Comcast does with things odd with ipv6 is an understatement.  About a year ago, they released firmware that completely broke prefix delegation.

The RA from the modem just advertises the first /64 in the /56, so your explanation makes sense.

I'll try building from the repo just to test.  It looks like you added that feature in 1.04 and the OPNsense plug-in is 1.3_1.  I'm assuming it's as simple as uninstalling the plug-in and then compiling/installing from your repo?  Anything else I need to be aware of?  I've done lots of compiling/installing on various linux systems.  I've avoided doing it on OPNsense.

Any idea how long until the full plug-in will be updated?  And will updating the plug-in atop a custom build require anything special?

Thanks for the quick response!

Is there a firewall setting that may need tweaking to get ndp-proxy NA's to go through?  They aren't making it to the upstream interface, and I think that will solve my issue.

I'm certain I'm doing something wrong. I'm also certain this is as much a Comcast/XFinity issue as it is an OPNsense one.

I'm using OPNsense 26.4.2p3.  I have a Comcast Business class with static IPs.  I have a /29 for ipv4 and a /56 for ipv6.  Comcast will only permit me to request prefix delegations no larger than /59.  Packet captures show if I request multiple /59 PD's, Comcast says I have them.

However, only ipv6 /64's in the firstly requested /59 fully route.

For those that fail, remote packet captures show the packets making it to my Comcast modem and failing.

Packet captures on my OPNsense box's WAN interface, show Comcast sending a neighbor solicitation packet and not getting a reply.  NOTE: for anything in the first PD requested, Comcast does not send NS requests.  It just sends the packets to OPNsense.

After frequent attempts to set this up and knocking parts of my family's internet out, I am just trying on one isolated test system.

I tried setting up os-ndp-proxy-go to have Comcast as the upstream interface and the downstream interface as the one connected to my test system as the downstream.

In that setup, via packet captures on OPNsense, I see Comcast send an NS to my WAN.  I see OPNsense send an NS to my test system.  I see my test VM send a Neighbor Advertisement.  I do not see an NA go out my WAN interface. 

NDP Proxy debug logs say that it is forwarding the NA to the upstream. 

Custom WAN dhcpv6.conf:

Code Select Expand

interface igb0 {
  send ia-na 0;
  send ia-pd 0;
  send ia-pd 1;
  send ia-pd 2;
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh";
};
id-assoc na 0 {
};
id-assoc pd 0 {
  prefix 2603:XXXX:XXXX:XX60::/59 infinity;
  prefix-interface igb2 {
    sla-id 26;
    sla-len 5;
    ifid 1;
  };
  prefix-interface igb1 {
    sla-id 0;
    sla-len 5;
  };
  prefix-interface igb3 {
    sla-id 30;
    sla-len 5;
  };
};
id-assoc pd 1 {
  prefix 2603:XXXX:XXXX:XXe0::/59 infinity;
  prefix-interface ix2 {
    sla-id 1;
    sla-len 5;
  };
};
id-assoc pd 2 {
  prefix 2603:XXXX:XXXX:XX20::/59 infinity;
};
NDP Proxy settings:

You cannot view this attachment.

NDP Proxy log saying it is forwarding the NA:

You cannot view this attachment.

This is not causing any issues.  I just find it interesting.  SNMP monitoring is reporting MAC address changes on remote devices.  ARP on opnsense box does NOT show the same.

I've got an observium instance on a proxmox VM that pulls data from a number of systems, including opnsense.  The opnsense box has multiple physical interfaces.  I'm certain this is an snmp bug, whether on the opnsense side or possibly the observium side.

So, let's say a MAC address is aa:bb:cc:dd:ee:ff.  SNMP from opnsense is reporting 3 different MAC addresses over the course of weeks:

• aa:bb:cc:dd:ee:ff
• 00:bb:cc:dd:ee:ff
• aa:00:00:00:00:00

Not all changing MAC's show all three patterns.  Not all devices show changing MACs. I do see changing MACs on all five NICs.

Currently, my observium instance reports my ISP router MAC as changing from the first form to the last on the list five hours ago.  An arp (both via GUI and commandline) reports the correct MAC.

Again, this is not a big deal.  I'm not even looking for a fix.  I am curious if anyone has seen anything similar?

I was ultimately able to get Comcast to roll back my firmware and prefix delegation is working again. It took about a week, but I also opened the case the Wednesday before Thanksgiving.

Comcast is aware of the issue. They will eventually roll out updated firmware, but it sounds like that will take time. If you are affected by this, you'll want to get a ticket opened and request a firmware rollback.

I lost my IPv6 prefix delegation about a week ago. Seriously dug into it yesterday and have packet captures of the modem telling me no prefix delegation.

For anyone else using anything besides the base /64 of your IPv6 statics, don't waste much time on this. There's a forum thread on the Comcast support that makes it clear this is an issue with the latest firmware. It even includes someone who got their modem swapped out. The swapped out modem came with older firmware. Prefix delegation worked again. A few days later, the new modem switched to the latest firmware and prefix delegation broke.

https://forums.businesshelp.comcast.com/conversations/ipv6/prefix-delegation-disabled/690fa973a2c50219bf21c6e6

It's pretty clear that firmware CGA4332COM_8.2p5s1_PROD_sey breaks prefix delegation for Comcast customers.

S-NAT has no impact on routing at all.

If you want to route certain traffic to the non-default gateway you need to add a Policy based routing rule.

Thanks!  I'd figured that out just before you posted. I hadn't found the documentation on it.

I am an idiot.

I needed a firewall rule for WiFi right before the default deny that routes all traffic through the Surf gateway.

I'm certain I'm an idiot and I'm missing something obvious.

I've have multiple LAN networks.  Until recently my WAN was solely a Comcast Business with static IPs, meaning I have an ipv4 /29 and an ipv6 /59.  I now have a Surf internet fiber connection.  Ultimately, I'd like to have some LANs (WiFi, IOT, wired family computers) use the new fiber connection but have my two server LANs (internal servers and DMZ servers) use the Comcast one.

I have always had Manual Outbound NAT rules working for all networks, along with a few outbound port and inbound port rules.  I don't remember if the need to set explicit Outbound NAT was due to the tutorial I followed for Comcast Business or if it was a desire to block the round robin IP usage.  In any case, it has been working.

I've been trying to just get the WiFi working, and am failing.  Details below, but in a nutshell, WiFi is 192.168.253.0/24 and when setting up a NAT using my new fiber, packet captures show an un-NAT'd 192.168.253.x IP going out my Comcast WAN, which is the default route. 

If I leave the existing Comcast Outbound NAT in place, everything works.  Packet captures show traffic leaving my Comcast WAN interface using the public IP set in that outbound NAT rule.

If I disable the Comcast Outbound NAT and set up a Surf Fiber Outbound NAT, traffic doesn't work.  Packet captures show the un-NAT'd 192.168.253.0/24 IP of devices on WiFi going out the Comcast WAN interface.  Since those are not routable packets, Comcast drops them.

Clearly SNAT isn't working when I'm trying to use Surf fiber.  I can't figure out what I'm doing wrong.

Gateway settings in GUI:

You cannot view this attachment.

I can ping both the Comcast and Surf upstream gateways.

This screenshot of the Outbound NAT rule for Surf fiber shows the rule disabled, but if I disable the Comcast Outbound rule for WiFi and enable this one, then the WiFi traffic is not SNAT'd and routes out the Comcast default route.

You cannot view this attachment.

So, while there are likely other things I'll need to tweak, it looks to me like the SNATing is not happening.  I'm certain I'm missing something obvious.

I agree with dseven.  Run a packet capture on the WAN. Assuming you see them, then alter your one to one NAT rule to log. Also create a rule on the LAN side to permit logging of packets to the Debian 12 box.

You do mention that even with the one to one in place, you are getting the wrong IP for outbound packets, so it's possible the packets are making it all the way to the Debian box, but the replies to the TCP handshake come from the .105 ip instead of .106. A packet capture on the Debian 12 box could be informative too.

I too have a /29. I've only done port forwards, not 1 to 1, so I can't help with settings there.

I will say you should do more to narrow down in what point in the process are things breaking. With that info, others that have worked with 1 to 1 NATs may have some insight.

Is it possible something on the Debian firewall is permitting LAN but not non-LAN?