Messages

1

22.7 Legacy Series / HA stange after upgrade from 22.1.10 to 22.7

« on: August 04, 2022, 02:22:25 am »

Hi,

Previously my HA was working fine. My fast main OPNsense VM was always the master (CARP set to "freq. 1 / 0") and my slow secondary OPNsense VM always the slave (CARP set to "freq. 1 / 100"). In case I had shutdown my main OPNsense the secondary got the new master within seconds and as soon as the main OPNsense was online again it instantly switched back.

Now I got the case that it needs 2 minutes until the secondary OPNsense will notice that the main OPNsense is offline to become the new master. And if the main OPNsense is online again it will still be the slave. It takes around 10 to 20 minutes until the main OPNsense become the master again. Only way to get my main OPNsense get to be the master faster is to reboot the secondary OPNsense so it gives the master role back to the main OPNsense.

So something is strange there. They somehow see each other but everything is very slow.

Someone knows how to find out what could be the problem?

Code: [Select]

2022-08-04T02:13:48 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual WAN IP (192.168.0.4).
2022-08-04T02:13:48 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual WAN IP (192.168.0.4) (1@vtnet1)" has resumed the state "BACKUP" for vhid 1
2022-08-04T02:13:48 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual IOT IP (192.168.50.1).
2022-08-04T02:13:48 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual IOT IP (192.168.50.1) (11@vtnet8)" has resumed the state "BACKUP" for vhid 11
2022-08-04T02:13:48 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual FFLAN IP (192.168.47.4).
2022-08-04T02:13:48 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual FFLAN IP (192.168.47.4) (7@vtnet7)" has resumed the state "BACKUP" for vhid 7
2022-08-04T02:13:48 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual TOR IP (192.168.46.4).
2022-08-04T02:13:48 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual TOR IP (192.168.46.4) (15@vtnet6)" has resumed the state "BACKUP" for vhid 15
2022-08-04T02:13:47 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual LAN IP (192.168.43.1).
2022-08-04T02:13:47 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual LAN IP (192.168.43.1) (3@vtnet4)" has resumed the state "BACKUP" for vhid 3
2022-08-04T02:13:47 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual RETRO IP (192.168.41.1).
2022-08-04T02:13:47 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual RETRO IP (192.168.41.1) (13@vtnet2)" has resumed the state "BACKUP" for vhid 13
2022-08-04T02:13:47 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual GUEST IP (192.168.44.1).
2022-08-04T02:13:47 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual GUEST IP (192.168.44.1) (9@vtnet5)" has resumed the state "BACKUP" for vhid 9
2022-08-04T02:13:47 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual DMZ IP (192.168.42.1).
2022-08-04T02:13:47 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual DMZ IP (192.168.42.1) (5@vtnet3)" has resumed the state "BACKUP" for vhid 5
2022-08-04T02:03:15 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual WAN IP (192.168.0.4).
2022-08-04T02:03:15 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual WAN IP (192.168.0.4) (1@vtnet1)" has resumed the state "MASTER" for vhid 1
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual FFLAN IP (192.168.47.4).
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual FFLAN IP (192.168.47.4) (7@vtnet7)" has resumed the state "MASTER" for vhid 7
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual FFLAN IP (192.168.47.4) (7@vtnet7)" has resumed the state "MASTER" for vhid 7
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual TOR IP (192.168.46.4).
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual TOR IP (192.168.46.4) (15@vtnet6)" has resumed the state "MASTER" for vhid 15
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual GUEST IP (192.168.44.1).
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual GUEST IP (192.168.44.1) (9@vtnet5)" has resumed the state "MASTER" for vhid 9
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual LAN IP (192.168.43.1).
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual LAN IP (192.168.43.1) (3@vtnet4)" has resumed the state "MASTER" for vhid 3
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual DMZ IP (192.168.42.1).
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual DMZ IP (192.168.42.1) (5@vtnet3)" has resumed the state "MASTER" for vhid 5
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual RETRO IP (192.168.41.1).
2022-08-04T02:03:14 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual RETRO IP (192.168.41.1) (13@vtnet2)" has resumed the state "MASTER" for vhid 13
2022-08-04T02:03:13 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Resyncing OpenVPN instances for interface Virtual IOT IP (192.168.50.1).
2022-08-04T02:03:13 Error opnsense /usr/local/etc/rc.syshook.d/carp/20-openvpn: Carp cluster member "Virtual IOT IP (192.168.50.1) (11@vtnet8)" has resumed the state "MASTER" for vhid 11
2022-08-04T02:01:58 Error opnsense /usr/local/etc/rc.routing_configure: Removing static route for monitor 8.8.8.8 via 192.168.0.1
2022-08-04T02:01:57 Error opnsense /usr/local/etc/rc.routing_configure: ROUTING: keeping current default gateway '192.168.0.1'
2022-08-04T02:01:57 Error opnsense /usr/local/etc/rc.routing_configure: ROUTING: setting IPv4 default route to 192.168.0.1
2022-08-04T02:01:57 Error opnsense /usr/local/etc/rc.routing_configure: ROUTING: IPv4 default gateway set to wan
2022-08-04T02:01:57 Error opnsense /usr/local/etc/rc.routing_configure: ROUTING: entering configure using defaults
2022-08-04T02:01:57 Error opnsense /usr/local/etc/rc.routing_configure: Removing static route for monitor 8.8.8.8 via 192.168.0.1
2022-08-04T02:01:57 Error opnsense /usr/local/etc/rc.routing_configure: ROUTING: setting IPv4 default route to 192.168.0.1
2022-08-04T02:01:57 Error opnsense /usr/local/etc/rc.routing_configure: ROUTING: IPv4 default gateway set to wan
2022-08-04T02:01:57 Error opnsense /usr/local/etc/rc.routing_configure: ROUTING: entering configure using defaultsThis is the log of the secondary OPNsense when rebooting the main OPNsense. Took like 1-2 minutes to reboot with 12 Minutes for giving back "master" to the other OPNsense. 

2

Intrusion Detection and Prevention / Two questions regarding suricata

« on: August 03, 2022, 09:06:16 pm »

Hi,

Got suricata in IPS mode running herein the home lab. I think it is working bu two things are still not clear to me.

1.) Is there some default behavior for rules that will be used when nothing special is defnied? Because there are some rulesets that got rules for malicious events that I would like to block but also some rules just for monitoring.
Right now I got one policy with high priority that sets the action to "block" in case the action is "disabled" for specific rulesets like "drop.rules", "compromised.rules" and so on. And then I got a lower priority policy that sets all rules of all rulesets to "alert" no matter what action is set. As far as I understand this will block all rulesets that I specified in the first policy and then alert for all other rulesets which I didn't set to "block".
Do I really need to do it this way (or is there a better way) because all rules will be disbled by default or is there some reasonable default action for each rule so I could just do what the ruleset provider recommends as an action?

2.) I installed the ET Open and ET Pro Telemetry plugins. For "os-intrusion-detection-content-et-open" the comment is "IDS Proofpoint ET open ruleset complementary subset for ET Pro Telemetry edition". With that I get for example the rulesets "ET open/botcc.portgrouped" and "ET telemetry/botcc.portgrouped". Do I need both rulesets or is the more up-to-date ET Pro Telemetry enough becasue it also includes the rules of the ET Open? Not that I run the same rules twice.

3

22.1 Legacy Series / Re: Suricata only using one thread

« on: March 01, 2022, 11:19:00 am »

When Suricata is running in IPS mode, Netmap is utilized to fetch packets off the line for inspection. By default, OPNsense has configured Suricata in such a way that the packet which has passed inspection will be re-injected into the host networking stack for routing/firewalling purposes. The current Suricata/Netmap implementation limits this re-injection to one thread only. Work is underway to address this issue since the new Netmap API (V14+) is now capable of increasing this thread count. Until then, no benefit is gained from RSS when using IPS.

Do you know if OPNsense 22.1.1-3 meanwhile supports IPS with more then one thread when enableing RSS?

4

22.1 Legacy Series / Suricata only using one thread

« on: March 01, 2022, 08:38:25 am »

Hi,

There are alot of old threads here reporting that suricata only makes use of one thread and isn't multi-threading.

I see the same here. My OPNsense 22.1 is running on a Proxmox VM with 4GB RAM and 4 vCPUs of a 2.3-3GHz Xeon E5 and virtio NICs. The virtio NICs use a LACP bond of all 4 ports of my Intel i350-T4. If I start downloading with suricata IPS enabled I can only make use of 50Mbit of my 100Mbit internet connection. When I look at top it shows that only one of suricatas threads is at 100% WCPU while the other threads aren't doing much. Bascially no meter how much threads I give OPNsense, it never makes use of more then 1-2 vCPUs.

Whats preventing suricata from effectivly using more than one core?

5

22.1 Legacy Series / Re: shutdown not working after update from 21.7.8 to 22.1

« on: February 15, 2022, 01:30:34 pm »

I was thinking of exporting the config and do a clean setup from scratch in parallel to see if that fixes it.
Maybe that could be an approach for you as well?

Will test that.

What I also found out:
With 1 vCPU the VM will never shutdown (waited up to 12 hour for the shutdown to finish where the CPU utulization of the VM always stayed at 100%).
With 2 vCPUs the VM will sometimes shutdown and sometimes get stuck. CPU Utilization is then 50% until I forcefully stop the VM.
With 3 or 4 vCPUs shutting down always works.

Someone knows why a shutdown can get stuck with less than 3 vCPUs? Tested it like 30 times now and only thing that changed was the amout of vCPUs.

Increasing it to 3 or 4 vCPUs is also not a great workaround as this will increas the hosts CPU queue and the VM never utilized two full vCPUs. Was working perfectly fine and fast enough until now with just 1 vCPU.

Edit:
Shutdown also hangs after upgrading the OPNsense VM to 22.1 on the TrueNAS server with bhyve as hypervisor. And there the number of vCPUs is 3 so increasing the amount of vCPUs might not fix it always.

6

22.1 Legacy Series / Re: shutdown not working after update from 21.7.8 to 22.1

« on: February 14, 2022, 12:25:49 pm »

I also tried to stop every plugin (dnscrypt-proxy, zabbix_agentd) before stutting down but then the shutdown also hangs.

7

22.1 Legacy Series / Re: shutdown not working after update from 21.7.8 to 22.1

« on: February 12, 2022, 12:14:18 pm »

I disabled "/var RAM disk" to get logs. But this doesn't seem to help either as the shutdown is stopping syslog-ng service so there are no logs after that could tell me why the VM gets stuck wuth 100% CPU load.
I asked other people running OPNsense 22.1 in a proxmox VM and there the shutdown is working.

Any ideas?

8

22.1 Legacy Series / shutdown not working after update from 21.7.8 to 22.1

« on: February 10, 2022, 11:22:15 am »

Hi,

My OPNSenses are virtualized using KVM (one hypervised by bhyve on TrueNAS, two on ProxmoxVE).
With 21.7.8 I shut them down using the qemu-guest-agent plugin.

Now I upgraded one of the OPNsenses on the Proxmox Server to 22.1 and I'm no longer able to shutdown OPNsense. I tried it from the hypervisor using the qemu guest agent, from the hypervisor using ACPI and also directly from the OPNsense WebUI. In all cases shutting down gets stuck with 100% CPU utilization and I need to forcefully stop the VM.

Can someone point me in the right direction what could cause this or what to look for?
Looks like the logs are only stored in RAM and are lost after I kill the VM so not sure where to look for.

The attachment shows what the console is showing when shutting down.

9

21.7 Legacy Series / Re: WebUI only accessible after restarting all services

« on: November 14, 2021, 10:15:50 am »

I booted into BIOS and the RTC was already set to UTC. So any other ideas?

10

21.7 Legacy Series / WebUI only accessible after restarting all services

« on: October 25, 2021, 01:29:23 pm »

Hi,

I've got a OPNsense 21.7.3 running inside a VM (bhyve hypervisor using KVM) on my TrueNAS server.
Always when I start that VM I can't access the webUI and chrome is showing a "ERR_SSL_PROTOCOL_ERROR" error. I need to login using SSH and run "11) Reload all services". After that the webUI is working.

Someone knows what causes this? It quite annoying to always do the workaround restarting all servives using SSH.

In the Web GUI log are no hints:

Code: [Select]

2021-10-25T13:17:45 lighttpd[69840] (server.c.1513) server started (lighttpd/1.4.59)
2021-10-25T13:17:45 lighttpd[7378] (server.c.1976) server stopped by UID = 0 PID = 80262
2020-10-25T15:18:37 lighttpd[7378] (server.c.1513) server started (lighttpd/1.4.59)

11

German - Deutsch / Re: Wireguard bei HA setup?

« on: September 12, 2021, 05:02:14 pm »

Ich habe das inzwischen hinbekommen...hatte unter "VPNs -> Wireguard -> Local -> Edit -> Peers" vergessen meinen Client einzutragen...
Jetzt klappt da Zugriff per VPN auf alle lokale VLANs und Internet mit DNS.

Mir sind da aber immer noch viele Dinge unklar.

1.) Warum sollte man unter "Interfaces -> Assignment" ein Interface für "wg0" hinzufügen? Wenn ich das richtig verstehe ist wg0 mein VPN Tunnel der dann als Interface dient und den ich wie jede andere physische NIC konfigurieren kann. Macht das gleiche aber nicht schon die Firewall Regelkategorie "WireGuard"?
2.) Wenn ich für wg0 ein Interface "WG" anlege aber für dieses keine statische IP vergebe, dann hat das Interface trotzdem als Subnetz mein 192.169.100.0/24 Subnetz was ich bei Wireguard eingestellt habe. "WG net" ist also korrekt nutzbar aber "WG address" gibt es nicht, was aber schon sehr praktisch wäre damit ich Unbound sagen könnte das es auch auf "WG addess" lauschen soll. Gibt es da einen Grund warum einem alle Tutorials sagen man soll das wg0 Interface ohne vergebene IP erstellen?
3.) Wo genau ist jetzt das Problem mit den virtuellen IPs? Ich habe Wireguard bisher nur für meine Master-OPNsense eingerichtet aber da scheint es soweit mit virtuellen IPs zu laufen. Die Fritzbox port-forwarded alle UDP Pakete an die virtuelle WAN IP, die kommen dann bei der Master-OPNsense an. Und das Outbound-NAT für Wireguard läuft bei mir auch über die virtuelle WAN IP.
4.) Bei HA ist es ja wichtig, dass alle Interfaces genau gleich heißen. Das heißt dann auch, dass ich da auf jedenfall auf der anderen OPNsense auch ein Wireguard laufen lassen sollte, damit beide OPNsenses ein wg0 haben?
5.) HA synchronisiert mir ja alle Aliase, Firewall Regeln und Co zwischen beiden OPNsenses. Das heißt dann aber auch, dass da beide Wireguards die selben IPs und Subnetze nutzen müssten. Ich vermute mal das sorgt dann für ordentlich Probleme wenn da 2 mal der slebe Dienst auf der selben IP läuft?
6.) Was genau ist da jetzt der unterschied zwischen dem hinzufügbaren wg0 Interface und dem automatisch hinzugefügten "WireGuard"?

12

German - Deutsch / Wireguard bei HA setup?

« on: September 10, 2021, 03:34:16 pm »

Moin,

Ich betreibe hier 2 OPNsense VMs hinter einer Fritzbox. Die beiden OPNsenses laufen als HA mit virtuellen IPs.
Da läuft auch alles soweit gut, jedoch wollte ich jetzt gerne, dass da die OPNsenses als Wireguard-Server fungieren (da hatte ich bisher Raspis für, die aber inzwischen eingemottet sind).

Was ich da aber so gelesen habe wird man Wireguard technisch bedingt nicht als HA betreiben können, da dieses nur UDP nutzt und daher nicht mit virtuellen IPs umgehen kann. Das wäre jetzt auch kein Weltuntergang für mich, wenn Wireguard nur auf einer OPNsense laufen würde. Oder halt auf beiden OPNseses parallel aber dann eigenständig auf anderen Ports.

Ich bekomme da aber Wireguard einfach nicht zum Laufen. Das fängt schon bei der Fritzbox an.
Setup ist da so:
192.168.0.1 -> Fritzbox LAN
192.168.0.2 -> OPNsense-PHY (OPNsense Master Physisch)
192.168.0.3 -> OPNsense2-PHY (OPNsense Backup Physisch)
192.168.0.4 -> OPNsense-VIP (OPNsense virtuelle IP)

Wenn Wireguard mit virtuellen IPs nicht umgehen kann, dann wollte ich halt alles was im Fritzbox WAN auf 51821 ankommt gerne an OPNsense-PHY an Port 51821 port-forwarden und alles was im Fritzbox WAN auf 51822 ankommt forwarden an OPNsense2-PHY an Port 51822. Dann könnte ich einfach im Wireguard Client alles 2 mal einrichten und mich vom Client aus entscheiden, welchen von beiden Zugängen ich nutzen will.
Ich bekomme da aber nicht einmal ordentliche Port-Forwards in der Fritzbox hin...
Die Fritzbox ist eine 7560 vom Provider mit FritzOS 7.27. In der Fritzbox selbst werden auch alle 3 OPNsense IPs erkannt. Bisher habe ich da nur 14 Portfreigaben eingerichtet die alle an die virtuelle IP durchgeleitet werden, was auch soweit klappte.
Versuche ich da aber nun eine Portfreigabe für eine der beiden physischen IPs anzulegen, dann scheint da die Fritzbox durcheinander zu kommen. Erstelle ich z.B. eine neue Portfreigabe für das Gerät OPNsense-PHY und speichere diese, dann landet die Portfreigabe nicht bei OPNsense-PHY sondern wird bei dem Gerät OPNsense-VIP hinzugefügt. Ähnliches Problem bei OPNsense2-PHY. Scheinbar bringen da die wechselnden MACs und die virtuelle IP die Fritzbox durcheinander. Aktuell wird also mein Wireguard Port an die virtuelle IP durchgereicht, da mich die Fritzbox einfach keine Port-Forwards an die Physische IP machen lässt.


Ein anderes Problem ist, dass ich da nicht genau weiß, wie ich meine OPNsenses einzustellen habe.
Für mein Wireguard Netz habe ich 192.168.100.0/24 gewählt. 192.168.100.1 soll dann meine OPNsense und 192.168.100.2 mein Handy sein. Wireguard habe ich nach Tutorials so eingestellt, dass sich da eigentlich mein Handy zur OPNsense verbinden können sollte. Das Handy sendet laut Wireguard-Android-App zwar Daten beim Verbindungsversuch, empfängt aber keine Daten. In der OPNsense sehe ich keine Handshakes und auch das Firewall Log zeigt mir keine geblockten Pakete auf dem eingestellten Wireguard-Port. Ich habe da also die Vermutung da liegt das Problem schon zwischen Fritzbox and OPNsense, wo noch ein managed Switch und Virtualisierung zwischen hängen.

Was mir da aber noch nicht ganz klar ist:
1.) Das Wireguard-Plugin hat ja die Firewall-Gruppe "WireGuard" selbstständig erstellt. Aber unter "Interfaces -> Assignments" gibt es nun auch ein neues Interface "wg0" was ich erstellen könnte. Wofür genau sind die beiden zuständig? Wenn ich das wg0 Interface unter dem Namen "WG" hinzufüge, dann kann ich ja für beides Firewall Regeln erstellen.

2.) Mein Outbound-NAT ist auf "Manual" gestellt wegen den virtuellen IPs. Üblicherweise füge ich da für jedes Interface eine neue Regel hinzu. Das müsste ich dann auch sowohl für das "Wireguard" als auch das "wg0" Interface, also z.B. so?:
Interface: WAN
Source address: WireGuard net
Translation / target: 192.168.0.4 (Virtual WAN IP)

3.) Bei den Firewall Regeln für WireGuard habe ich nur folgenen Eintrag:
Interface: WireGuard
Direction: In
Protocol: Any
Source: 192.168.100.0/24
Destination: Any
Passt das oder brauche ich da wegen HA noch etwas anderes? Im Tutorial war nur diese eine Regel angegeben.

4.) Für das WAN Interface habe ich eingehende UDP Pakete erlaubt sofern die "WAN address" +  für den WireGuard-Port als Ziel haben. Was genau heißt dann in dem Fall "WAN address"? Ist das dann die physische WAN IP der OPNsense oder ist es die virtuelle WAN IP der OPNsense oder steht das für beides?

Wäre nett wenn da jemand Tipps hat. Ich würde da WireGuard eigentlich schon gerne mit der OPNsense nutzen anstatt ein neues VLAN mit einer neuen VM nur für Wireguard erstellen zu müssen, was dann am Ende ja doch wieder die OPNsense routen müsste, damit man von dem WireGuard-VLAN ins Internet oder auf andere VLAN kommen könnte.

Edit:
Wenn ich in der Fritzbox einen Port-Forward für 192.168.0.4 für Port 51821 erstelle (so wie für alle anderen Dienste die mit HA gut laufen) dann sehe ich einmalig in der OPNsense Firewall Log dieses:

Code: [Select]

__timestamp__ Sep 10 17:01:30
action [pass]
anchorname
datalen 156
dir [in]
dst 192.168.0.2
dstport 51821
ecn
id 19180
interface vtnet1
interface_name WAN
ipflags DF
ipversion 4
label Allow incoming WireGuards connections
length 176
offset 0
protoname udp
protonum 17
reason match
rid eb61b025f937d46287cd990ef8a616ee
rulenr 145
src Meine.Handy.IP.ADDR
srcport 24103
subrulenr
tos 0x0
ttl 54
Das sehe ich aber auch wirklich nur einmalig. Da kann ich so oft am Handy auf "Connect" klicken, solange ich die Fritzbox nicht reboote kommt der Log nicht noch einmal. Die WireGuard App auf dem Handy empfängt aber keine Pakete und ich sehe auch in OPNsense sonst keine Logs auf dem Port 51821 oder aus dem IP-Bereich 192.168.100.0/24. Auch keinen Handshake oder kein neuer Eintrag unter "List Configuration" im OPNsense Plugin.

13

German - Deutsch / Virtuelle IPs und Fritzbox

« on: February 23, 2021, 01:24:16 pm »

Hi,

Ich habe da mal eine Verständnisfrage zu den Virtuellen IPs.

Wenn ich 2 OPNsenses habe die im HA fungieren, dann haben ja beide OPNsenses jeweils eine identische virtuelle IP und eine unterschiedliche physikalische IP.
Und irgendwie sorgt dann MAC Spoofing noch dafür, dass da virtuelle IPs und physikalische IPs unterschiedliche MACs haben, obwohl beide die selbe NIC nutzen.

Meine Fritzbox kommt darauf aber nicht wirklich klar...

Die beiden virtuellen IP haben die normalen einmaligen MACs der NICs:
FE:41:DC:03:E2:67 = 192.168.0.4
00:A0:98:6F:54:71 = 192.168.0.4

Die beiden physikalischen IPs haben aber eine identische MAC gespooft bekommen:
00:00:5E:00:01:01 = 192.168.0.2
00:00:5E:00:01:01 = 192.168.0.3

Ich kann zwar über die beiden physikalischen IPs auf die GUI der beiden OPNsenses zugreifen, aber wie soll ich da bitte Port-Forwards oder Exposed Hosts auf der Fritzbox einstellen, dass da die die virtuellen IPs auch von dem Internet aus erreichbar sind?

Die Fritzbox teilt Port-Forwards/Exposed Host anhand der MAC zu und nicht anhand der IP. Wenn ich die virtuelle IP der ersten OPNsense als Exposed Host einstelle, dann ist automatisch immer die OPNsense mit der MAC "FE:41:DC:03:E2:67" der exposed Host. Die Fritzbox erlaubt es auch nicht, dass man da einen zweiten Exposed Host erstellen darf. Genau so wenig darf man Port-Forwards des selben Ports zu zwei unterschiedlichen Hosts durchleiten. Damit auch die Backup-OPNsense im Ernstfall Traffic aus dem Internet annehmen kann, müsste ich ja eigentlich noch die MAC der anderen virtuellen IP irgendwie in die Fritzbox kommen. Wenn da immer nur eine MAC als Exposed Host geht, dann könnte die zweite OPNsense ja nie aus dem Internet erreicht werden, selbst wenn die erste OPNsense ausfällt.

Außerdem ist das schon sehr merkwürdig, dass sich da die beiden physikalischen IPs eine MAC teilen.
Das bringt mein Netz glaube ich teilweise zum Spinnen, wenn da zwei unteschiedliche Hosts mit der selben MAC unterwegs sind. Bei der Backup-OPNsense ist z.B. immer nach ein paar Minuten das WebUI nicht mehr erreichbar ("ERR_SSL_PROTOCOL_ERROR") wenn auch die Master-OPNsense gleichzeitig eingeschaltet ist.
Ich muss dann immer wieder über "System -> HA -> Status -> Restart all" auf der MAster-OPNsense the Diesnte auf der Backup-OPNsense neu starten, damit dessen WebUI wieder kurz erreichbar ist.

Für mich macht das alles kein Sinn, außer OPNsense hat da einen Fehler und statt den physischen IPs sollten eigentlich die virtuellen IPs ein MAC Spoofing bekommen. Dann wäre die MAC beider virtuellen IPs identisch und die Fritzbox hätte auch kein Problem mehr mit dem Exposed Host, weil ja dann beide OPNsenses als eine einztige OPNsense erkannt werden würden.

Edit:
vtnet1 aus der ersten OPNsense:

Code: [Select]

vtnet1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=800a8<VLAN_MTU,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE>
        ether fe:41:dc:03:e2:67
        inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
        inet 192.168.0.4 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1
        inet6 xxx%vtnet1 prefixlen 64 scopeid 0x2
        carp: MASTER vhid 1 advbase 1 advskew 0
        media: Ethernet 10Gbase-T <full-duplex>
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

vtnet1 aus der zweiten OPNsense:

Code: [Select]

vtnet1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
        ether 00:a0:98:6f:54:71
        inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255
        inet 192.168.0.4 netmask 0xffffff00 broadcast 192.168.0.255 vhid 1
        inet6 xxx%vtnet1 prefixlen 64 scopeid 0x2
        carp: BACKUP vhid 1 advbase 1 advskew 100
        media: Ethernet 10Gbase-T <full-duplex>
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

14

German - Deutsch / Re: CARP Split Brain mit VMs

« on: February 23, 2021, 08:29:09 am »

IGMP Snooping ist deaktiviert.

Habe nochmal beide ConnectX-3 NICs auf die neuste Firmware geflasht und die beiden NICs aus beiden Servern vertauscht. Keine Änderung. FreeNAS will auf der ConnectX-3 keine CARP Pakete annehmen.

Direktlink muss ich mal gucken, da ja alles über das tagged vlan läuft und ich mich dann selbst aus beiden Server aussperre.

Edit:
Auch wenn ich beide NICs direkt per DAC verbinde kommen über die ConnectX-3 am FreeNAS keine CARP Pakete an.

15

German - Deutsch / Re: CARP Split Brain mit VMs

« on: February 23, 2021, 05:49:25 am »

Da müsstest Du jetzt langsam wirklich einen Bug bei FreeBSD einkippen, wenn es mit einer Deiner Karten im FreeNAS funktioniert, aber mit der anderen nicht. Das ist ja dann offensichtlich ein Treiber-Bug.

Ja, 3 Ports am Switch identisch eingestellt mit gleichen tagged VLANs. Davon 1x SFP+ zum Proxmox, 1x SFP+ zum FreeNAS und 1x Gbit Ethernet zum FreeNAS. Beide SFP+ NICs in den Servern sind identische "mcx311a-xcat". Lasse ich die Intel Gbit NIC unverbunden und nur die beiden SFP+ NICs dran, dann sehe auf dem Proxmox Host CARP Pakete von beiden Servern aber auf dem FreeNAS nur die CARP Pakete von FreeNAS selbst.
Stecke ich zusätzlich das Kabel in die Intel Gbit NIC am FreeNAS Host und gucke was über die Intel NIC läuft, dann sehe ich auch CARP Pakete von beiden Servern.
Also über die Intel NIC scheinen die CARP Pakete in beide Richtungen zu wandern aber über die Mellanox NIC nur ausgehend. Ist halt komisch, weil die baugleiche NIC mit baugleichem DAC am Proxmox Server keine Probleme mit CARP macht.

2 verschiedene Karten in einem lagg einzusetzen ist jetzt aber auch nicht grad das empfohlene Setup ...
Du sprichst doch LACP mit Deinem Switch? Ja? Jetzt sag nicht, dass nicht. Dann lass das mit dem lagg ...

Ich weiß das LACP da Probleme macht mit verschiedenen NICs, besonders wenn eine 10G die andere 1G ist.
Daher hab ich active-passive bzw failover genommen ohne LACP, wo die ja dann nicht gebündelt mit Lastverteilung arbeiten sondern immer nur eine zur Zeit einzeln. Das hatte ja auch soweit gut funktioniert, konnte volle 10Gbit nutzen und wenn ich ein Kabel gezogen habe ist es halt auf 1Gbit umgesprungen und lief dann wenigstens noch mit 1Gbit.
Aber lagg schien hier ja auch nicht das Problem zu sein, wenn die ConnectX3 auch ohne lagg CARP Pakete nur in eine Richtung durchlässt.