"Recent posts
#1
25.7, 25.10 Series / Re: 25.7.8 upgrade
Last post by franco - Today at 05:55:45 PMCan you do a connectivity audit from the firmware status page?
> truncated: 0/1332 bytes
This could happen due to long DNS timeouts for example.
Cheers,
Franco
> truncated: 0/1332 bytes
This could happen due to long DNS timeouts for example.
Cheers,
Franco
#2
25.7, 25.10 Series / OPNsense 25.7.8 HA - Persisten...
Last post by martymarty004 - Today at 05:55:23 PMHello, I'm new to OPNsense and networking in general, and I'm facing some issues with the IPv6 configuration of my setup.
PPPoE is working, but I'm getting "Destination unreachable: Source address failed ingress/egress policy" when trying IPv6.
I'm, attaching three files with the status of WAN, LAN and what a client receives as parameters, so you can check if anything is amiss.
Do you have any suggestions?
PING [PREFIX]:0::1 OK
PING fe80::1%enp42s0 OK
PING google.com KO > From _gateway (fe80::1%enp42s0) icmp_seq=1 Destination unreachable: Source address failed ingress/egress policy
Physical network>
Two identical Proxmox nodes (v9.1.1) with two NICs, one NIC in a Tagged 835VLAN, the other is Untagged LAN.
Each NIC has a virtual bridge on top, connected to the OPNsense VM (v25.7.8) and other containers. Bridges are VLAN aware, virtual NICs are VIRTIO (queues enabled, Firewall OFF).
Everything is attached to a TL-SG3424, stock config except for ports 1-4 being assigned to VLAN 835 (TRUNK).
My ISP provides me with a public dynamic IPv4 (which never actually changes) as well as a static /48 IPv6 prefix.
OPNsense Environment>
- WAN : Block private, Block bogon
IPv4 : PPPoE
IPv6 : DHCPv6, Prefix delegation /48, request only prefix, send hint
- LAN
IPv4 : 10.79.0.2/24 (static) - (10.79.0.2/24)
IPv6 : [PREFIX]:0::2/64 (static) - ([PREFIX]:0::3/64)
- WAN_PARENT : assigned to vtnet1 just for CARP logic
CARP>
VHID 1 - LAN - 10.79.0.1/24
VHID 2 - LAN - fe80::1/64
VHID 3 - LAN - [PREFIX]:0::1/64
VHID 4 - OPT1 - 10.254.254.1/32 (brings down PPPoE when BACKUP)
One VM is MASTER, the other BACKUP, I can see the spoofed MACs from the switch's ARP table, so they should be fine
KEA DHCPv6>
Subnet : [PREFIX]:0::/64
Range : [PREFIX]:0::1000 - [PREFIX]:0::ffff
DNS : [Pi-Hole1], [Pi-Hole2]
HA : Enabled
Router Advertisements>
Mode : Assisted
Priority : High
Source Address : fe80::1/64
Advertise Routes : [PREFIX]:0::/64
Advertise Default Gateway, Do not send any DNS configuration to clients
Dnsmasq, ISCDHCP, Unbound DNS> OFF
System : High Availability> Active and synchronized
For internet connectivity on BACKUP router>
- Firewall: NAT: Outbound : Hybrid
Rule : WAN - Src: LAN - Dst: * - NAT: Interface addr
- Gateways
Fallback_GW : Interface: LAN - IP: 10.79.0.1 (lower priority, FAR gateway)
PPPoE is working, but I'm getting "Destination unreachable: Source address failed ingress/egress policy" when trying IPv6.
I'm, attaching three files with the status of WAN, LAN and what a client receives as parameters, so you can check if anything is amiss.
Do you have any suggestions?
PING [PREFIX]:0::1 OK
PING fe80::1%enp42s0 OK
PING google.com KO > From _gateway (fe80::1%enp42s0) icmp_seq=1 Destination unreachable: Source address failed ingress/egress policy
Physical network>
Two identical Proxmox nodes (v9.1.1) with two NICs, one NIC in a Tagged 835VLAN, the other is Untagged LAN.
Each NIC has a virtual bridge on top, connected to the OPNsense VM (v25.7.8) and other containers. Bridges are VLAN aware, virtual NICs are VIRTIO (queues enabled, Firewall OFF).
Everything is attached to a TL-SG3424, stock config except for ports 1-4 being assigned to VLAN 835 (TRUNK).
My ISP provides me with a public dynamic IPv4 (which never actually changes) as well as a static /48 IPv6 prefix.
OPNsense Environment>
- WAN : Block private, Block bogon
IPv4 : PPPoE
IPv6 : DHCPv6, Prefix delegation /48, request only prefix, send hint
- LAN
IPv4 : 10.79.0.2/24 (static) - (10.79.0.2/24)
IPv6 : [PREFIX]:0::2/64 (static) - ([PREFIX]:0::3/64)
- WAN_PARENT : assigned to vtnet1 just for CARP logic
CARP>
VHID 1 - LAN - 10.79.0.1/24
VHID 2 - LAN - fe80::1/64
VHID 3 - LAN - [PREFIX]:0::1/64
VHID 4 - OPT1 - 10.254.254.1/32 (brings down PPPoE when BACKUP)
One VM is MASTER, the other BACKUP, I can see the spoofed MACs from the switch's ARP table, so they should be fine
KEA DHCPv6>
Subnet : [PREFIX]:0::/64
Range : [PREFIX]:0::1000 - [PREFIX]:0::ffff
DNS : [Pi-Hole1], [Pi-Hole2]
HA : Enabled
Router Advertisements>
Mode : Assisted
Priority : High
Source Address : fe80::1/64
Advertise Routes : [PREFIX]:0::/64
Advertise Default Gateway, Do not send any DNS configuration to clients
Dnsmasq, ISCDHCP, Unbound DNS> OFF
System : High Availability> Active and synchronized
For internet connectivity on BACKUP router>
- Firewall: NAT: Outbound : Hybrid
Rule : WAN - Src: LAN - Dst: * - NAT: Interface addr
- Gateways
Fallback_GW : Interface: LAN - IP: 10.79.0.1 (lower priority, FAR gateway)
#3
General Discussion / Re: Missing Interfaces
Last post by Unregistered Member - Today at 05:42:24 PMThanks for the suggestion @pfry. I updated the NVM and the problem still persists - I still get netmap_transmit ixl0 full from time to time.
As for missing interfaces, I'll update to 25.7.8 and see if it fixes it.
As for missing interfaces, I'll update to 25.7.8 and see if it fixes it.
#4
25.7, 25.10 Series / Re: 25.7.8 upgrade
Last post by Baron_Backdoor - Today at 05:27:34 PMQuote from: meyergru on Today at 04:46:36 PMThat looks as if 25.7.8 upgrade was done (potentially incomplete) and now you do not have internet access.
From what version did you start out? If it was < 25.7, see https://forum.opnsense.org/index.php?topic=48343.msg244891#msg244891
If that is your situation, you need to apply the fixes, preferably before the upgrade.
I want to say 25.7.5 so i'll lok at those fixes as luckily despit it being upset i still have internet (thank the lord as she is catching up on stranger things and i don't wish to stop that lol)
UPDATE
Yes 25.7.5 as under updates it still say to update despite dashboard saying all good.
#5
25.7, 25.10 Series / Re: 25.7.8 upgrade
Last post by Baron_Backdoor - Today at 05:25:27 PMQuote from: SeeDrs on Today at 04:33:57 PMHave you tried a different Mirror? You can change it under System > Firmware > Setting.
Thank you for the reply, yes 3 or 4 of them
#6
25.7, 25.10 Series / Re: Using Adguard Home and DNS...
Last post by meyergru - Today at 05:00:45 PMQuote from: Patrick M. Hausen on Today at 11:44:07 AMQuad9 are located in Switzerland and seem to be ok:
https://quad9.net/about/foundation-council/
1.1.1.1 also seems O.K. to me (and it is by far the fastest DNS resolver I know of).
#7
25.7, 25.10 Series / Re: Using Adguard Home and DNS...
Last post by JMini - Today at 04:51:07 PMA lot of good info here. Thanks, all.
I'm located in the US and Verizon is my ISP. I'm pretty sure they mine DNS and sell the data. No GDPR here. CloudFlare has a good reputation for privacy. But any unencrypted DNS will be snooped by Verizon.
I don't care about "intelligence". I'm a nobody home user. They're gonna get what they get. I'd rather just not be snooped on by my ISP and have it sold to advertisers.
So, if I let Unbound use the authoritative servers it has compiled in, it's sending those requests in the clear over port 53 that can be seen by anyone along the way. Using DOH/DOT, it's at least hidden until it gets to CloudFlare/OpenDNS. Then I'm relying on their privacy promises. I get that part.
Thanks for the whole explanation of how the stepped approach to DNS resolution works. I thought there were these centralized DNS repositories that just served up the whole thing. Not org, then opnsense.org, then forums.opnsense.org.
Maybe I'll so some reading on the details of DNS. No idea it was that segmented.
I'm located in the US and Verizon is my ISP. I'm pretty sure they mine DNS and sell the data. No GDPR here. CloudFlare has a good reputation for privacy. But any unencrypted DNS will be snooped by Verizon.
I don't care about "intelligence". I'm a nobody home user. They're gonna get what they get. I'd rather just not be snooped on by my ISP and have it sold to advertisers.
So, if I let Unbound use the authoritative servers it has compiled in, it's sending those requests in the clear over port 53 that can be seen by anyone along the way. Using DOH/DOT, it's at least hidden until it gets to CloudFlare/OpenDNS. Then I'm relying on their privacy promises. I get that part.
Thanks for the whole explanation of how the stepped approach to DNS resolution works. I thought there were these centralized DNS repositories that just served up the whole thing. Not org, then opnsense.org, then forums.opnsense.org.
Maybe I'll so some reading on the details of DNS. No idea it was that segmented.
#8
25.7, 25.10 Series / Re: 25.7.8 upgrade
Last post by meyergru - Today at 04:46:36 PMThat looks as if 25.7.8 upgrade was done (potentially incomplete) and now you do not have internet access.
From what version did you start out? If it was < 25.7, see https://forum.opnsense.org/index.php?topic=48343.msg244891#msg244891
If that is your situation, you need to apply the fixes, preferably before the upgrade.
From what version did you start out? If it was < 25.7, see https://forum.opnsense.org/index.php?topic=48343.msg244891#msg244891
If that is your situation, you need to apply the fixes, preferably before the upgrade.
#9
General Discussion / PSA: recent Comcast firmware s...
Last post by really_lost - Today at 04:45:26 PMI 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.
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.
#10
General Discussion / Re: TUI for viewing and analys...
Last post by allddd - Today at 04:44:15 PMI'm glad you liked it :)
This is already on my todo list because, even with larger screens, it's an issue if the terminal is not running in fullscreen mode, which is often the case. I even have a bit of code for this in a local branch, but I haven't really decided what would be the best way to do this.
One approach would be to dynamically truncate the columns based on window size, but that would cause an issue on smaller screens where you could not see part of the date, IP, etc., which isn't ideal.
Another approach, as you mentioned, would be to implement horizontal scrolling. This would be more tricky to implement and might not look as good, but at least it would not cut off parts of IPs or other fields.
Currently, it is not possible to filter based on IP version, but adding this as an option would be easy. Documentation on the filter.log format:
The proto filter is used to filter by protoname. The reason you get any results with a filter query such as proto ip, is because some protocol names contain ip* (e.g. ipv6-icmp) and the value does not have to be an exact match. To implement this, I would either have to abuse the proto keyword or add a new one used specifically for matching the ipversion field. The latter option would probably be less confusing.
If you have a Gitlab account, feel free to open an issue if you notice any bugs or have suggestions.
Quote from: patient0 on Today at 10:24:48 AMmy screen is quite small (1280x800) and not all columns fit on the screen. It would be helpful if I could scroll horizontally with e.g. either the left/right arrow keys and/or 'h'/'l' (like in vim).
This is already on my todo list because, even with larger screens, it's an issue if the terminal is not running in fullscreen mode, which is often the case. I even have a bit of code for this in a local branch, but I haven't really decided what would be the best way to do this.
One approach would be to dynamically truncate the columns based on window size, but that would cause an issue on smaller screens where you could not see part of the date, IP, etc., which isn't ideal.
Another approach, as you mentioned, would be to implement horizontal scrolling. This would be more tricky to implement and might not look as good, but at least it would not cut off parts of IPs or other fields.
Quote from: patient0 on Today at 10:24:48 AMright now filtering for 'proto ip6' doesn't show any results. But filtering for 'proto ip' shows only the ip6 traffic. I would prefer if 'proto ip' would show the ipv4 entries and 'proto ip6' the ipv6. Maybe even a shortcut like in 'pftop' 'ip' and 'ip6' showing the ipv4 and ipv6 entries.
Currently, it is not possible to filter based on IP version, but adding this as an option would be easy. Documentation on the filter.log format:
Code Select
IPv4
====
[Packetfilter], ipversion, tos, ecn, ttl, id, offset, flags, protonum, protoname, length, src, dst
The protonum/protoname order is reversed compared to IPv6.
IPv6
====
[Packetfilter], ipversion, class, flow, hoplimit, protoname, protonum, length, src, dst
The protonum/protoname order is reversed compared to IPv4.
The proto filter is used to filter by protoname. The reason you get any results with a filter query such as proto ip, is because some protocol names contain ip* (e.g. ipv6-icmp) and the value does not have to be an exact match. To implement this, I would either have to abuse the proto keyword or add a new one used specifically for matching the ipversion field. The latter option would probably be less confusing.
If you have a Gitlab account, feel free to open an issue if you notice any bugs or have suggestions.
