Messages

106

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

107

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

108

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

109

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

110

18.7 Legacy Series / Re: LAN and OPT1 interface are getting the same link local address

« on: October 21, 2018, 03:22:57 pm »

Hi emwe

By definition there can only be one default gateway per routing table. Same is true for IPv4. if you want to route traffic to several gateways use source based routing and create additional routing tables with default routes specific per table. A roule is required which router to use with what source address.

As also stated in the link above, next chapter network design:

As each IPv6-enabled router interface will already have a link-local address generated based on the modified EUI-64 scheme, the address fe80::1 will either replace or augment this automatically generated address. At the same time an existing global unicast address on the interface will not be affected.

Have not tested yet whether OPNsense behaves like that; anyhow, this would be the more compliant solution ....

Br br

111

18.7 Legacy Series / Re: New Install Problem - Not able to open websites on lan through firewall

« on: October 20, 2018, 08:33:42 pm »

Hi there,

I faced the same challenge when I went from ipcop to opnsense about 3 years ago. As opnsense is a stateful firewall (other than ipcop), the rule logic is somewhat different from ipcop. What could help you a lot is this article:

https://forum.opnsense.org/index.php?topic=4436.0

Its in German, hope you can read it ....

BR br

112

18.7 Legacy Series / Re: Stopped working

« on: October 20, 2018, 08:04:27 pm »

... And you root filesystem is on da0 or da1?

This reads to me that after a reboot (?) it cannot find its root filesystem anymore ..... and now asking in taptalk to give the information where the root filesystem is ...

Br br

113

18.7 Legacy Series / Re: LAN and OPT1 interface are getting the same link local address

« on: October 20, 2018, 07:45:29 pm »

Hi emwe,

If its for your configuration a good decision to give your sense a different LL address - fine...  but I doubt that this is a good solution in general:

There is a widely accepted convention in ipv6 network design that LL address fe80::1:1%<zoneid> is used as default ipv6 gateway address. See eg here again: https://www.edge-cloud.net/2013/08/07/ipv6-link-local-addresses-as-default-gateway/amp/, section 'ipv6 use case'.

Having a textual representation of fe80::1:1%<zoneid> for this address is all what you need. As with that all autoconf ipv6 protocols work like a charm I am wondering rather vice versa, what use case behind really REQUIRES to have a different LL address on the interfaces of our router node in your network. The cited comment from the source around CARP is something which is according my understanding not really a practical problem yet ...

I personally rather tend to explicitly APPRECIATE that all my LANs have a standard ipv6 gateway address so that setting the default gateway in pure autoconf setups does not require extra 'research' to find the specific LL address of the sense interface .... One of my sense has btw 8 NICs and there might be even bigger scenarios ...

Historically, a similar convention is also in ipv4, where in private address space eg 192.168.X.1 and 192.168.X.254 are the recommended router/gateway addresses

Br br

114

18.7 Legacy Series / Re: LAN and OPT1 interface are getting the same link local address

« on: October 19, 2018, 09:16:56 am »

Hi emwe,

here for comparison my config with 4 nics also using tracking of the WAN and having 4 different scopeid's. WAN is igb1. As you can see, all my internal interfaces have an fe80::1:1 with translated scopeid/zoneindex according to the standard.

However, my interfaces do not show the 'duplicated' attribute for the link local address. Interesting to find out from where this is coming from. Never seen that before for an LL Address with scopeID. As it is also described in your wikipedia article, differentiation of equal LL addresses are done with the zoneID. Could it be that you have the same scopeID on different network interfaces or that dmz and lan are bridged (eg via switch)?

Code: [Select]

igb0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,TXCSUM_IPV6>
ether 00:XX:1a
hwaddr ac:XX:98
inet 192.168.XX.XX netmask 0xffffff00 broadcast 192.168.XX.255
inet6 2003:XX:a21a prefixlen 64
inet6 fe80::1:1%igb0 prefixlen 64 scopeid 0x1
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igb1: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,TXCSUM_IPV6>
ether 00:XX:1d
hwaddr ac:XX:99
inet6 fe80::XX:a21d%igb1 prefixlen 64 scopeid 0x2
inet6 2003:XX:febe:a21d prefixlen 64 autoconf
inet 192.168.XX.XX netmask 0xffffff00 broadcast 192.168.XX.255
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igb2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,TXCSUM_IPV6>
ether 00:XX:c7
hwaddr ac:XX:9a
inet 192.168.XX.1 netmask 0xffffff00 broadcast 192.168.XX.255
inet6 2003:XX:4bc7 prefixlen 64
inet6 fe80::1:1%igb2 prefixlen 64 scopeid 0x3
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igb3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,TXCSUM_IPV6>
ether 00:XX:c6
hwaddr ac:XX:9b
inet 10.XX.XX.1 netmask 0xffffff00 broadcast 10.XX.XX.255
inet6 2003:XXXX:4bc6 prefixlen 64
inet6 fe80::1:1%igb3 prefixlen 64 scopeid 0x4
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active

Br br

115

18.7 Legacy Series / Re: LAN and OPT1 interface are getting the same link local address

« on: October 18, 2018, 09:29:58 am »

Nothing goes wrong - all fine!

fe80::1:1 is the link local ipv6 default gateway address. With the zoneid extension %<interface> its getting properly differentiatable. The WAN has indeed no default gateway on its own interface ...

Background see eg here

https://www.edge-cloud.net/2013/08/07/ipv6-link-local-addresses-as-default-gateway/amp/

Br br

116

18.7 Legacy Series / Re: telegraf feature request

« on: October 14, 2018, 01:45:13 pm »

Some more:

also interesting would be

Code: [Select]

[[inputs.statsd]]
because it allows a bunch of statistics around tcp connections et al.

However, although being contained in the ports tree of opnsense as described here https://forum.opnsense.org/index.php?topic=2004 (indeed upgraded to 18.7.) it does not compile as some dependencies can not be built

Code: [Select]

===>  Staging for statsd-0.7.2_1
===>   statsd-0.7.2_1 depends on package: node6>=0 - not found
/!\ WARNING /!\

Ports Collection support for your FreeBSD version has ended, and no ports are
guaranteed to build on this system. Please upgrade to a supported release.

===>  License MIT accepted by the user
===>   node6-6.14.4 depends on file: /usr/local/sbin/pkg - found
=> node-v6.14.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://nodejs.org/dist/v6.14.4/node-v6.14.4.tar.gz
node-v6.14.4.tar.gz                           100% of   25 MB 2690 kBps 00m10s
===> Fetching all distfiles required by node6-6.14.4 for building
===>  Extracting for node6-6.14.4
=> SHA256 Checksum OK for node-v6.14.4.tar.gz.
===>  Patching for node6-6.14.4
===>  Applying FreeBSD patches for node6-6.14.4
===>   node6-6.14.4 depends on executable: gmake - found
===>   node6-6.14.4 depends on file: /usr/local/bin/python2.7 - found
===>   node6-6.14.4 depends on package: pkgconf>=1.3.0_1 - found
===>   node6-6.14.4 depends on file: /usr/local/lib/libcrypto.so.9 - found
===>   node6-6.14.4 depends on shared library: libcares.so - found (/usr/local/lib/libcares.so)
===>   node6-6.14.4 depends on shared library: libuv.so - not found
===>   libuv-1.23.2 depends on package: autoconf>=2.69 - found
===>   libuv-1.23.2 depends on package: automake>=1.16.1 - found
===>   libuv-1.23.2 depends on executable: libtoolize - not found
/!\ WARNING /!\

Ports Collection support for your FreeBSD version has ended, and no ports are
guaranteed to build on this system. Please upgrade to a supported release.

===>  License GPLv2 accepted by the user
===>   libtool-2.4.6 depends on file: /usr/local/sbin/pkg - found
=> libtool-2.4.6.tar.xz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.xz
libtool-2.4.6.tar.xz                          100% of  950 kB 2461 kBps 00m00s
===> Fetching all distfiles required by libtool-2.4.6 for building
===>  Extracting for libtool-2.4.6
=> SHA256 Checksum OK for libtool-2.4.6.tar.xz.
===>  Patching for libtool-2.4.6
===>   libtool-2.4.6 depends on executable: gm4 - found
===>   libtool-2.4.6 depends on executable: gmake - found
===>   libtool-2.4.6 depends on executable: makeinfo - not found
===>   texinfo-6.5,1 depends on executable: help2man - not found
===>   help2man-1.47.7 depends on executable: gmake - found
===>   help2man-1.47.7 depends on package: perl5>=5.26<5.27 - found
===>  Configuring for help2man-1.47.7
env: ./configure: No such file or directory
===>  Script "configure" failed unexpectedly.
Please report the problem to sunpoet@FreeBSD.org [maintainer] and attach the
"/usr/obj/usr/ports/misc/help2man/work/help2man-1.47.7/config.log" including
the output of the failure of your make command. Also, it might be a good idea
to provide an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/misc/help2man
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/print/texinfo
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/devel/libtool
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/devel/libuv
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/www/node6
*** Error code 1

Stop.
make: stopped in /usr/ports/net-mgmt/statsd
Obviously, the ports tree seems not to be up to date to the current version of the freebsd Version of the Opnsense and some dependencies are not possible to be resolved/built. Prior to any further telegraf testing, a fix would be required.

Br br

117

18.7 Legacy Series / Re: telegraf feature request

« on: October 08, 2018, 09:29:18 pm »

Hi,

here some more feedback. Expanding some more features might be worth to consider some security implications

Code: [Select]

[[inputs.ipmi_sensor]]
servers = ["<ADMIN_USER>:<password>@lan(192.168.1.X)"]
works basically if the user telegraph is made belonging to group 'operator', otherwise /dev/ipmi0 can not be opened. Indeed, full ipmi_tool installation including kernelmodules need to be there. Could be a security issue.

Code: [Select]

[[inputs.pf]]requires access to /dev/pf and user telegraf need to belong to group 'proxy' too; also worth a security consideration

Code: [Select]

[[inputs.netstat]]needs command lsof which is in /usr/ports but requires kernel sources to compile; perhaps worth to consider to make lsof integral part of the standard installation. Might be that additional topics pop up after lsof has been installed.

Code: [Select]

[[inputs.unbound]]
## If running as a restricted user you can prepend sudo for additional access:
#use_sudo = false

## The default location of the unbound-control binary can be overridden with:
binary = "/usr/local/sbin/unbound-control"

## The default timeout of 1s can be overriden with:
timeout = "1s"

## Use the builtin fielddrop/fieldpass telegraf filters in order to keep/remove specific fields
fieldpass = ["total_*", "num_*","time_up", "mem_*"]
This requires enablement of usage of /usr/local/sbin/unbound-control to work in the unbound config. Did not have the time to get this up as certificates for client and server need to work properly but should be feasible basically. (Was not couragous enough to run unbound-control-setup  and to put my running config at risk on my productive system ....)
There are some comments in the fora recommending not to enable unbound-control on a primary firewall installation.

All telegraf functions relying on /proc (eg /proc/CPUinfo) are likely to fail as freebsd proc has a widely smaller structure compared to Linux

Br br

118

18.7 Legacy Series / Re: telegraf feature request

« on: October 07, 2018, 06:06:17 pm »

Yea, at least partly - will do when I'm back

119

18.7 Legacy Series / Re: telegraf feature request

« on: October 07, 2018, 05:52:00 pm »

Good point - If I may also come up with a wishlist:

[[inputs.conntrack]] (if feasible on freebsd)

[[inputs.swap]]

[[inputs.hddtemp]]

[[inputs.ipmi_sensor]]

[[inputs.netstat]]

 [[inputs.nginx]]

 [[inputs.pf]]

[[inputs.smart]]

[[inputs.sysstat]] (if supported by freebsd)

[[inputs.unbound]]

[[inputs.zfs]]

Some of those need indeed some extension of the freebsd system packages also for OPNsense, which today might not be there to keep it small; but for professional use this might be worth thinking ....

Br br

120

18.7 Legacy Series / Re: Upgrade to 18.7.4: telegraf plugin broken?

« on: October 02, 2018, 10:33:41 am »

Thanks, thats great!

Br br