Messages

31

General Discussion / Re: IPv6 privacy extensions for WAN interface

« on: April 02, 2019, 09:54:17 pm »

I have enabled the following two options:

• net.inet6.ip6.use_tempaddr
• net.inet6.ip6.prefer_tempaddr

Now, the pppoe interface gets an additional temporary address when using SLAAC. Basic tests shows that this address is used for Internet communication via opnsense's proxy.

We should consider that this kind of addresses should not be used for DynDNS registrations because the binding gets invalid in case the temporary address changes.

Edit:
The temporary address is not shown in the GUI (possibly a bug?) but is shown with ifconfig. You can also verify using websites like http://ipv6-test.com/ or https://www.whatismyip.com/

32

General Discussion / Re: DynDNS for IPv6 not working

« on: April 02, 2019, 09:43:51 pm »

PPPoE (pppoe0) interface is a virtual one on top of ethernet (ix0)

The DynDNS configuration "Custom v6" tries to gather the ipv6 address from the ix0 interface instead of pppoe0 if I understand the logfiles correctly.

Has anybody successfully running DynDNS with "Custom v6" profile?

33

General Discussion / Re: DHCP on WAN with public IP via RFC1918?

« on: April 02, 2019, 06:21:52 pm »

It is not a usual setup because it can conflict with private networks using the same shared address space. But, I had the same situation years ago with telefonica backend for my DSL.

34

General Discussion / Re: IPv6 privacy extensions for WAN interface

« on: March 29, 2019, 08:04:33 pm »

I also did some research and figured out that FreeBSD supports privacy extensions which can be controlled by syscontrols

• net.inet6.ip6.use_tempaddr
• net.inet6.ip6.prefer_tempaddr

I'll test this the next days. Adjusting the syscontrols is already included in opnsense's system tunables (System -> Settings -> Tunables).

35

General Discussion / Re: IPv6 privacy extensions for WAN interface

« on: March 28, 2019, 06:13:11 pm »

I know that /64 is a single subnet. Because my internal network is still IPv4 only, I do not need to request a delegation prefix. Thus, the subnet offered by my ISP is correct.

Related to privacy extensions clients are responsible to randomize their host id. But, please consider the opnsense machine also as a client due to its services (proxy, ntpd etc.). So, the firewall should also randomize its own IPv6 address when using SLAAC.

Clients in my LAN (IPv4) use the proxy to access IPv6 ressources in the Internet.

36

General Discussion / Strange behavior with IPv6 on PPPoE [was: DynDNS for IPv6 not working]

« on: March 27, 2019, 07:39:30 pm »

Hello,

I have problems to register the IPv6 address of the firewalls WAN interface to my DynDNS operator. I got the following results:

• Registering the IPv4 address using the built-in DynDNS client (Custom) works fine
• Registering the IPv6 address using the built-in DynDNS client (Custom v6) fails
• Triggering the IPv6 registration URL via command line using curl works fine

A packet capture shows that the DynDNS client does not communicate with the server, but the log file shows the following error message, even though the WAN interface has a public IPv6 address assigned:

opnsense: /services_dyndns_edit.php: Dynamic DNS (<hostname>) There was an error trying to determine the public IP for interface - wan(ix0). Probably interface is not a WAN interface.

Update URL: https://update.spdyn.de/nic/update?hostname=xxxx&myip=%IP%&user=xxxx&pass=yyyy

Does anybody has similar problems?

37

General Discussion / IPv6 privacy extensions for WAN interface

« on: March 27, 2019, 07:25:33 pm »

Today I started the first experiment to migrate to IPv6. First step is a basic setup for accessing IPv6 webpages.

So, I request an IPv6 address from my ISP to be assigned to the WAN interface. The router advertisment message from my ISP offers me a /64 prefix (currently no prefix delegation is used). The firewall itself generates an IPv6 address for its WAN interface via SLAAC.

What I am missing is an option to enable IPv6 privacy extensions, to random the host id. Are privacy extensions implemented in Opnsense (v.19.1.4)?

38

19.1 Legacy Series / Re: IPSEC Tunnel not working anymore

« on: March 14, 2019, 09:55:17 pm »

I have updated from 19.1.2 to 19.1.4 and my IPSec connections (1 x site2site, 2 x mobile) still work fine without installing the patch. Is the latter only needed in case of using VTI?

39

19.1 Legacy Series / Re: Problem with WAN - right setup with FritzBox router

« on: March 06, 2019, 02:39:24 pm »

You can use the Fritzbox in routing mode with additional PPPoE forwarding/passthrough (example with Fritzbox 7412 shown here).

40

19.1 Legacy Series / Re: Kernel panic after upgrade

« on: March 01, 2019, 07:05:06 pm »

I have migrated from 18.7.10_4 to 19.1.2. The migration process worked without any problems.

My system:

• Board: Supermicro A2SDi-4C-HLN4F
• RAM: 8 GB
• Sys: 64 Bit

Many thanks to all the developers and contributors who made this version possible 

41

German - Deutsch / Re: Frage zu Syncookies

« on: February 08, 2019, 07:39:43 pm »

Syncookies sind standardmäßig eingeschaltet. Es betrifft auch nur TCP-Verbindungen, die auf der Opnsense terminieren (also jegliche abhörende TCP-Ports von den laufenden Diensten).

Sollte für die meisten Anwender also relativ belanglos sein, es sei denn, sie haben TCP-Dienste ins Internet exponiert.

42

19.1 Legacy Series / Re: [isolated: see #91] PPPoE reconnect loop

« on: February 04, 2019, 10:14:02 pm »

Last ticket update on https://github.com/opnsense/core/issues/2267 on 26 Jun 2018. As stated elsewhere, please complain early *and* often.

My work queue that is based on 100% self-funding after my 40 hour day job entirely away from OPNsense is maxed out either way. I can only prioritise according to user feedback and progress.


Cheers,
Franco

I know how much time you and the other core members spent in programming within this project, many thanks for that. I help to improve things by testing, investigating bugs, giving hints and so forth. To investigate and isolate the PPPoE bug took me a long time. This bug affects a lot of people, especially those using 1&1 as ISP.

I reported and described the bug at github, so that everybody is able to comprehend what the real issue is. The bug is still open and will not solve itself. Currently, I use a workaround to make Opnsense work. But after a system update, the workaround gets overwritten and I have to reapply the temporary patch which is difficult because of regularly upcoming "state resets".

Ok, do you need any additional input, to proceed in solving this issue?

43

19.1 Legacy Series / [isolated: see #91] PPPoE reconnect loop

« on: January 30, 2019, 06:07:55 pm »

Opnsense 19.1 will be released the next time. Thank you to all who made this happen. I was really happy that the problem with PPPoE reconnect loops will get solved in this version. Unfortunately, a bugfix has been postponed again.

Without a bugfix opnsense stops working after every update and it is difficult to patch the system by hand because every reconnect attempt rises the state reset feature to clean up the NAT tables. This was introduced to keep SIP communication working after ISP initiated IP address change.

The previous part of the whole thread began with Opnsense 18.1: see here.

Is there a chance to get the problem solved before release 19.7?

44

18.1 Legacy Series / Re: [isolated: see #91] PPPoE reconnect loop

« on: January 29, 2019, 06:16:25 pm »

Opnsense 19.1 will be released the next time. Thank you to all who made this happen. I was really happy that the problem with PPPoE reconnect loops will get solved in this version. Unfortunately, a bugfix has been postponed again.

Without a bugfix opnsense stops working after every update and it is difficult to patch the system by hand because every reconnect attempt rises the state reset feature to clean up the NAT tables. This was introduced to keep SIP communication working after ISP initiated IP address change.

Is there a chance to get the problem solved before release 19.7?

[Edit]
The topic is still relevant for upcoming release Opnsense 19.1, so further discussion will move to this forum (see here). Please answer there.

45

18.7 Legacy Series / Re: Kernel panic when unplugging WAN network interface

« on: January 09, 2019, 05:34:50 pm »

The error looks like a software bug in the NIC driver or kernel. Unplugging the interface (network cable) triggers a hardware interrupt (irq259 in the error message). The code behind that accesses a virtual memory address which is not mapped to a physical memory page.

To prevent unknown system behaviour with possibly trashing data the kernel panics into fail stop mode. In this case, the nic driver or kernel needs an update. Is the nic driver seperately installed or shipped with opnsense? In the latter case the BSD kernel team needs a bug report.