Messages

1

German - Deutsch / Re: Langsamer Traffice zwischen 2 VLANs

« on: December 20, 2023, 01:23:04 pm »

Welches Betriebssystem läuft auf dem PC?

Beim Betriebssystem SMBv3 aktiviert, SMB multi-channel aktiviert?

2

Hardware and Performance / Re: BUG: Low data throughput (bug in Opnsense or FreeBSD?)

« on: December 19, 2023, 10:22:05 pm »

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.

3

Virtual private networks / Re: How can I view the IPSec VPN routes in kernel routing table?

« on: December 19, 2023, 07:37:45 pm »

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

4

Hardware and Performance / Re: BUG: Low data throughput (bug in Opnsense or FreeBSD?)

« on: December 18, 2023, 10:50:09 pm »

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.

5

23.1 Legacy Series / Re: LAN interface drops connection after a few days

« on: August 21, 2023, 11:55:51 pm »

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. 

6

23.1 Legacy Series / Re: Stale NAT states on WAN-IP change prevent SIP re-register

« on: February 13, 2023, 08:27:03 pm »

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;
            }
        }

7

23.1 Legacy Series / Re: Update migration of IPsec with "Mutual RSA + EAP-MSCHAPV2" broken.

« on: February 13, 2023, 08:08:54 pm »

Patch works like a charm. Top!

8

23.1 Legacy Series / Re: Update migration of IPsec with "Mutual RSA + EAP-MSCHAPV2" broken.

« on: February 12, 2023, 07:30:20 pm »

        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.

9

23.1 Legacy Series / Re: Stale NAT states on WAN-IP change prevent SIP re-register

« on: February 11, 2023, 02:49:43 pm »

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]

$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.

10

Virtual private networks / Re: Only one tunnel in IPsec s2s VPN possible since update to OPNsense 22.7

« on: October 03, 2022, 07:37:23 pm »

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.

11

Virtual private networks / Only one tunnel in IPsec s2s VPN possible since update to OPNsense 22.7

« on: October 02, 2022, 04:49:00 pm »

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?

12

Hardware and Performance / Re: Poor Throughput (Even On Same Network Segment)

« on: June 12, 2022, 01:32:19 pm »

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!

13

Hardware and Performance / Re: Not getting gigabit throughput on iperf3

« on: June 07, 2022, 09:23:16 pm »

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.

14

Hardware and Performance / Re: Not getting gigabit throughput on iperf3

« on: June 07, 2022, 08:46:49 pm »

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.

15

Hardware and Performance / Re: Poor Throughput (Even On Same Network Segment)

« on: June 07, 2022, 08:31:23 pm »

https://www.mayrhofer.eu.org/post/firewall-throughput-opnsense-openwrt/

When IPsec is active - even if the relevant traffic is not part of the IPsec policy - throughput is decreased by nearly 1/3. This seems like a real performance issue / bug in the FreeBSD/HardenedBSD kernel. I will need to try with VTI based IPsec routing to see if the in-kernel policy matching is a problem.

Well spotted! Exactly the same negative observation here on my end with IPsec policy based VPN. 

Here is a first estimate of how IPsec affects my routing speed in the LAN:

Direction	IPsec enabled	IPsec disabled
Server -> OPnsense -> Client	48.1 MB/s	74.2 MB/s
Server <- OPnsense <- Client	49.9 MB/s	61.1 MB/s

Overall, the routing speed remains very disappointing. Especially considering I had full routing performance up until OPNsense 20.1.

During my testing, I noticed that OPNsense doesn't seem to be utilizing all NIC queues. Two out of four NIC queues process almost no traffic and are bored.

Code: [Select]

dev.ix.2.queue3.rx_packets: 2959840
dev.ix.2.queue2.rx_packets: 2158082
dev.ix.2.queue1.rx_packets: 9861
dev.ix.2.queue0.rx_packets: 4387

dev.ix.2.queue3.tx_packets: 2967255
dev.ix.2.queue2.tx_packets: 2160888
dev.ix.2.queue1.tx_packets: 15955
dev.ix.2.queue0.tx_packets: 8725

Any take on this?