"Recent posts
#1
General Discussion / Re: Native NAT64 support
Last post by Jackknife4782 - Today at 01:32:33 PMIf I WiFi call out, I can't receive any calls back unless I wait a few minutes. Had a couple people call me and their calls failed if it was still within a few minutes of my WiFi call out. After a few minutes I can receive WiFi calls again.
#2
26.1 Series / Re: WiFi interface broken afte...
Last post by binaryx - Today at 01:29:35 PMPatched yesterday opensense with as bundle so with router restart, when the interface is configured with mode it will fail as mode is non-empty:
in the log you can see
/usr/local/etc/rc.linkup: The command </sbin/ifconfig wlan create wlandev 'ath0' 'wlanmode hostap' bssid name 'ath0_wlan1'> returned exit code 1 and the output was "ifconfig: SIOCIFCREATE2 (wlan): Input/output error"
the issue is that escapeshellarg() convert "wlanmode hostap" into "'wlanmode hostap'" which isn't valid param as there must not be any ''
correct cmd:
/sbin/ifconfig wlan create wlandev 'ath0' wlanmode hostap bssid name 'ath0_wlan1'
what we get from escape ..
/sbin/ifconfig wlan create wlandev 'ath0' 'wlanmode hostap' bssid name 'ath0_wlan1'
this also makes the new fix/commit not requried, but no overwiew on whole code so just statement base on the troubleshooting
in the log you can see
/usr/local/etc/rc.linkup: The command </sbin/ifconfig wlan create wlandev 'ath0' 'wlanmode hostap' bssid name 'ath0_wlan1'> returned exit code 1 and the output was "ifconfig: SIOCIFCREATE2 (wlan): Input/output error"
the issue is that escapeshellarg() convert "wlanmode hostap" into "'wlanmode hostap'" which isn't valid param as there must not be any ''
correct cmd:
/sbin/ifconfig wlan create wlandev 'ath0' wlanmode hostap bssid name 'ath0_wlan1'
what we get from escape ..
/sbin/ifconfig wlan create wlandev 'ath0' 'wlanmode hostap' bssid name 'ath0_wlan1'
this also makes the new fix/commit not requried, but no overwiew on whole code so just statement base on the troubleshooting
#3
26.1 Series / Re: Firewall rules are sticky
Last post by eck - Today at 01:22:18 PMThank you for the answer.
Still it is a strange behavior.
Better was a question to leave the states active or reset them right away.
Still it is a strange behavior.
Better was a question to leave the states active or reset them right away.
#4
26.1 Series / Re: Prefix delegations when PD...
Last post by staticznld - Today at 12:50:24 PMAccording to the documentation, "Identity Association" allows manual configuration. I will try that later.
QuoteIdentity Association offers similar functionality like Track Interface (legacy), but without automatic ISC-DHCPv6 and Radvd configuration. It is intended for pure RA and DHCPv6 configuration using Dnsmasq or Kea/Radvd.
#5
26.1 Series / Re: Need to select "Prefer to ...
Last post by trdeal - Today at 12:48:00 PMHi
My ISP has an MTU of 1492 bytes with the IPv6 standard specifying a minimum of 1280 bytes. For an IPv6 communication to take place the PMTU (Path Maximum Transmission Unit) needs to be discovered or configured as any packets that exceed the PMTU are dropped as IPv6 does not fragment packets the way that IPv4 does. So the PMTU must be determined for successful IPv6 communication to occur between hosts.
So while I have configured the MTU which works fine for IPv4 traffic from the opnsense and for IPv4/IPv6 tranffic traversing opnsense, however when opnsense attempts to make an IPv6 connection itself it is not honouring the MTU from which the PMTU should be defined. This appears to be a bug in opnsense not honouring the MTU (PMTU) value itself and generating too large a packet which will be dropped.
My ISP has an MTU of 1492 bytes with the IPv6 standard specifying a minimum of 1280 bytes. For an IPv6 communication to take place the PMTU (Path Maximum Transmission Unit) needs to be discovered or configured as any packets that exceed the PMTU are dropped as IPv6 does not fragment packets the way that IPv4 does. So the PMTU must be determined for successful IPv6 communication to occur between hosts.
So while I have configured the MTU which works fine for IPv4 traffic from the opnsense and for IPv4/IPv6 tranffic traversing opnsense, however when opnsense attempts to make an IPv6 connection itself it is not honouring the MTU from which the PMTU should be defined. This appears to be a bug in opnsense not honouring the MTU (PMTU) value itself and generating too large a packet which will be dropped.
#6
26.1 Series / Re: Firewall rules are sticky
Last post by meyergru - Today at 12:39:09 PMSee the first note in the docs? A reboot is not neccessary.
#7
26.1 Series / Re: Prefix delegations when PD...
Last post by staticznld - Today at 12:34:36 PMSee the attached screenshot for the LAN settings.
I thought that when "Manual configuration" is turned off, only radvd distributes IPv6 addresses.
I am assigned a /48 prefix by my ISP.
I thought that when "Manual configuration" is turned off, only radvd distributes IPv6 addresses.
I am assigned a /48 prefix by my ISP.
#8
26.1 Series / Re: wrong interface after upgr...
Last post by franco - Today at 12:34:32 PM... which only happens when you assign an interface that moves it's location upon reboot or is not there during early boot?
Cheers,
Franco
Cheers,
Franco
#9
26.1 Series / 26.1: intra vlan traffic is no...
Last post by giox969 - Today at 12:33:45 PMHi, after upgrade to 26.x (currently 26.1.1-amd64), all intra vlan traffic is permitted and no longer blocked.
According to the firewall logs, the "let out anything from firewall host itself" rule, is allowing traffic from/to internal VLANS/LAN.
The rule "let out anything from firewall host itself" is applied automatically before my interface group "last match" blocking rule, so my blocking rule cannot be used. My interface group last match blocking rule was working correctly, blocking intra vlan traffic, before the upgrade.
I also tried to convert rules to the new version, deleted all old rules, rebooted, but nothing changed. Intra vlan traffic is still permitted.
Is it correct that in 26.x "let out anything from firewall host itself" allows traffic not originating from the firewall ?
According to the firewall logs, the "let out anything from firewall host itself" rule, is allowing traffic from/to internal VLANS/LAN.
The rule "let out anything from firewall host itself" is applied automatically before my interface group "last match" blocking rule, so my blocking rule cannot be used. My interface group last match blocking rule was working correctly, blocking intra vlan traffic, before the upgrade.
I also tried to convert rules to the new version, deleted all old rules, rebooted, but nothing changed. Intra vlan traffic is still permitted.
Is it correct that in 26.x "let out anything from firewall host itself" allows traffic not originating from the firewall ?
#10
26.1 Series / Re: Missing plugin: os-lcdproc...
Last post by franco - Today at 12:33:12 PMThis will reset it to default:
# opnsense-revert os-lcdproc-sdeclcd
Cheers,
Franco
# opnsense-revert os-lcdproc-sdeclcd
Cheers,
Franco
