Messages

Same issue here.

Segmentation fault also popping up when verifying configuration file with the -k parse option.

Code Select Expand

squid -k parse

Welches Betriebssystem läuft auf dem PC?

Beim Betriebssystem SMBv3 aktiviert, SMB multi-channel aktiviert?

[a "kernel route" is installed]

I fear observed performance degradation could be linked to the following:

In order to pass traffic over an IPsec tunnel, we need a policy matching the traffic. By default when adding a phase 2 (or child) policy a "kernel route" is installed as well, which traps traffic before normal routing takes place.

I would actually have expected that normal routing would have a higher priority and preference over the IPsec policies.

Maybe the developers can elaborate on the "kernel route" thing. Especially, it would be important to know whether the "kernel route" traps ALL traffic or if the trap just applies to traffic selectors defined in phase 2.

[Generally IPsec processing is based on policies.]

Generally IPsec processing is based on policies. After regular route lookups are done the OS kernel consults its SPD (Security Policy Database) for a matching policy and if one is found that is associated with an IPsec SA (Security Association) the packet is processed (e.g. encrypted and sent as ESP packet).

Depending on the operating system it is also possible to configure route-based VPNs. Here IPsec processing does not (only) depend on negotiated policies but may e.g. be controlled by routing packets to a specific interface.

[...]

https://docs.strongswan.org/docs/5.9/features/routeBasedVpn.html

[~600 MBit/s]

This seems to be an endless problem. I still encounter similar problems. LAN throughput is poor when (policy-based) IPsec VPN is enabled.

I ran a few tests again. In order to exclude as many external influences as possible, I deliberately kept the test setup simple. There are simply two servers (each in its own subnet) and OPNsense in between. The devices are connected via GBit full-duplex link . Performance tests are done with iPerf (utilizing TCP-connections).

iPerf gives the following bandwidth between the two servers:

strongswan activated:     ~600 MBit/s
strongswan deactivated: ~930 MBit/s

As you can see there is a significant drop in performance when strongswan is activated. This is a surprise to me since the traffic between the two servers is not subject to any IPsec policy at all.

Unfortunately, I have no idea how to further analyze the problem - if this is even possible. I'm afraid that one has to really dig deep into the kernel to understand what's happening behind the scenes.

Similar issue here with 23.1.11.

Suddenly LAN interface and all VLANs lose the connection. Log file is showing that the link states changed to DOWN.  >:(

[/* kill all states destinating at and originating from cached IP before removing cached IP*/ mwexecf('/sbin/pfctl -k 0.0.0.0/0 -k %s', $cacheip); mwexecf('/sbin/pfctl -k %s', $cacheip);]

Complaining is easy.

Yes, you're right. Sorry for my harsh words.

Can't we just - before we delete the cached IP - kill the old states like we do when the IP address changes? It should look like this then:


        $ip = get_interface_ip($interface);

        $cacheip_file = "/tmp/{$device}_oldip";

        if (!is_ipaddr($ip)) {

            /* kill all states destinating at and originating from cached IP before removing cached IP*/
            mwexecf('/sbin/pfctl -k 0.0.0.0/0 -k %s', $cacheip);
            mwexecf('/sbin/pfctl -k %s', $cacheip);

            /* remove previously cached IP since it is gone */
            @unlink($cacheip_file);

            /*
             * Take care of OpenVPN and similar if you generate the event
             * to reconfigure an interface.  OpenVPN might be in tap(4)
             * mode and not have an IP address.
             */
            if (substr($device, 0, 4) != 'ovpn') {
                log_msg("Failed to detect IP for {$interface_descr}[{$interface}]", LOG_WARNING);
                return;
            }
        }

Patch works like a charm. Top!

        local-0 {
            id =
            auth = pubkey
            certs = cert-1.crt
        }
        remote-0 {
            id = %any
            auth = pubkey
            eap_id = %any
        }
        remote_addrs = %any
        encap = no
        dpd_delay = 10 s
        dpd_timeout = 60 s
        pools = defaultv4
        remote-1 {
            auth = eap-mschapv2
        }

Well spotted!

I changed the configuration manually according to your findings. After reloading the configuration with swanctl --load-conns Mutual RSA + EAP-MSCHAPV2 works as expected.

The next time I restart or when I make changes via the GUI, my manual changes are of course gone.

Guys, seriuosly? Every time the same dilemma that something doesn't work after an update. Does anyone here do a code review and testing before releasing the changes? Doesn't look like it!

Due to recent changes in rc.newwanip and rc.newwanipv6 stale states won't be deleted from the state table any longer.

The problem lies in changed code lines 61-78 of rc.newwanip script (analogue rc.newwanip6):

Code Select Expand

$ip = get_interface_ip($interface);

$cacheip_file = "/tmp/{$device}_oldip";

if (!is_ipaddr($ip)) {
    /* remove previously cached IP since it is gone */
    @unlink($cacheip_file);

    /*
     * Take care of OpenVPN and similar if you generate the event
     * to reconfigure an interface.  OpenVPN might be in tap(4)
     * mode and not have an IP address.
     */
    if (substr($device, 0, 4) != 'ovpn') {
        log_msg("Failed to detect IP for {$interface_descr}[{$interface}]", LOG_WARNING);
        return;
    }
}

get_interface_ip won't return any IP when there is a forced disconnect by the provider. Hence, if (!is_appr($ip)) will be TRUE, the cacheip_file be deleted and the script exited.

The script won't reach code lines 166-181 where stale states will be flushed from the state table.

Nice observation! Thanks for the references.

You are right. VPN logs showing "no proposal chosen" error when using modp8192. Switching to LibreSSL on both endpoints fixed the issue.

I hope OpenSSL will be fixed or upgraded to > 3.0.5 before LibreSSL will be dropped.

I am running an IPsec site 2 site VPN with several phase 2 tunnels. Tunnel isolation has been enabled in phase 1 settings. All tunnels show up in ipsec.conf file.

This setup has been working flawlessly in OPNsense 22.1.

Unfortunately, since update to OPNsense 22.7 only one tunnel is possible. Once one tunnel (it doesn't matter which one) is being established no further connections can be established.

Any ideas how to fix?

[interrupt]

interrupt	total	rate
irq51: ix2:rxq0	5136	11
irq52: ix2:rxq1	2176474	4708
irq53: ix2:rxq2	7203	16
irq54: ix2:rxq3	3299471	7138
irq55: ix2:aq	1	0

This is really crap!

There shouldn't be any problems with the CPU. With pfsense and Win10 you have already been able to achieve higher data rates.

By the way, I use a Supermicro A2SDi-4C-HLN4F motherboard with an Intel Atom C3558 CPU.

In case there is free time this weekend I will rebuild my complete setup on OPNsense 20.1 for testing purposes.

Thanks for you effort. I had already considered doing some performance tests with pfsense as well.

I am having the same performance issues. And we are not alone.

In the past I did compare the routing performance of OPNsense and Ubuntu (https://forum.opnsense.org/index.php?topic=18754.msg91547#msg91547). Pretty clear result: OPNsense crap, Ubuntu full wirespeed.

Surprisingly, a rollback to OPNsense 20.1 gives me full wirespeed.

Something seems to be broken in OPNsense.