Messages

You can disable root (System->Access->Users select root and check Disabled).
If you're using shell access, you should (if not done already) enable sudo usage (System->Settings->Administration), otherwise (at least the last time I checked), you can not elevate your privileges in the shell.

[disabled]

Hi,

I've been trying to solve an IPSec issue where a box works fine with a public IP but does not send any data behind a NAT connection. To do this I used two Opnsense (plus the box to connect to, which we call H) boxes, one as a Router (call it R) with a public IP which basically does only NAT (and later introduces some connection problems for testing) and another machine to do the IPSec tunnel (call it I). Turns out, that the firewall of I blocks the connections on the IPSec interface even though there is a valid rule to allow any traffic from the IPSec interface to the LAN and a rule on the LAN interface to do the opposite. This could be fixed by adding an IPSec to any rule, which is weird but deemed to be investigated if time is available. Copied the working config to another box (F for far away) and off it goes.

But it did not work as intended, so I fired up the two boxes (R and I) again. To avoid problems because of the same config (same tunnel and local subnet), I created a copy of the IPSec tunnel with different password and different ciphers and disabled the old one on H (box F is still online) and of course reloaded the IPSec config.

Now it gets weird and I did lose quite a lot of hair. I tested the connection by trying to reach the web interface of the remote box but the firewall of both I and H (both having the IPSec to any rule) decided to block the SYNACK. So the package goes H -> R -> I, is answered there and the answer gets back the whole way to H where it is rejected for no apparent reason. To demonstrate this to a colleague I reloaded the page a few times (times out of course) but then it did work. The web interface appeared! Hooray! No config changes, nothing, just out of the blue. But then I saw the Gateway IP of the box and realised, it is not I I am talking to but instead it is F (same local IP because same config), which should not work because the tunnel is disabled. Checking on the Tunnel Settings it is indeed disabled. It does not appear on the Status Overview. That means there is a tunnel running which should not be there and it does not appear in the web interface!

Checked the command line, the connection does still show up as "Security Association" but not as a "Connection" in ipsec statusall. Could only really disconnect the connection with ipsec down con1

To sum up:

• IPSec behind NAT confuses the firewall
• disabling an IPSec tunnel via the GUI does NOT disable it
• there can be an active tunnel without showing up in the GUI Status Overview

Two and three are bad and one is still not working. Any help?

Thanks!

I would suggest checking out this thread with a test kernel to try:
https://forum.opnsense.org/index.php?topic=4804.0

Thanks for the advise! Sadly this kernel doesn't fix the issue (at least for me) with IPsec traffic getting filtered by the firewall despite rules saying otherwise.

Hi,

is there any news on this? I'm using 17.1.3 and still have problems with IPSEC traffic being blocked by the firewall. Is there any workaround (except for possibly creating a hole in the fw by allowing bogus IPs on WAN)?