Topics

1

24.1 Legacy Series / SOLVED: Unbound: Using TLD test. internally and Unbound as caching DNS

« on: April 12, 2024, 05:48:38 pm »

Hi,
we use the .test domain internally configured on four Bind DNS servers.

A nslookup using one of those is successful:

Code: [Select]

PS C:\Users\admin> nslookup m.s.test 10.20.30.254
Server:  controlnode02.muc.contoso.com
Address:  10.20.30.254

Name:    test01.node.dev.contoso.com
Address:  10.31.9.23
Aliases:  m.s.test

PS C:\Users\admin>

The OPNsense unbound uses all four Bind servers as forward servers, but the nslookup is not successful

Code: [Select]

PS C:\Users\admin> nslookup m.s.test 10.20.30.1
Server:  UnKnown
Address:  10.20.30.1

*** m.s.test wurde von UnKnown nicht gefunden: Non-existent domain.
PS C:\Users\admin>

Switching back to DNSmasq it just works:

Code: [Select]

PS C:\Users\admin> nslookup m.s.test 10.20.30.1
Server:  private-access.muc-fw01.contoso.com
Address:  10.20.30.1

Name:    test01.node.dev.contoso.com
Address:  10.31.9.23
Aliases:  m.s.test

PS C:\Users\admin>

How can I enable the .test domain for unbound?

Already tried with "Private Domains" and  "Insecure Domains" on the Advanced tab - did not help...

Thanks
Rainerle

2

High availability / HA : Virtual IP : IPv4/IPv6 : IPsec VPN client wants to connect to backup device

« on: May 20, 2022, 05:16:59 pm »

Hi,

following setup:


- On both HA partners I have VPN IPsec activated.
- Client from the WAN interface is able to connect using IPv4 and IPv6 address of the vpn services domain name
- Client from the LAN interface is able to connect using IPv4
- Client from the LAN interface connecting using the IPv6 address is able to connect, but no network services within the VPN are available.

After looking around I saw that the LAN client is connecting to the running IPsec service on the backup firewall.

Pinging the VPN domain name from the LAN client get resolved to the IPv6 virtual IP address, but the connection to the VPN service is established to the backup firewall... 

3

20.7 Legacy Series / [SOLVED] VPN : IPsec : IPv6 : Roadwarrior : Connect works but no traffic

« on: August 22, 2020, 01:15:03 am »

Hi,
we are currently adding IPv6 to our system setup as more and more of our users are upgrading their cable network data rates and are forced DS-Lite upon.

I went through the following steps:
- Add IPv6 to Interfaces and Virtual IPs
- Add IPv6 to IPsec server settings, pools and tunneled networks
- Add IPv6 IPsec pool addresses to firewall aliases, so the rules continue to work

Now I am facing the following problem:
I override the IPv4 address of the VPN DNS FQDN using the hosts file and try to connect via IPv6 to the VPN service. The connection gets established, the route print command looks fine but no traffic is passing. I am not able to ping IPv4 and IPv6 addresses behind the VPN.
When connecting to the VPN with the IPv4 address it works as expected, I am able to connect to services behind the VPN using IPv4 and IPv6 addresses.

The only obvious log entry difference is this:

Code: [Select]

Aug 21 22:34:15 opnsense01 charon: 05[IKE] <mobile-ops|6> peer requested virtual IP %any
Aug 21 22:34:15 opnsense01 charon: 05[CFG] <mobile-ops|6> reassigning offline lease to 'user'
Aug 21 22:34:15 opnsense01 charon: 05[IKE] <mobile-ops|6> assigning virtual IP 10.20.35.33 to peer 'user'
Aug 21 22:34:15 opnsense01 charon: 05[IKE] <mobile-ops|6> peer requested virtual IP 1:2:3:8001::1
Aug 21 22:34:15 opnsense01 charon: 05[CFG] <mobile-ops|6> reassigning offline lease to 'user'
Aug 21 22:34:15 opnsense01 charon: 05[IKE] <mobile-ops|6> assigning virtual IP 1:2:3:8001::1 to peer 'user'
Aug 21 22:34:15 opnsense01 charon: 05[CFG] <mobile-ops|6> selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
Aug 21 22:34:15 opnsense01 charon: 05[KNL] <mobile-ops|6> adding PF_ROUTE route failed: Invalid argument
Aug 21 22:34:15 opnsense01 charon: 05[KNL] <mobile-ops|6> installing route failed: 10.20.35.33/32 via 1:2:3::1 src 10.11.10.11 dev ixl1
Aug 21 22:34:15 opnsense01 charon: 05[KNL] <mobile-ops|6> adding PF_ROUTE route failed: Invalid argument
Aug 21 22:34:15 opnsense01 charon: 05[KNL] <mobile-ops|6> installing route failed: 10.20.35.33/32 via 1:2:3::1 src 192.168.0.11 dev ixl1

Since IPv6 and IPv4 via the IPv4 VPN server address work but not via the IPv6 VPN server address I believe I am on the right track, but have no idea currently where to look further.

Please help
Rainer

4

20.1 Legacy Series / MS Windows 10: Always on VPN using an OPNsense as VPN server

« on: April 03, 2020, 12:26:00 am »

Hi,

for our home office users we would like to use Windows 10 Always On VPN. See here:
http://blog.tofte-it.dk/tutorial-deploy-always-on-vpn/ - This is the shortest explanation I have found compared to the Microsoft documentation.

So basically the Windows 10 Device is creating a device VPN tunnel based on a machine certificate authentication.

Is this possible with OPNsense?

Has anybody tried yet?

Best regards
Rainer

5

19.7 Legacy Series / Zabbix proxy plugin: private shared memory - Cannot allocate memory

« on: October 16, 2019, 02:31:12 pm »

Hi,

trying to migrate a dedicated Zabbix proxy to OPNsense. Startup fails with

Code: [Select]

cannot initialize database cache: cannot get private shared memory of size 536870912 for history index cache: [12] Cannot allocate memory
Zabbix Proxy Settings:

Code: [Select]

root@opnsense01:~ # cat /usr/local/etc/zabbix4/zabbix_proxy.conf
...
CacheSize=8M
HistoryCacheSize=64M
HistoryIndexCacheSize=512M
...

Above Proxy values are from the existing proxy...

What do I have to set specifically with sysctl ( /system_advanced_sysctl.php ) to get that proxy up?

Best regards
Rainer

6

19.7 Legacy Series / [SOLVED] 19.7.4: Rebooting the switch - OPNsense looses WAN connection/routing

« on: September 30, 2019, 11:43:14 pm »

Hi,

after rebooting the switch attached to the MASTER OPNsense the firewall loses its WAN connection/routing, but does not failover to the BACKUP.

Only after executing menu option 11 (Reload all services) WAN is working again.

Logfile

Code: [Select]

Sep 30 23:11:44 opnsense01 sshd[47244]: Connection closed by 10.20.30.28 port 39584 [preauth]
Sep 30 23:12:44 opnsense01 sshd[12208]: Connection closed by 10.20.30.28 port 41114 [preauth]
Sep 30 23:13:44 opnsense01 sshd[38112]: Connection closed by 10.20.30.28 port 42595 [preauth]
Sep 30 23:14:44 opnsense01 sshd[60325]: Connection closed by 10.20.30.28 port 44062 [preauth]
Sep 30 23:15:04 opnsense01 kernel: ixl0: link state changed to DOWN
Sep 30 23:15:04 opnsense01 kernel: ixl1: link state changed to DOWN
Sep 30 23:15:04 opnsense01 opnsense: /usr/local/etc/rc.linkup: Hotplug event detected for admin_port(lan) but ignoring since interface is configured with static IP (10.11.10.11 ::)
Sep 30 23:15:06 opnsense01 kernel: carp: demoted by 0 to 0 (send error 50 on lagg0_vlan3)
Sep 30 23:15:06 opnsense01 kernel: carp: demoted by 0 to 0 (send error 50 on lagg0_vlan2026)
Sep 30 23:15:06 opnsense01 kernel: carp: demoted by 0 to 0 (send error 50 on lagg0_vlan2040)
Sep 30 23:15:06 opnsense01 kernel: carp: demoted by 0 to 0 (send error 50 on lagg0_vlan30)
Sep 30 23:15:06 opnsense01 kernel: carp: demoted by 0 to 0 (send error 50 on lagg0_vlan2038)
Sep 30 23:15:06 opnsense01 kernel: carp: demoted by 0 to 0 (send error 50 on lagg0_vlan2028)
Sep 30 23:15:06 opnsense01 kernel: carp: demoted by 0 to 0 (send error 50 on lagg0_vlan2027)
Sep 30 23:15:06 opnsense01 kernel: carp: demoted by 0 to 0 (send error 50 on lagg0_vlan2020)
Sep 30 23:15:26 opnsense01 kernel: pflog0: promiscuous mode disabled
Sep 30 23:15:26 opnsense01 kernel: pflog0: promiscuous mode enabled
Sep 30 23:15:44 opnsense01 sshd[94285]: Connection closed by 10.20.30.28 port 45496 [preauth]
Sep 30 23:16:22 opnsense01 kernel: pflog0: promiscuous mode disabled
Sep 30 23:16:22 opnsense01 kernel: pflog0: promiscuous mode enabled
Sep 30 23:16:44 opnsense01 sshd[5997]: Connection closed by 10.20.30.28 port 46934 [preauth]
Sep 30 23:17:44 opnsense01 sshd[12793]: Connection closed by 10.20.30.28 port 48371 [preauth]
Sep 30 23:18:44 opnsense01 kernel: ixl0: Link is up, 10 Gbps Full Duplex, Requested FEC: None, Negotiated FEC: None, Autoneg: False, Flow Control: None
Sep 30 23:18:44 opnsense01 kernel: ixl0: link state changed to UP
Sep 30 23:18:44 opnsense01 kernel: ixl1: Link is up, 10 Gbps Full Duplex, Requested FEC: None, Negotiated FEC: None, Autoneg: False, Flow Control: None
Sep 30 23:18:44 opnsense01 kernel: ixl1: link state changed to UP
Sep 30 23:18:44 opnsense01 sshd[76502]: Connection closed by 10.20.30.28 port 49844 [preauth]
Sep 30 23:18:44 opnsense01 opnsense: /usr/local/etc/rc.linkup: Hotplug event detected for admin_port(lan) but ignoring since interface is configured with static IP (10.11.10.11 ::)
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'ixl0'
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: On (IP address: 10.11.10.11) (interface: admin_port[lan]) (real interface: ixl0).
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'lan'
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv4 default route
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: ROUTING: IPv6 default gateway set to wan
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: Removing static route for monitor 2001:4860:4860::8888 via <CARP WAN IPv6>
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: Adding static route for monitor 2001:4860:4860::8888 via <CARP WAN IPv6>
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: Removing static route for monitor 8.8.8.8 via <CARP WAN IP>
Sep 30 23:18:45 opnsense01 opnsense: /usr/local/etc/rc.newwanip: Adding static route for monitor 8.8.8.8 via <CARP WAN IP>
Sep 30 23:18:50 opnsense01 kernel: pflog0: promiscuous mode disabled
Sep 30 23:18:50 opnsense01 opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface admin_port.
Sep 30 23:18:50 opnsense01 kernel: pflog0: promiscuous mode enabled
Sep 30 23:18:57 opnsense01 kernel: pflog0: promiscuous mode disabled
Sep 30 23:18:57 opnsense01 kernel: pflog0: promiscuous mode enabled
Sep 30 23:19:02 opnsense01 kernel: pflog0: promiscuous mode disabled
Sep 30 23:19:02 opnsense01 kernel: pflog0: promiscuous mode enabled
Sep 30 23:19:07 opnsense01 kernel: pflog0: promiscuous mode disabled
Sep 30 23:19:07 opnsense01 kernel: pflog0: promiscuous mode enabled
Sep 30 23:19:24 opnsense01 kernel: pflog0: promiscuous mode disabled

ixl0 is a access port attached on that rebooted switch, ixl1 is the LACP lagg port attached to that same switch. The second switch stays alive and takes over operation during the reboot of switch 1. WAN connection fails as soon as the rebooted switch comes up again.

No idea how to go from here...

7

19.7 Legacy Series / 19.7.4: After HA failover mobile IPsec users stay connected to the now backup FW

« on: September 16, 2019, 10:35:09 am »

Hi,

after a few failovers I realised that a via IPsec connected users (with MOBIKE enabled) stays connected to the firewall he initially connected to. The connection itself becomes unusable since the routing is not working anymore, but the VPN client does not reconnect to the new master HA device.

If one of the firewall reboots the client reconnects properly. Above scenario is only valid if the failover is triggered by disabling the CARP interfaces in /carp_status.php .

Is there already an existing best practise/work around for this? From my point of view a CARP failover should trigger service restarts on the old master HA device...

8

19.7 Legacy Series / [Solved] 19.7.3: Fallback to Master HA member not working

« on: September 06, 2019, 05:50:54 pm »

Hi,

after upgrading the Master HA member and a final reboot I clicked "Leave Persistent CARP Maintenance Mode". The Backup HA member would still be Master.

Checking on the WebIF I could see that adskew on the Backup would be 100 and on the Master 0 for all the VHIDs. On the status page the Master showed for "Current CARP demotion level" 0 and on the Backup 0 as well.

Looking on the CLI:
Master:
ixl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 7c:d3:0a:d8:34:a0
        hwaddr 7c:d3:0a:d8:34:a0
        inet 10.20.38.41 netmask 0xffffff00 broadcast 10.20.38.255
        inet 10.20.38.1 netmask 0xffffff00 broadcast 10.20.38.255 vhid 1
        inet6 fe80::7ed3:aff:fed8:34a0%ixl0 prefixlen 64 scopeid 0x1
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect (10Gbase-Twinax <full-duplex>)
        status: active
        carp: BACKUP vhid 1 advbase 1 advskew 254
...

After clicking "Temporarily Disable CARP" and then "Enable CARP" on the Master it just failed back.

After clicking "Temporarily Disable CARP" and then "Enable CARP" on the Backup it stayed on the Master.

Now the Master shows:
WebIF: Current CARP demotion level: -240
CLI: carp: MASTER vhid 1 advbase 1 advskew 0

And the Backup:
WebIF: Current CARP demotion level: 0
CLI: carp: MASTER vhid 1 advbase 1 advskew 0
carp: BACKUP vhid 1 advbase 1 advskew 100

No idea if this is reproducable...

9

19.7 Legacy Series / [Solved] 19.7.3: GeoIP based firewall rules on the secondary HA partner broken

« on: September 04, 2019, 06:41:51 pm »

Hi,

as suggested I open a separate thread for above mentioned problem.

During a HA take over services on the BACKUP HA partner are not available since the GeoIP based firewall rules block them.

Running the following scripts on the CLI
/usr/local/opnsense/scripts/filter/download_geoip.py
/usr/local/etc/rc.filter_synchronize
/usr/local/etc/rc.filter_configure

The GeoIP DB files under /usr/local/share/GeoIP/alias are updated but the rules still allow no access to the service.

Adjusting the rules by changing from GeoIP to any restores access to the service. So I am sure it is related to the GeoIP based rule.

Thanks
Rainer

10

Tutorials and FAQs / system.log and dmesg full of "kernel: arp: <MAC> is multicast" spam

« on: July 26, 2019, 04:31:18 pm »

Hi,

the system.log and dmesg were full with "kernel: arp: <some MAC address> is multicast" messages and hence unusable.

By adding "net.link.ether.inet.allow_multicast" and setting the value to 1 in System->Settings->Tunables we were able to get rid of that.

All the best
Rainer

11

19.7 Legacy Series / [Solved] After upgrade to 19.7 routing over IPsec tunnels seems broken

« on: July 23, 2019, 05:07:10 pm »

Hi,

just upgraded today.

After applying the following patches
fabaef0a 6b1f3e60 9287b55 64858b5

I still have the problem that routing from devices within the network over a VTI (ipsec1000) does not work.

Ping from opnsense01 does work and the tunnel is up.

Clients on the same location as the opnsense are not able to ping. The traceroute shows the client is trying to connect via the opnsense but then just stars out.

Now I tried to downgrade to 19.1.10

root@opnsense02:~ # opnsense-update -u -r 19.1.10
Fetching packages-19.1.10-OpenSSL-amd64.tar: .. failed, no signature found
root@opnsense02:~ #

How do I properly downgrade a complete release?

12

19.1 Legacy Series / Network Insight: No further new data in the graphs

« on: May 31, 2019, 04:30:37 pm »

Hi,

I just looked into Network Insight ( /ui/diagnostics/networkinsight ) and the graph and pie charts do not contain any new data. It stopped at around 10:00 after about 6 days uptime (see attachment).

Any idea where to look for errors? How to fix that?

Thanks and best regards
Rainer

13

Tutorials and FAQs / HOWTO:IPsec IKEv2 clients: Split tunnel / EAP Radius / Virtual IP pool per group

« on: March 21, 2019, 04:21:10 pm »

Hi everybody,

we are live - since 14 Mar 2019 - with our HA OPNsense 19.1.4 setup. Now I wanted to share our specific IPsec IKEv2 mobile client setup. It works for IPv4 and IPv6 .

Our requirements:
- VPN login using accounts maintained already in a Radius server.
- No installation of additional software on the clients.
- No installation of certificates on the clients - all the user has to know is his user ID and password.
- Separate IP pools per user group. Access rights to some systems on our network are based on addresses of these IP pools.
- Split tunneling for internal and external IP addresses. External since some partners only allow access using our firewalls uplink IP address.
- Split DNS since we maintain internal DNS domains.
- Allow more than one connection per user ID for users (Laptop and mobile phone concurrent use...)

Since 24.1.8 we are able to maintain this using the WebGUI and are based on this documentation https://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html

Previous configurations up to 22.7.11:

Since 19.1.7 we are able to maintain a file based IPsec configuration using StrongSwan include files.

So how does it look like in short:
- Create a Let's Encrypt Server certificate for the IPsec responder FQDN (vpn.contoso.com) with A and AAAA DNS entry
- Configure VPN->IPsec->Mobile Client using a Radius server as backend, create phase 1 using EAP-RADIUS and then create one IPv4 and one IPv6 phase 2 default tunnel. This is then used by "also" in separate include.d configurations.
- Create a Phase1 per Radius class (which is the group) using an include file
- Create multiple Phase2 per Phase1 for the split tunneling using an include file
- Configure the StrongSwan Radius plugin to use the class_group using an include file (https://wiki.strongswan.org/projects/strongswan/wiki/EAPRadius#Group-selection )


OPNsense Configuration:

To let the clients know about the Split DNS we configured "DNS Default Domain", "Split DNS" and "DNS Servers" in VPN->IPsec->Mobile Clients.

I include our config files and the generated IPsec config files. The external IP addresses have been replaced with some other IPs. The domain names are replaced as well.


Client Configuration:
Windows 10:

I attached the PowerShell script we use to configure our Windows 10 clients. It is copied using a robocopy computer group policy script and then executed everytime the user logs onto the laptop using a user GPO.

Apple Devices (MacOS and iOS):

Since 19.1.5 the Clients just have to configure a IKEv2 VPN with vpn.contoso.com as Server and Remote ID and pass their User ID and Password. Split tunnel and DNS are configured automatically from the Responders IKEv2 payload.
There are two bugs though:
- The split DNS domain names are added automagically to the DNS search suffixes.
- DNS A records are resolved properly with the Split DNS server. DNS SRV records are not (see https://communities.apple.com/de/thread/250249906 ).

Android Devices:

Install the StrongSwan App, configure and you are good to go!
https://play.google.com/store/apps/details?id=org.strongswan.android

Linux clients:

Until I found a long outstanding bug in the Ubuntu LTS version I could not get them to work. See https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1772705 .

But then it is fairly simple:
- sudo apt install network-manager-strongswan libstrongswan-standard-plugins libcharon-standard-plugins libstrongswan-extra-plugins libcharon-extra-plugins dnsmasq
- Configure IKEv2 VPN in Network Manager using EAP. Tick "assign internal IP" and give user name and password.
- Split DNS (use dnsmasq as local DNS server and set specific DNS server per DNS domain name)
  - Disable dnsmasq starting as a system service (systemctl disable dnsmasq)
  - Add "dns=dnsmasq" in the main section in /etc/NetworkManager/NetworkManager.conf
  - Add "server=/internal.contoso.com/10.20.30.1" in /etc/NetworkManager/dnsmasq.d/contoso-vpn.conf. Do so for all further internal DNS domain names.
- pkill -9 charon-nm if there is IPsec plugin trouble (sudo journalctl -f during VPN connect is your friend...)

Chromebooks:
No solution yet. Split tunnel and split DNS seem not to work using the StrongSwan Android App.

Best for now to star https://bugs.chromium.org/p/chromium/issues/detail?id=715622 .

Updated on 24.8.2020 to use the web interface for most and only adjust to use Radius-EAP's rightgroups group assignment. As well IPv4 and IPv6 are working now - the VPN responder FQDN needs an A and AAAA DNS entry.

14

19.1 Legacy Series / Everybody can help: Push for Chromebook VPN IPsec IKEv2 integration

« on: March 21, 2019, 01:27:49 pm »

Hi everybody,

finally you can now use your Google accounts to do something useful: Let's push the issue for the ChromeOS native inclusion of IPsec IKEv2!

All you have to do is go to https://bugs.chromium.org/p/chromium/issues/detail?id=715622 ,
sign in on the right with your google account and click on the star on the left side.

Let's see the number of stars rise!!!

All the Best and Thanks
Rainer

15

German - Deutsch / [SOLVED] VPN IPsec Mobile Clients: User in separate Virtual Address Pools

« on: February 28, 2019, 05:45:27 pm »

Hallo zusammen!

Ich habe hier folgendes vor:
- Drei Benutzergruppen (ADMIN,DEV,USER)
- Alle haben VPN Zugriff über dasselbe IPsec IKEv2
- Anhand der zugewiesenen IP Adresse des Virtual Address Pools dürfen sie per Regel in bestimmte Netze und zu bestimmten Applikationen

Die Benutzer sind auf einem Radius Server.

Mir fällt mit der OPNsense GUI keine offensichtliche Lösung für mein Problem ein...

Hat sowas schon mal jemand gemacht?

Besten Gruß
Rainer