Een niet gebruikelijke configuratie, aangezien de OPNsense firewall doorgaans alleen vanaf de LAN zijde benaderd zal worden, maar een testopzet van OPNSense in een VM op een Linux systeem. OPNSense, Linux en V10 bridged op 192.168.2.0/24
Ik probeer OpenVPN draaiend te krijgen tussen het host-systeem en de OPNsense gast. Met geen mogelijkheid.
Wat blijkt: OPNSense stuurt antwoord op OpenVPN verzoeken naar de Experiabox, de default route. Als deze het pakket ongewijzigd aflevert bij de buren is er weinig aan de hand, maar de box doet een soort omgekeerde NAT en antwoordt met het externe adres als bron.
Daarmee verandert het pakket van gerelateerd naar ongerelateerd met extern bron adres en wordt door de Linux firewall geweigerd.
Oplossing: Diep verborgen in OPNSense Firewall: Settings: Advanced zit:
| Disable reply-to | Disable reply-to on WAN rules With Multi-WAN you generally want to ensure traffic leaves the same interface it arrives on, hence reply-to is added automatically by default. When using bridging, you must disable this behavior if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface. |
Aanzetten van deze optie zorgt ervoor dat OPNSense weer normaal werkt en binnen het WAN netwerk kan communiceren zonder via de V10 te gaan. Ik begrijp de verklaring niet, maar het helpt wel.
Misschien heeft iemand ooit wat aan deze tip, als experimenten met deze firewall op onverklaarbare wijze mislukken.
