Topics

1

General Discussion / Route Based IPsec breaks Port Forwarding

« on: January 22, 2020, 05:52:25 pm »

I just found out that when using Route Based IPsec tunnels, Port Forwarding only works if

  Firewall / Settings / Advanced / Use shared forwarding

is disabled. It is enabled by default. I wonder if this is a bug or spmething that is specific to my environment. If this is by design, it should be added to the manual as it is not obvious.

This was obsered on a fresh installation of OPNsense 19.7.9.

2

General Discussion / Route Based IPsec Limitation

« on: January 22, 2020, 04:53:25 pm »

Scenario: Private LAN on Location A connected via OPNsense 19.7.9 to Internet. OPNsense has Route-Based IPsec tunnel to location B. Everything works as expected, except that the public IP of location B is now unreachable for hosts in private LAN of location A.

I assume that all traffic from LAN to the public IP of location B is erroneously sent via Tunnel Gateway through the tunnel instead of being Natted to the standard default route.

Is this behaviour a general design flaw of Route-Based IPsec on OPNsense or can it be solved somehow?

3

17.1 Legacy Series / SNMP service is crashing regularly

« on: March 05, 2017, 11:48:26 am »

We are evaluating OPNsense 17.1.2 for production use and observed that the snmp service is crashing regularly after about 5 days. We are sending snmp requests every five minutes for the most common linux parameters (cpu util, memory usage, interface usage, uptime) using bare OIDs, so this can't be a MIB issue.

One other thing that bothers me is that we don't get any snmp response from the standard Nagios check_snmp_storage request. All Linux hosts of different flavors give a valid reply for this SNMP query, only OPNsense does not. We could live with the fact that we can't monitor disk usage on OPNsense boxes but it is inconvenent that we have to treat these boxes seperatly from all other linux hosts.

Looks like the snmp service is dying because it's logfile growth, but this should not happen IMO. SNMPD is notoriously talkative and a quick and dirty solution would be to set the dontLogTCPWrappersConnects option. Of course this would not solve the underlying problem that it must not be possible to kill the service by sending ligitimate snmp get requests.