Messages

Creating specialized servers is a good and easy way to go.
The other way could be to use client specific overrides to provide each client a fixed IP that can be used in firewall rules to deny/allow access to special devices.

@RamSense what's the time we are talking about?
I have also set up my clients using v4 and v6. Normally my Android phone automatically disconnects WG when at home wifi, but for testing purposes I disabled this behaviour and for now I am online with WG on wifi coming home with WG on 5G/LTE for about one hour without any problems.

:D
Davon hab ich einen uralten für Storage-Spielereien.
Die Sense läuft auf einer RC100 von Securepoint, etwa wie die FWS2251 von Aaeon. Normalerweise ist die relativ flott. 3min für Update und Reboot schafft die aber niemals...

Hm wenn es drei Reboots waren, dann hat es bei mir vielleicht einfach nur so lange gedauert, ohne dass es gehangen hat... Ich bin von einem Reboot ausgegangen und habe es daher so interpretiert.

3 Minuten? Hast du nur 22.7.11_1 installiert?  :o

Hat bei mir auch elendig lange gedauert, etwa 15min bis reboot und dann war erstmal gar nichts mehr. Kaum habe ich meine KVM Konsole aufgeklappt ging es weiter und dann war die Sense auch wieder da... Hat etwa 10min beim reboot gehangen.

Moin,

hat es einen bestimmten Grund, dass Du dem Client einen festen Port zuweist (37163)?

Die IPs in der Client Config passen auch nicht:
Oben bei Interface muss die IP des Clients rein, das wird bestimmt nicht 10.6.0.1 sein, da das der Server selbst ist. Außerdem ist es ein /32 Netz, das macht sogesehen zwar keinen Unterschied, manche Clients haben sich hier aber schonmal angestellt. Demnach wäre vermutlich 10.6.0.2/32 korrekt.

Bei Teilnehmer erlaubte IP gibts Du nur das WG Netz an, hier ist die /32 aber falsch, stattdessen muss hier das /24 rein. Damit kannst du aber keine IPs aus dem LAN erreichen, dazu müsstest Du auch die Range des LAN angeben oder 0.0.0.0/0 damit alles durch den Tunnel geht.

Seitens CPU würde ich mehr Durchsatz erwarten... selbst mit meinem E3845 schaffe ich mit OVPN (AES-128-GCM) 120/84 (bei 300/150) Mbits bei SMB und größeren Dateien, bei kleinen Dateien nur 77/65. Es macht halt einen Unterschied, welches Protokoll verwendet wird. Ich verwende daher (privat) mittlerweile Wireguard, da hier wesentlich mehr durchgeht, vor allem über Smartphone.

Was ein ordentliches Model für Kabel ist weiß ich nicht, hatte ich nie. Mit einer Fritte ist man aber sicherlich nicht schlecht bedient.

Wie es sich bei dir (bzw im Allgemeinen) mit IPv6 im Bridge Modus verhält weiß ich nicht, eigentlicht sollte v6 unabhängig davon sein... wichtig ist halt, dass Du Deine Sense über eine globale v6 von außen erreichen kannst. Mit meinem LTE Modem kann ich das zB nicht, das kann nur Portweiterleitung für v4. v6 wird zwar unterstützt, hier kann ich aber nichts freigeben um meine Sense zu erreichen (brauche ich aber auch nicht).

Wenn man durch das Modem nicht mit v6 zur Sense kommt eventuell ein ordentliches Modem anschaffen mit dem das möglich ist.
VPN an CGNAT über v6 funktioniert genauso gut wie über v4.

Ich vermisse die öffentliche v4 jedenfalls in keiner Weise und freue mich vielmehr darüber, dass die Sense nicht ständig mit irgendwelchen Portscans und co belästigt wird :)

Mach doch einfach Screenshots von der PDF oder optimiere die PDF, das kann auch gut was rausholen :)

Mit DNS und IP Blocking funktioniert das jedenfalls nicht. Ich kenne auch nur die Möglichkeit das mit Ad Blockern auf den Clients zu umgehen, auf Android nutze ich New Pipe als YouTube Ersatz.
Wahrscheinlich müsste man den traffic aufbrechen/mitlesen und rausfiltern welcher Anteil Werbung ist um diesen zu blockieren.

Changing rules from block to allow should be applied immediately, changing from allow to block requires resetting the states as allowed traffic remains allowed until the states are expired or killed.

Da klinke ich mich mal ein und frage: Warum unbound? (habe ich mich nie mit auseinander gesetzt). Bevor ich zu AGH gewechselt habe, habe ich Dnscrypt-proxy verwendet und der hat wie mein AGH die DNS Server verwendet, die ich vorgegeben habe und meinen Vorstellungen entsprechen. Warum soll da noch ein unbound zwischenlabern? Die Anfragen verteilen kann AGH auch und ich kann sogar entscheiden welcher Client von welchen DNS Servern bedient wird (mein Frau steht zB auf Tracking und Werbung, demnach hat sie andere Filter und DNS Server als der Rest).

I created a german tutorial to send WOL over VPN to LAN subnet. Should work for you too: https://www.heimnetz.de/anleitungen/firewall/opnsense/opnsense-wake-on-lan-ueber-vpn/

[[PROLOGUE]]

[PROLOGUE]
Ever since I became a member of this forum, I keep reading about problems with cellular modems from Sierra Wireless (which doesn't mean that Sierra Wireless modems are bad).

In the meantime I have switched to a different, external modem because I also had to struggle with these problems for some time. Over the years, I created a small troubleshooting guide that I could use when nothing worked again. Now I don't need this help anymore, but I don't want to let it get lost in my documents either, but share my findings and make them available here, maybe it will help someone after all.
Please note that it has been a year since I last used my MC7304 before I replaced it with an external modem. This time OPNsense 21.x was present with hardened BSD.

[GENERAL]
Below I describe what I found out for my setup, which doesn't mean that it works in all cases.
Most of the problems occur because the OS cannot communicate with the modem or when connecting to the mobile network itself.

1) Check modem support!
BSD not really seems to support cellular modems very well, so you should always check if someone has already reported that the modem has been successfully set up in BSD or OPNsense. Also remember that there are different cellular bands used by different geographical regions: Your modem must be compatible with your region! MC7304 will perform fine in Europe/ Germany and Australia, but not really good in USA as the modem only supports 2100MHz for that region.

2) Be patient!
After initial connection attempt, e.g. after reboot, it may take some attempts over a few minutes until the connection will be established.

3) Read the logs!
The point to point connection logs are essential to debug such problems, but be prepared that there may be created tons of entries within a few seconds while the modem is trying to connect. You´re good to go using filters for some specific keywords I´ll refer to later in ,,Reading the logs" section.

4) Don´t worry!
Some PPP configuration settings such as service provider settings may dissapear in the GUI occasionally, that should not be the problem, in most cases the connection will work without these settings displayed in GUI.


As mentioned in the docs, the SIM PIN definitely should be deactivated. Do this with a cellular phone, or using the CLI if the access to the modem already works. See ,,AT-commands" section for further information.

Sierra Wireless cellular modems are regulary devices called ,,cuaU0.2", where ,,0" can also differ or may change occasionally for unknown reasons. "cuaU0.1" may be the GPS device included in most cellular modems.

The AT-command / init string &F0E1Q0 +CMEE=2 is often mentioned, which is supposed to prevent or fix problems. For me that AT-command never has fixed any issues and if I translated the individual commands correctly, this command may only provide additional debug information if the parameters differ from default. The command at&v will show you all current parameters.
&F1 will set all parameters to default, &F0 should have no effect, but I am not really sure.
E1 turns echo mode on, but it should be on by default.
Q0 turns result code presentation mode off, but it is by default.
+CMEE=2 reports mobile termination errors, again that's the default behaviour.

[AT-COMMANDS]
The docs states this way to locate the correct port while setting up the first time, but I recommend to do this step each time when issues occur, because it is (for me) the fastest way to see if any communication with the modem itself is possible:
Enter CLI / command prompt and enter cu -l /dev/cuaU0.2 to call the device, where ,,0.2" is your cellular device. If the output is ,,connected" the communication to the hardware is fine so far.
Now enter AT which should say ,,OK" and enter AT+CPIN. An ,,OK" states that access to SIM is also working. If ,,AT" says ,,all ports are busy" (ICP stage failure) you can do as follows:
Exit cu with ~ or start a new CLI session, then enter
cd ..
cd ..
rm var/spool/lock/LCK..cuaU0.2
where ,,0.2" is your device and reboot. Sometimes editing the interface worked form me without requiring a reboot.
If ,,AT+CPIN" gives an error you should check SIM card an PIN.
To disable SIM PIN, after calling your device, you can use AT+CLCK="SC",0,"xxxx" where xxxx is the current PIN.

For further troubleshooting you can use the following AT commands:
Reset modem (I experienced best results using this command in interface config as init string (without ,,AT")): AT!GRESET
Show operation status of the modem: AT!GSTATUS
Determine signal strength (2-9 marginal, 10-14 OK, 15-19 good, 20-30 excellent): AT+CSQ
Network registration status: ATt+CREG?
Show ISP: AT+COPS?
List supported transmission types in actual network: AT*CNTI=1
Show used transmission type: AT*CNTI=0

[READING THE LOGS]
Instead of starting troubleshooting in CLI, you can check the PtP logs in the GUI. I recommend to filter the output using the following keywords one by one:

,,Ack_Sent"
followed by ,,->opened" indicates that the internal hardware communication (ICP stage) is fine. If it shows an error / failure such as ,,The modem is not responding to ,,AT" ...", see ,,all ports are busy (ICP stage)" in AT-commands section further up.

,,MTU", ,,MRU", ,,ACCM"
followed by corresponding parameters indicates that parameter negotiation (LCP stage) was successful. I never experienced errors in this stage. If there are no parameters shown, the signal quality may be poor or modem parameters are misconfigured. It may be worth a try to reset parameters to factory defaults using AT&F1.

,,LCP"
followed by ,,authorization successful" indicates that the registration with the APN using username and password was successful (Authentication stage). If it shows an error / failure check your config.

,,IPCP"
followed by ,,state change Ack-Sent --> Opened" and an assigned IP address indicates that the cellular connection is established and ready to use (IPCP stage). If it shows no IP or an error / failure, check your PtP connection, select your country, ISP and all required options and save. This happened to me most times after a reboot, sometimes it took a while until the connection was established, sometimes it failed even after some hours of waiting. If ,,edit and save" don't do the trick, try a reset (AT!GRESET) in CLI or add !GRESET as init string in the interface configuration. Note that the init string may dissapear after some time. There is no need to add it again as long as everything works as expected.
I also remember that I had some issues at this stage (?) when I tried to get IPv6 to work on the cellular interface, maybe you're good to go disabling IPv6 temporarily.

[EPILOGUE]
I hope this little guide can help someone troubleshooting problems with Sierra Wireless modems. Maybe you can do something with it when using other modems, although my recent experiences show that there can be significant deviations here.
Please excuse my partly bad English, I read a lot in English, but that doesn't mean I can express myself better in that language, but what are online translators for?! ;)

Now while you guys solve your problems, I'll just sit back and watch my external modem at work... I'll have a drink to that, cheers!