Messages

1

20.1 Legacy Series / Re: IPSEC tunnel config changes Opnsense host IP in /etc/hosts

« on: May 15, 2020, 02:40:14 pm »

So to be more precise... the change is happening on reboot. Looking at system.inc I think it probably relates to the order into which the interfaces returned by get_configured_interface_with_descr() are sorted by sort().

Any suggestions for more information I can provide do please let me know.

Charlie

2

20.1 Legacy Series / IPSEC tunnel config changes Opnsense host IP in /etc/hosts

« on: May 15, 2020, 02:04:51 am »

Hello. I hope everyone is safe and well at this troubling time. I'm so grateful for the functionality of Opnsense, thank you.

So this seems like a weird one to me but I cannot figure out how to stop it happening.

I have a LAN on 10.23.21.0/24 and a routed IPSEC tunnel into Azure. The tunnel IPs are 10.111.1.1 locally and 10.111.1.2 at the Azure end.

Opnsense is configured on the LAN as 10.23.21.1 and of course that's what I'd like opnsense locally to ping.

After adding the IPSEC tunnel recently though I became aware that suddenly the opnsense hostname was resolving to clients on the LAN as 10.111.1.1 (the IP of the local IPSEC tunnel end). Disabling the phase 2 IPSEC configuration returns things to normal.

After fiddling I finally found that the opnsense IP address is being changed in /etc/hosts. This doesn't seem right to me. For now I have used an override in DNSmasq to get local clients resolving opnsense to 10.23.21.1 again but really I'd like to get /ets/hosts back to normal.

Thanks so much and sorry if this is a dumb question or I've missed out something you need to know,
Charlie

3

17.7 Legacy Series / Aliases not loaded on reboot?

« on: January 18, 2018, 11:35:26 pm »

Hello. I'm still getting to know OPNsense but enjoying so doing.

I set up some policy based routing to send traffic to certain networks over an OpenVPN tunnel. For ease these networks are defined in an alias.

I updated to 17.7.12 today and I noticed that after a reboot these rules don't work. Everything looks OK in pfTables and looking at the rules in pfInfo but nothing goes out over the tunnel. However when I view the alias in question in the GUI and save it... everything starts working again. It's like the alias (which is a list of networks in CIDR notation) is empty until this refresh is done.

I notice also that using the command prompt option 11 to reload all services will also make things start working without needing to touch the alias in the GUI.

Could the aliases be being populated too late in the restart process or something? Just a thought.

Thanks
Charlie

4

17.7 Legacy Series / Re: Unable to update from UI and (very) slowly from cli

« on: January 15, 2018, 12:11:05 am »

Hello. New user here. I have the issue described above with 17.7.11.

I tried the suggestion of switching prefer IPv4 on and it didn't help. It would seem to work briefly on reboot/restarting the services but then break again. This got me thinking... what starts later in the boot/restart process?

Do you by any chance use OpenDNS and sign in to it though Services/OpenDNS? This adds IPv6 OpenDNS nameservers in /etc/resolv.conf *before* the IPv4 ones. I have found that disabling the signin to OpenDNS and and just manually putting only the IPv4 OpenDNS nameservers in System/Settings resolves the issue for me. I have not tried reenabling it and manually changing the order of the nameservers in /etc/resolv.conf to put the IPv6 ones last but I will when I get a chance.

Loving the project by the way. Really great work. Thanks.

Charlie