Messages

16

21.7 Legacy Series / QEMU-Guest-Agent causes lots of zombie-processes, OPNSense stalls

« on: November 21, 2021, 11:30:57 pm »

Im running half a dozen virtual OPNSense Gateways (21.7.4) under oVirt using QEMU-Guest-Agent.
The plugin qemu-ga became available within the 21.1 release.

After roughly 60 days without reboot these gateways stall, the Web-GUI as well as the console show "cannot fork" errors and it is impossible to login via console or ssh.

To find the culprit I had the smart idea, to reboot an affected OPNSense gateway from oVirt using qemu-ga and did a

Code: [Select]

ssh root@mygateway ps uxawj
very quickly during reboot to show the process list.

There were several thousand zombie-processes starting at various dates with PPID 8995

Code: [Select]

...
root 182 0.0 0.0 0 0 - Z Fri05 0:00.01 <defunct> 8995 8995 8995 0
root 192 0.0 0.0 0 0 - Z 4Nov21 0:00.00 <defunct> 8995 8995 8995 0
root 215 0.0 0.0 0 0 - Z Fri04 0:00.00 <defunct> 8995 8995 8995 0
root 249 0.0 0.0 0 0 - Z 13Nov21 0:00.00 <defunct> 8995 8995 8995 0
root 253 0.0 0.0 0 0 - Z 3Nov21 0:00.00 <defunct> 8995 8995 8995 0
...

Luckily the process with PID 8995 was still alive

Code: [Select]

root 8995 0.0 0.4 17236 4052 - Ss 29Oct21 2:48.09 /usr/local/bin/q 1 8995 8995 0

The output is truncated, but on this OPNSense the only binary beginning with "q" in /usr/local/bin is qemu-ga.
I think, the problem is described for FreeBSD on GitHub

https://github.com/aborche/qemu-guest-agent/issues/17

and there already seems to be a fix for it

https://github.com/aborche/qemu-guest-agent/commit/71edc56b1476bf6c45d1d461bbfa9fe987a8974e

Unfortunately this fix hasn't made it into FreeBSD and therefore in OPNSense yet.
I was able to fix the problem for me by disabling the guest-get-fsinfo RPC call in OPNSense configuration, see attachment.

Just in case, if somebody else is running into the same problem

17

German - Deutsch / Re: WAN und LAN im gleichen Netz + Openvpn

« on: October 28, 2021, 10:36:56 pm »

Ungewöhnliche Konfiguration, aber ich denke korrekt wäre in dem Fall

LAN 192.168.90.2 / Gateway 192.168.90.1

unter System -> Gateways ein Gateway für die LAN Schnittstelle einrichten und das WAN Interface einfach deaktivieren.

Noch nie probiert, sollte aber klappen

18

21.7 Legacy Series / Re: Configure the virtual ip for a pc

« on: October 08, 2021, 01:02:32 am »

Let's assume you are using IPv4 and your desired virtual WAN IP is 42.1.2.3/32 and your PC is 192.168.1.1/24.

• First create an IP Alias in Interfaces->Virtual IP's->Settings using WAN as interface and 82.1.2.3/3 as address.
  
• The goto Firewall->NAT->Outbound and switch to Hybrid or Manual Mode whatever suits your needs better.
• Create a new rule using WAN as interface, 192.168.1.1/32 as source, the previously created IP Alias 42.1.2.3/32 as Translation/Target and IPv4/any as protocol.
  

To get a more readable configuration I would first set up Aliases under Firewall->Aliases for 42.1.2.3/32 and 192.168.1.1/32 and use them in the NAT rule instead of IP adresses

19

Virtual private networks / Re: What do I need to allow traffic from LAN through OpenVPN client connection?

« on: September 28, 2021, 05:34:40 pm »

To make this work you have to setup a new interface in Interfaces->Assignment using ovpnc2 as "Network port".
After that you should be able to configure NAT in Firewall->NAT->Outbound for this newly generated interface.

When using several OpenVPN Client Connections this is a bit tedious 
You are perfectly right, there should be a setting for outgoing NAT in OpenVPN client settings.

We solved this several months ago with a quick and dirty patch enabling outgoing IPv4 and IPv6 NAT for all OpenVPN Client connections, which is not the correct way to do this

20

General Discussion / Re: How to clear interface rule counters

« on: June 26, 2021, 07:24:35 pm »

How about clicking Firewall -> Aliases -> Apply ?

According to the explanation found under Firewall -> Diagnostics -> States Reset this should leave the state tables intact and for me it does reset the inspect counters 

21

German - Deutsch / Re: UnBound DNS Problem mit web.impfnachweis.info

« on: June 26, 2021, 06:38:43 pm »

Das Problem wurde im englischen Forum bereits gelöst.

Die Adresse 100.102.17.10 ist eine Carrier-Grade-NAT Adresse und die fallen offenbar für UnBound neuerdings zusätzlich zu RFC1918 Adressen unter "privat". Die Lösung ist also, impfnachweis.info unter Dienste -> Unbound-DNS -> Verschiedenes als private Domain einzutragen, sonst macht die DNS Rebind-Protection die Antwort tot.

Nur falls jemand über das gleiche Problem stolpert

22

21.1 Legacy Series / Re: Strange UnBound DNS problem with web.impfnachweis.info

« on: June 26, 2021, 06:31:57 pm »

That was quick and it does help 
Entering impfnachweis.info as private domain fixes the problem.

Just because I'm curious: Has the behaviour regarding the treatment of carrier grade NAT addresses in Unbound changed recently ?

23

German - Deutsch / [gelöst] UnBound DNS Problem mit web.impfnachweis.info

« on: June 26, 2021, 06:18:22 pm »

Die DNS Adresse web.impfnachweis.info wird aktuell von deutschen Arztpraxen zum Ausstellen digitaler Covid19 Impfzertifikate verwendet.
Über Public Nameserver (getestet mit 1.1.1.1, 8.8.8.8 und 9.9.9.9) ist die Adresse problemlos auflösbar:

Code: [Select]

me@laptop02 ~
$ host web.impfnachweis.info 9.9.9.9
Using domain server:
Name: 9.9.9.9
Address: 9.9.9.9#53
Aliases:

web.impfnachweis.info has address 100.102.17.10

Ich hatte gerade bei einem Kunden das Problem, dass die Adresse von seinem OPNSense Gateway nicht aufgelöst wurde und habe ein wenig getestet:

• UnBound auf OPNSense >=21.1.6 löst die Adresse nicht auf, getestet auf 4 Gateways
• Unbound auf OPNSense <= 21.1.2 löst die Adresse korrekt auf, getestet auf einem Gateway
• DNSSEC abzuschalten, macht's nicht besser

Es geht nur um die DNS Auflösung, die Website https://web.impfnachweis.info ist dann nur aus der Arztpraxis via VPN über die Telematik Infrastruktur erreichbar.

Ich habe das Problem bereits im englischen Forum unter https://forum.opnsense.org/index.php?topic=23694.0 gepostet und frag jetzt hier nochmal nach, weils ein "typisch deutsches" Problem ist 

Mein Hotfix ist bisher, einen Override für impfnachweis.info zeigend auf einen Public DND Server zu setzen, das funktioniert.
Hat jemand das gleiche Problem beobachtet und vielleicht eine Lösung ?

24

21.1 Legacy Series / Strange UnBound DNS problem with web.impfnachweis.info

« on: June 26, 2021, 05:24:40 pm »

I just stumbled across a strange DNS problem probably related to UnBound DNS.

A customer has to resolve web.impfnachweis.info, which is used by physicians in Germany to issue digital Covid19 vaccination certificates.

The address resolves fine using public DNS servers

Code: [Select]

me@laptop02 ~
$ host web.impfnachweis.info 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

web.impfnachweis.info has address 100.102.17.10

(same result for 1.1.1.1 and 9.9.9.9)

For some reasons it does not resolve using UnBound on OPNSense 21.1.6 (tested on three different gateways)

Code: [Select]

me@laptop02 ~
$ host web.impfnachweis.info 10.42.1.1
Using domain server:
Name: 10.42.1.1
Address: 10.42.1.1#53
Aliases:

whereas it does on UnBound still using OPNSense 21.1.2

Code: [Select]

me@laptop02 ~
$ host web.impfnachweis.info 10.70.71.254
Using domain server:
Name: 10.70.71.254
Address: 10.70.71.254#53
Aliases:

web.impfnachweis.info has address 100.102.17.10

So far I have tried to restart UnBound, disabled DNSSEC on the affected gateways and increased the Log Level with no effect and no further insight what is happening.
Upgrading one of the affected gateways to OPNSense 21.1.7_1 did also not solve the problem.

The problem can easily be solved by defining an override for impfnachweis.info pointing to a public DNS server, but I would be very interested in what is happening here.

Has anybody experienced this and can provide an explanation ?

25

21.1 Legacy Series / Re: IPsec Stealing Traffic.

« on: June 23, 2021, 11:23:22 pm »

I think entering 10.14.182.0/24 under VPN -> IPSEC -> Advanced Settings -> Passthrough networks should do the trick

26

21.1 Legacy Series / Re: IPv6 from WAN to LAN

« on: May 04, 2021, 09:45:05 pm »

Firewall rules (on WAN) should be sufficient, provided your IPv6 is set up correctly and there is no other router between your OPNsense and the internet, blocking traffic.
Perhaps you should provide a little more information 

27

21.1 Legacy Series / Re: IPv6 IPSEC tunnel does not pass data in NAT-T mode

« on: May 03, 2021, 09:50:46 am »

I have tested with a Windows10 mobile client, what you describe for Linux client:

The OPNsense box used for testing has only an AAAA DNS entry and a IPSEC mobile client using EAP Radius set up.

Connecting from Windows works fine, when looking at "VPN: IPsec: Security Association Database" ESP transport ist used for the mobile connection. Data flow accross the tunnel is fine for IPv6 and IPv4.

When forcing NAT-T by setting "Nat Traversal" to "Force" on the OPNSense side the Windows Client also connects successfully, but pings accross the tunnel wont work.

So I would agree to

It looks like IPv6 IPsec with NAT-T enabled is broken

testing with 21.1.4

28

21.1 Legacy Series / Re: IPv6 IPSEC tunnel does not pass data in NAT-T mode

« on: May 01, 2021, 09:26:50 pm »

Can you please share the link to the github ticket? Thanks.

https://github.com/opnsense/core/issues/4862

29

Virtual private networks / Re: Purpose of CA when running OpenVPN with User Auth only?

« on: April 30, 2021, 05:48:37 pm »

But then what about the "Peer Certificate Authority"? Since we're not using client keys, the peers shouldn't be presenting any client certificates at all, or am I misunderstanding something?

The "Peer Certificate Authority" in your setup is the one that has issued the server certificate.
It is not used by the server itself (as there are no client certificates) but included in the client config file when you export one using "VPN->OpenVPN->Client Export". Therefore it is selectable in server configuration.

30

Virtual private networks / Re: OpenVPN server & OpenVPN Connect problem

« on: April 29, 2021, 06:24:31 pm »

The generated config file should contain something like

Code: [Select]

...
<ca>
-----BEGIN CERTIFICATE-----
{your ca cert}
-----END CERTIFICATE-----
</ca>
..
<cert>
-----BEGIN CERTIFICATE-----
{your client cert}
-----END CERTIFICATE-----
</cert>
...
<key>
-----BEGIN PRIVATE KEY-----
{your client key}
-----END PRIVATE KEY-----
</key>
..

Are the sections <ca>, <cert> and <key> filled correctly ?

If you are not using client certs you might want to add

Code: [Select]

client-cert-not-required

under "Custom Config" before exporting, see

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