Messages

Without context it comes down to speculation most of the time.
Having said that, when someone expects something to work in a particular way, who am I to say that it can not be done, aside from the original intention of the author of that script/piece of software.

In this case I would not like to state that something is either right or wrong, just that it did not work the way someone expected it to work.

So no offense meant in any way to anyone or anything. Just trying to help out ;-).

Had the same issue and did a quick and dirty fix by patching /usr/local/opnsense/scripts/firmware/connection.sh (patch included).

That is the script that does the connectivity check. It performs a ping command on IPv4 and IPv6 using a 1500 byte packet size. If I'm not mistaken, the maximum packet size for IPv4 using an MTU of 1500 is 1472. For IPv6 the maximum size is 1452. Bottom line is that if you know the MTU of your WAN-interface and subtract 28 bytes for IPv4 and 48 bytes for IPv6, you get the maximum packet size that can be used in said script.

You could calculate the values dynamically, but I was too lazy to do that (for now).

Best regards.

In my case, traffic is dropping back pretty much instant (well, maybe a second) on both interfaces. I think something else is causing this in your case, not sure what though. Have you tried connecting the STB directly to the router instead of behind (non-IGMP snooping enabled?) switches to see if that changes anything?

After another reboot I now see that everything works according to specs  ???.
Anyway ... thanks for pointing out what to expect. Made me go and question myself and my setup  ;).

Best regards.

Good work!

Last question though ... on both LAN- and WAN-side I see that while one stream is about 14Mbps, when I switch channels the consumed bandwidth on the WAN-side doubles for about 3 minutes (to about 28Mbps) , while on the LAN-side it takes about half a minute before everything is back to normal. Is that expected behaviour? Never looked at it in this detail before, so I hope you don't mind me asking  ::)

Best regards.

I think this issue will be fixed as well if the streams are correctly released after the unsubscribe request. I will be available to test stuff next week; I'm more than happy to test potential fixes.

I seem to have the same problems. Restarting IGMP proxy is the workaround I use for now. Happy to help with testing/sharing my config when needed.

Best regards.

If I may I would recommend some light reading. Perhaps the following article can get you on the right track?

https://www.jscape.com/blog/setting-up-an-ftps-server-behind-a-firewall-or-nat-for-pasv-mode-data-transfers

Best regards.

[Subject: CN = forum.opnsense.orgDNS:forum.opnsense.org]

Some background on SAN, for those who are interested.

The most straight forward type of certificate will have only 1 fqdn and even there you will find that the besides the subject you will also find a SAN entry of type DNS with the same fqdn.

The following code snippets extract the certificate from a website and show the subject name and SAN DNS names.

Code Select Expand

echo | openssl s_client -servername forum.opnsense.org -connect forum.opnsense.org:443 2>&- | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 }' | openssl x509 -in - -noout -text | grep "Subject:\|DNS:" | sed 's/^[[:space:]]*//'

Subject: CN = forum.opnsense.org
DNS:forum.opnsense.org


Certificates can have more than one fqdn and this will always result in exactly one fqdn ending up being the subject whereas all fqdn's will be added to the SAN-section of the certificate, even the fqdn that is used as the subject.
I've even seen certificates with a subject not used in the SAN-section at all, but while that also works (as long as you don't use the subject name), I would not recommend that for normal use.

Code Select Expand

echo | openssl s_client -servername letsencrypt.com -connect letsencrypt.com:443 2>&- | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/ { print $0 }' | openssl x509 -in - -noout -text | grep "Subject:\|DNS:" | sed 's/^[[:space:]]*//'

Subject: CN = lencr.org
DNS:lencr.org, DNS:letsencrypt.com, DNS:letsencrypt.org, DNS:www.lencr.org, DNS:www.letsencrypt.com, DNS:www.letsencrypt.org


For those who are interested in reading some more about the "Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates", here's a link to the latest information: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.4.pdf.

[Firewall: NAT: Port Forward]

To illustrate, the following would have to be done for access to a LAN-host using IPv4 and IPv6 on port 8080.

Firewall: NAT: Port Forward

Code Select Expand

Source Destination NAT
Interface Proto Address Ports Address Ports IP Ports Description

WAN_INTERNET TCP * * WAN_INTERNET address 8080 192.168.1.234 8080 Access from internet to LAN-host
WAN_INTERNET UDP * * WAN_INTERNET address 8080 192.168.1.234 8080 Access from internet to LAN-host


Firewall: Rules: WAN_INTERNET

Code Select Expand

Protocol Source Port Destination Port Gateway Schedule Description

IPv6 UDP * * 2001:0db8:1234::234/64 8080 * * Access from internet to LAN-host
IPv6 TCP * * 2001:0db8:1234::234/64 8080 * * Access from internet to LAN-host

Eh ... When trying to get IPv4 and IPv6 connectivity from the internet to a specific host on the LAN-side, I would make a NAT port forward rule for IPv4 and a normal allow rule for IPv6 on the WAN-interface. No need to NAT IPv6, right?

Best regards.

Hoe bedoel je precies de Ziggo box er tussen uit?

https://www.ziggo.nl/klantenservice/internet-wifi/bridge-modus

Topic Starter

Dank u!  :)

No worries. Was in een bijdehante bui  ;D.

Nu heb je mij weer een beetje ... wat is (een) TS?

En voor het geld hoe je het niet te laten. Ik gebruik een GS108Ev3 van 30 tientjes ofzo.

300 euro, Daar kan ik er ongeveer 10 van kopen  ;D
(https://tweakers.net/pricewatch/424304/netgear-prosafe-gigabit-plus-gs108ev3.html)

@RZR, I think you got things mixed up.

Not talking TLSv1.3 specifics right now, but ...

With RSA-certificates you can achieve PFS. PFS only depends on the key exchange method.

With RSA key exchange a symmetric key is exchanged "over the line" so when someone obtains the private key, traffic can be decrypted when listening in on (or replaying recorded) traffic. When using Diffie-Hellman a symmetric key is "calculated" and never sent "over the line", so it can't be found by listening in on (or replaying recorded) traffic.

Hope that makes sense?  ;)

https://forum.opnsense.org/index.php?topic=30145.msg145541#msg145541

The update is pulled for now.