OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of bringha »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Messages - bringha

Pages: 1 2 [3] 4 5 ... 13
31
19.1 Legacy Series / Re: Upgrade to 19.1.1 - no ipv6 gateway
« on: February 17, 2019, 04:48:59 pm »
Changed it and rebooted but no success, still:

Code: [Select]
Feb 17 16:44:37 OPNsense dhcp6c[88324]: restarting
Feb 17 16:44:37 OPNsense dhcp6c[88324]: Start address release
Feb 17 16:44:37 OPNsense dhcp6c[88324]: Sending Release
Feb 17 16:44:37 OPNsense dhcp6c[88324]: Received REPLY for RELEASE
Feb 17 16:44:37 OPNsense dhcp6c[88324]: status code: success
Feb 17 16:44:37 OPNsense dhcp6c: dhcp6c RELEASE on igb1 - running newipv6
Feb 17 16:44:37 OPNsense dhcp6c[88324]: Sending Solicit
Feb 17 16:44:37 OPNsense dhcp6c[88324]: unknown or unexpected DHCP6 option opt_86, len 16
Feb 17 16:44:38 OPNsense dhcp6c[88324]: Sending Request
Feb 17 16:44:38 OPNsense dhcp6c[88324]: unknown or unexpected DHCP6 option opt_86, len 16
Feb 17 16:44:38 OPNsense dhcp6c[88324]: Received REPLY for REQUEST
Feb 17 16:44:38 OPNsense dhcp6c[88324]: invalid prefix length 62 + 4 + 64
Feb 17 16:44:38 OPNsense dhcp6c[88324]: invalid prefix length 62 + 4 + 64
Feb 17 16:44:38 OPNsense dhcp6c[88324]: invalid prefix length 62 + 4 + 64
Feb 17 16:44:38 OPNsense dhcp6c: dhcp6c REQUEST on igb1 - running newipv6

 :-\

32
19.1 Legacy Series / Re: Upgrade to 19.1.1 - no ipv6 gateway
« on: February 17, 2019, 03:59:40 pm »
Hmmmmm ... Not sure whether this will reflect my configuration: I connect to my ISP via a Fritzbox. This Fritzbox I have configured with

DNS-Server und IPv6-Präfix (IA_PD) zuweisen

After the reboot of all Fritzbox and sense, I have a new error message:

Code: [Select]
Feb 17 15:50:08 OPNsense dhcpd: RTSOLD script - Starting dhcp6 client for interface wan(igb1)
Feb 17 15:50:08 OPNsense dhcpd: RTSOLD script - Sending SIGHUP to dhcp6c for interface wan(igb1)
Feb 17 15:50:08 OPNsense dhcp6c[28493]: restarting
Feb 17 15:50:09 OPNsense dhcp6c[28493]: Sending Solicit
Feb 17 15:50:09 OPNsense dhcp6c[28493]: unknown or unexpected DHCP6 option opt_86, len 16
Feb 17 15:50:10 OPNsense dhcp6c[28493]: Sending Request
Feb 17 15:50:10 OPNsense dhcp6c[28493]: unknown or unexpected DHCP6 option opt_86, len 16
Feb 17 15:50:10 OPNsense dhcp6c[28493]: Received REPLY for REQUEST
Feb 17 15:50:10 OPNsense dhcp6c[28493]: invalid prefix length 62 + 8 + 64
Feb 17 15:50:10 OPNsense dhcp6c[28493]: invalid prefix length 62 + 8 + 64
Feb 17 15:50:10 OPNsense dhcp6c[28493]: invalid prefix length 62 + 8 + 64
Feb 17 15:50:10 OPNsense dhcp6c: dhcp6c REQUEST on igb1 - running newipv6

Would this fit to your recommendation? I had never before to deal with DUID stuff et al with a Fritzbox before ...

Thanks again for your support ....

Br Br

33
19.1 Legacy Series / Re: Upgrade to 19.1.1 - no ipv6 gateway
« on: February 17, 2019, 03:18:31 pm »
OK ....

After reboot and having the interfaces description as mentioned, the DHCP log contains for dhcp6c

Code: [Select]
Feb 17 15:15:05 OPNsense dhcp6c[78038]: Sending Solicit
Feb 17 15:15:05 OPNsense dhcp6c[78038]: advertise contains NoAddrsAvail status
Feb 17 15:15:13 OPNsense dhcp6c[78038]: Sending Solicit
Feb 17 15:15:13 OPNsense dhcp6c[78038]: advertise contains NoAddrsAvail status
Feb 17 15:15:24 OPNsense dhcpd: DHCPREQUEST for 192.168.1.10 from 00:25:XX:XX:XX via igb0
Feb 17 15:15:24 OPNsense dhcpd: DHCPACK on 192.168.1.10 to 00:25:XX:XX:XX via igb0
Feb 17 15:15:29 OPNsense dhcp6c[78038]: Sending Solicit
Feb 17 15:15:29 OPNsense dhcp6c[78038]: advertise contains NoAddrsAvail status


34
19.1 Legacy Series / Re: Upgrade to 19.1.1 - no ipv6 gateway
« on: February 17, 2019, 02:43:19 pm »
Thanks Marjohn - the good thing is that my ipv6 gateway shows now online again

However, my interfaces now don't get any ipv6 address advertised still and the dhcpd6 cannot be started either still - is there any adaption I need to make for the other interfaces too?

Looking forward to your reply

35
19.1 Legacy Series / [SOLVED] Upgrade to 19.1.1 - no ipv6 gateway
« on: February 17, 2019, 02:02:02 pm »
Hi,

after upgrading to 19.1.1 from 18.7, the ipv6 gateway is shown as offline and cannot be started from GUI anymore. The issue is that there is no rtsold process anymore pickup the prefix from WAN and  also dhcp6d can not be started.

The logs do not show any hint except that they state that there is no ipv6 default route possible to be set;
Code: [Select]
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: The command '/bin/pkill -'HUP' 'php-cgi'' returned exit code '1', the output was ''
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: entering configure using defaults
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: IPv4 default gateway set to wan
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: IPv6 default gateway set to wan
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: setting IPv4 default route to 192.168.2.1
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: keeping current default gateway '192.168.2.1'
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: skipping IPv6 default route
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: entering configure using 'wan'
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: IPv4 default gateway set to wan
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: IPv6 default gateway set to wan
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: setting IPv4 default route to 192.168.2.1
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: removing /tmp/igb1_defaultgw
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: creating /tmp/igb1_defaultgw using '192.168.2.1'
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: skipping IPv6 default route
Feb 17 13:54:57 OPNsense opnsense: /interfaces.php: Warning! services_radvd_configure(auto) found no suitable IPv6 address on igb2
Feb 17 13:54:57 OPNsense opnsense: /interfaces.php: Warning! services_radvd_configure(auto) found no suitable IPv6 address on igb0
Feb 17 13:54:57 OPNsense opnsense: /interfaces.php: Warning! services_radvd_configure(auto) found no suitable IPv6 address on igb3

dpinger can not be started as well (clear if there is no ipv6 gateway ....)

Any idea where to look after?

Br br

36
18.7 Legacy Series / Re: New Install Problem - Not able to open websites on lan through firewall
« on: October 25, 2018, 07:30:46 pm »
Next, please check whether you have under System->routes all the routes you require to get traffic at the right places

Then, please check whether your DNS is configured correctly and is accessible from the clients

All that as suggested by others with ONE client directly connected to the LAN interfaces of the sense ....

Br br

37
18.7 Legacy Series / Re: New Install Problem - Not able to open websites on lan through firewall
« on: October 25, 2018, 08:01:23 am »
Quote
WAN DHCP gets various addresses e.g., 24.x.x.x, 69.x.x.x 75.x.x.x so can't give you a specific one
Just to be clear: The WAN Port of your opnsense gets an address out of one of these networks?

Br br

38
18.7 Legacy Series / Re: New Install Problem - Not able to open websites on lan through firewall
« on: October 24, 2018, 07:47:14 pm »
... and before: What is the network address in the WAN DHCP network ....

Br br

39
18.7 Legacy Series / Re: Link local address on Lan and Opt are overwritten when using interface tracking
« on: October 24, 2018, 01:47:27 pm »
Don't understand that last statement - not at all the intention behind the discussion from my side

I am coming from the point that IF a decision should be made do adapt THEN it should include ...

If the decision should be to leave it as it is (and there are also good reasons for) - fine

Br br

40
18.7 Legacy Series / Re: Link local address on Lan and Opt are overwritten when using interface tracking
« on: October 24, 2018, 12:35:58 pm »
Thats for sure true!

In all cases, this would mean that a provided LL address must be possible to be changed manually then ... ideally via GUI.

Br br

41
18.7 Legacy Series / Re: Link local address on Lan and Opt are overwritten when using interface tracking
« on: October 24, 2018, 08:40:50 am »
Quote
To be consistent you can simply remove the few code lines. Adding the possibility to change/add the LL address via the web interface is then the icing on the cake.
Here I disagree - The result of the current interface tracking implementation leads to a convention compliant address scheme with fe80::1:1%<zoneid> result on the internal interface as a router should have. We may dispute whether the current chosen hardcoded method is the most elegant one, however, if this is no longer generated automatically, there must be a possibility to add/modify this address manually (best) via the GUI. The one without the other does not make sense to me.

Br br

42
18.7 Legacy Series / Re: Link local address on Lan and Opt are overwritten when using interface tracking
« on: October 23, 2018, 07:40:48 pm »
Hi Franco,

Imho its a question of philosophy OPNsense wants to follow in future:

Alternative 1: Full flexibility with LL Addresses as being  assigned by Kernel
But then, simply removing the code would not be enough, there should be an option to set LL addresses manually as emwe has suggested to support the convention model as discussed earlier

Alternative 2: Leave the code in and have a kind of 'built in hard coded' support of the mentioned conventions

The current model supports the 'OPNsense-is-a-router' philosophy and obviously the use cases the today users have can be served (as you rightfully said, there was no momentum for a change since 2016). On the other hand for the price that some configs are then 'limited'.

I personally don't miss yet the additional possibilities of Alternative 1 would be able to offer but others might see this differently. I prefer a rather clear model as Alternative 2 is showing. If going for Alternative 1, the extensions in the GUI are from my perspective mandatory ....

Just my 10c

Br br

43
18.7 Legacy Series / Re: Link local address on Lan and Opt are overwritten when using interface tracking
« on: October 23, 2018, 06:58:43 pm »
Hi Franco,

what do you mean with the 'old link-local switcheroo for the tracking' specifically' ?

Br br

44
18.7 Legacy Series / Re: New Install Problem - Not able to open websites on lan through firewall
« on: October 23, 2018, 06:30:21 pm »
I think we need start one step back ....

Can you provide a drawing of your network config, what is connected to what and IP network addresses you have used on your interfaces, modem, client, ....

Br br

45
18.7 Legacy Series / Re: Link local address on Lan and Opt are overwritten when using interface tracking
« on: October 23, 2018, 04:38:00 pm »
Hi emwe

Although you would like to have this solved via different LL Addresses  ;)  I would suggest however to consider the following two options as an alternate possibility

If I have understood your target config correctly, there are eg:

Option 1: Route traffic to WAN 2 via Router 1.

Imho Router 2 (WAN 2) does not need to send RA. If for what reasons ever RA should be required, then the relevant config in radvd.conf should look like (eth0 is the Interface to your internal subnet):

Code: [Select]
interface eth0 {
  AdvSendAdvert on;
  AdvDefaultLifetime 0;
  MinRtrAdvInterval 3;
  MaxRtrAdvInterval 10;
  route 2006:cadf:485e::/48 {};
};

AdvDefaultLifetime 0 prevents that router 2 advertises a default gateway and confuses the client by overwriting the default gateway being advertised from Router 1. You don't need to advertise the prefix option on eth0 of Router 2 because Router 1 is already doing that. Router 1 needs furthermore a (static) route to Router 2 for the WAN subnet behind it. Clients that don't understand the route option will use Router 1 as default gateway, and then Router 1 needs to know where to send those packets.

Option 2: Have second routing table on each client as well as (virtual) dedicated NICs connecting to the WAN 2 router.
In Linux, this function is provided eg via iproute2; here you can add an additional routing table and assign it to the related NICs.(see also suggestion from Franco in the other post)

Should work ....

Further options indeed possible ....

Br br


Pages: 1 2 [3] 4 5 ... 13
OPNsense is an OSS project © Deciso B.V. 2015 - 2021 All rights reserved
  • SMF 2.0.18 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2