Messages

Ist der Anschluss neu resp. gerade geschaltet worden? Den Fehler gibt es manchmal, wenn SIP/VoIP noch nicht ganz aktiviert wurde. Typisch ist da, daß man angerufen werden kann, aber nicht raustelefonieren.

Kriegt der RW auch _alle_ Netze gepusht?

Normally you don't want to route all traffic through a VPN, so this needs a special setting on client side or a server-side config file with the option set, see https://openvpn.net/index.php/open-source/documentation/howto.html#redirect
If you can't control the openvpn server (so you can't set that option), you then need to manually set the default route to the VPN server's IP. Beware that _all_ traffic get's routed, so you may also need to push DNS, WINS and such.

Does your VPN client know the route to the remote LAN? If not set to route all traffic through VPN you must push the route via the server and use dev tun.
See https://openvpn.net/index.php/open-source/documentation/howto.html#scope

Well, I had very bad experiences with older boards made by Jetway (unstable, creepy caps, bad PCB-design and such). They also had bad support (not existing...), so Jetway is on my personal no-buy-list. Before buying Jetway, I even take those cheapies from aliexpress.. ^^
Of course, things could have changed..

Hmm.. ICMP spielt da eventuell eine Extrawurst, da ICMP redirects i.d.R. beachtet werden. Dann müßte man aber trotzdem immer erst mal falsch addressierte (i.e. falsche MAC) ICMP-Packete am nächsten Router sehen - und ein entsprechenes Geh-wo-anders-lang-Packet vom Router an den opnsense-Router intern.
Auch was reply-to mit ICMP so anstellt.. hmm..

Put a hub in front to be sure to capture all packets with a third machine. Just set this eg. laptop to a static IP like 10.2.3.4 and capture in promiscuous mode.
ISP - Modem - hub - router and laptop
A switch with an admin/mirror/monitor/whatever-it-is-called port will do the same.

Normally you have to give your ISP the MAC of the new DHCP-client aka router. Sometimes via web, sometimes even via good ole telephone. Did you do this and/or try to clone the MAC of your old router?

I use several Lex 3I270D with Intel Atom N270 1,6GHz. There are quite some OEM-boxes with this board out there, with 2-4-Realtek NICs, mini-PCIe, SATA and CF-slot. You can get them sometime for ~25$/€ barebone (no RAM, no SSD/DOM) on ebay.
Work fine on a 200MBit cable line, VDSL lines, ..
Here's one (much to expensive..) with only 2 NICs, you can see the 2 more optional ethernet slots in the housing.
http://r.ebay.com/TsGDEl
Same device, but labeled as Securepoint firewall and has all 4 NICs, also much to expensive.
http://r.ebay.com/xh8hzV
They have VGA - which is really nice. Without VGA I recommend those APU-1D4 or simular thingies like this
http://r.ebay.com/e27OEZ
Serial setup only, realtek NICs, work.
I really like to see those boxes with Intel NICs, but well.. I also modded 2 Lex 3I270D and soldered a second SATA port onto the board, but well, SMD.. ^^

Naja, das
"We may need a bit more logic when applying reply-to on an interface's rules, skipping it automatically for rules that refer to directly reachable networks."
klingt schon ziemlich nach genau diesem Problem.
Damit wir uns richtig verstehen, mal ein Schaubild rein.
http://www.mein-zeugs.de/pub/setup.png
Das war "mein Problem" aus dem IRC-channel. Fw1 und Fw2 sind Kisten mit opnsense, mein Mac ("PC1") die 192.168.1.69 und das Laptop der Port-Forwarding-Versuch. Alle Pakete von PC1 wandern via Fw2 zwar bis zum Laptop, aber die Antworten werden von Fw2 nicht an PC1 addressiert (MAC-Adresse), sondern bekommen als Empfänger-MAC die von Fw1. Fw1 kann damit natürlich nichts anfangen und verwirft die einfach. Gleiches mit ssh von PC1 auf Fw2 - Pakete kommen an, werden angenommen (Firewallregel erlaubt ssh auf WAN), aber die Pakete werden wieder an MAC von Fw1 geschickt und PC1 sieht keinerlei Antwortpakete (geswitches Netzwerk). Erst mit einem Hub (oder entsprechenden Port an einer Switch) sieht man auch da dann die Pakete rumfliegen.
Deaktiviert man auf Fw2 alle Gateways (und damit die reply-to-Regeln), geht alles (ssh und port-forwarding auf das Laptop) - aber logischerweise kein Internet.. ^^
Ich kenne pf nicht so gut, aber es müßte halt sichergestellt werden, daß lokal erreichbare Netzwerke (inkl. möglicher statischer Routen im 192.168.1.0) nicht über das nächst höhere Gateway wandern. Eigentlich müßten ja z.B. VPN-Tunnel ebenso Probleme machen, da auch hier kein Upstreamgateway beteiligt sein darf.

Das Problem ist doch, daß reply-to im Fall des _lokalen_ WAN-Netzwerkes wenig sinnvoll ist. Nur im Fall einer ungewöhnlichen physischen Segmentierung und Abschottung der Knoten in "lokale WAN-Untersegmente" müßte überhaupt ein Router ins Spiel kommen. Ansonsten muss das Paket einfach über die WAN-Schnittstelle raus und gut is. Bin mir nicht mal sicher, ob der nächsthöhere Router nicht einfach die Pakete verwirft, da sowohl Sender als auch Empfänger im gleichen logischen Netz sind. Stille Post spielen ist da nicht wirklich sinnreich.. ;)

Well, if you deploy machines in a big network, security matters for sure. So my suggestion is, that the installer takes care of user interaction right after start. Like a timer that waits for a keyboard pressed (case 1: user has a screen, we take "opnsense" as default root password) and a (decent) timeout and further enabling ssh (case 2: no direct user interaction, we take a MAC as root password). This won't force to change much documentation and won't stress "normal" users but takes care of bigger networks and their specific needs. That's more or less the opposite way it works on many headless systems with a bootloader waiting for a (e.g. serial) interaction to do fancy things like firmware recovery and, if there is no interaction, continues to boot the default headless system with no direct user interaction. Which makes sense, because those devices are headless by default and opnsense is not. So reversing this behavior might be a good idea.

Naja, das ganze erinnert doch sehr an Kindergarten. Aber - und das sollte man nicht vergessen - ist hier auch Geld im Spiel und macht das ganze wieder hässlich.
Meiner bescheidenen Meinung nach sollte man das alles einfach ignorieren und mit opnsense in Ruhe weitermachen. Ob hier auch Befindlichkeiten transatlantischer Natur mit reinspielen - keine Ahnung, aber denkbar. pfsense ist ja auch nichts anderes als ein Fork (von m0n0wall). Und Manuel Kasper hat eben nicht pfsense, sondern opnsense als "würdigsten" Nachfolger empfohlen, das fuchst die sicher.. ;)
Für mich ist wichtig, daß opnsense sich nicht - wie leider viele andere Projekte - daran versucht, das Rad 2x zu erfinden und unnötige Energien in Dinge steckt, die schon vorhanden sind. Mein liebstes Beispiel, aber eben auch traurigstes Beispiel, hier ist IPCop. Tolle Firewall mit Fokus auf Sicherheit. Aber inzwischen völlig veraltet, weil die Entwickler nicht mehr hinterherkommen. Anstatt die Firewall weiterzuentwickeln, prügeln die sich mit der rasanten Entwicklung des Unterbaus, Linux, herum, weil sie keinen fertigen Unterbau nehmen, sondern via LFS alles selbst bauen wollen. Nett, aber das kostet einfach irre Zeit und Opensource-Projekte haben davon nicht unbegrenzt viel. Deshalb stört es mich auch nicht die Bohne, wenn Projekte auf andere Projekte aufbauen - das ist ja gerade Sinn und Zweck von OpenSource und offenen Schnittstellen etc. Der Weg von pfsense in Richtung restriktiver Lizenz ist IMHO deshalb falsch - wenngleich wohl finanziell lohnender. Aber die freiere Konkurrenz mit Schmutz zu bewerfen, ist weder professionell noch wird es sich auf Dauer bezahlt machen, da bin ich mir sicher.
Wichtig wäre für opnsense in naher Zukunft eine Etablierung in z.B. der akademischen und schulischen Umgebung. Egal ob mit einem Schulprojekt oder der c't etc. Aber dazu muss definitiv der Fokus auf Stabilität und Sicherheit verstärkt werden. Systempflege statt Featuritis, Sicherheit statt Bequemlichkeit,  logische und konsistente GUI statt BlingBling. Wenn ihr das schafft, erledigt sich das Thema hier von ganz alleine.

Well yes, there are security things involved. If you set up a device like this (with a default known root password), you have to ensure that no one else can touch your ethernet.. ^^
A second way might be to change the root password in ssh-mode to e.g. the MAC-address of the first ethernet interface (either xx:xx:.. or xx-xx-..). Apple uses the serial number of the machines, but well, standard hardware doesn't have this or in a different way (like HP or Dell). So, common feature is the MAC, which is often on a sticker on the machines anyway.

Well, it might be a bit confusing. If you connect from inside your LAN to the outside (WAN) IP-address of your firewall, you indeed will get the normal login page. If you check the same from outside - it won't work. Or should not - if you did not change anything. So - check from an outside address.
LAN-client -> LAN-IP of firewall  = works
LAN-client -> WAN-IP of firewall = works
WAN-client -> WAN-IP of firewall = does not work (by default)
You might check this with an online scanner like
https://pentest-tools.com/network-vulnerability-scanning/tcp-port-scanner-online-nmap
or
https://www.grc.com
or any other online scanner around.

So, traffic gets redirected, but there is no explicit rule for that shown in the GUI, prob. a dev will answer here.