Messages

I have following sysctl values set:

Code Select Expand


net.inet.ipsec.filtertunnel: 0
net.enc.in.ipsec_filter_mask: 2
net.enc.out.ipsec_filter_mask: 1


When filtering on enc0, traffic filtering does not apply. When filtering on a ipsecXYZ device (i.e. VTI device), filtering applies. This behaviour seems to be different from 24.1 and also different than described in https://docs.opnsense.org/manual/vpnet.html#route-based-vti.
Is this an intentional change, or are there other settings which might have an impact here?

Hi,
did anyone accomplish a VTI with IPv6 addresses? The GUI accepts the config, but the inet6 address is never set on the ipsec interface.

Code Select Expand

ipsec41: flags=8011<UP,POINTOPOINT,MULTICAST> metric 0 mtu 1400
tunnel inet 198.51.100.39 --> 203.0.113.49
inet6 fe80::20d:3aff:fe83:90d5%ipsec41 prefixlen 64 tentative scopeid 0xd
groups: ipsec
reqid: 41
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>


Hi,

in the legacy IPsec UI one can create VTI tunnels with dynamic remote IPs by selecting "Route-based" as a mode for the P2 entry. This will then automatically create a Virtual Tunnel Interface with the entered remote gateway of the corresponding P1 entry.

With the new IPsec UI the Virtual Tunnel Interface needs to be created manually and there, only an IP address is accepted in the remote address. A hostname is not accepted.

Did I oversee something or is there a way to create a VTI with dynamic remote address?

I've started up one of my devel machines after a longer time being offline. I faced the issue with not being able to update due to server certificate validation issues with the let's encrypt upstream. After some recommendations in other threads I removed all Let's Encrypt roots and intermediates from the certificate trust, then I switched to a HTTP mirror and accomplished to update.
Now I'm facing the situation that when trying to change to the devel stream (mirror type 'Development') I get verification errors, but on the community stream updating is possible via the same mirror even using HTTPS (default mirror - pkg.opnsense.org).

Code Select Expand


***GOT REQUEST TO UPDATE***
Currently running OPNsense 22.1.9 (amd64/OpenSSL) at Sat Jun 25 22:00:51 CEST 2022
Updating OPNsense repository catalogue...
Certificate verification failed for /CN=pkg.opnsense.org
34372419584:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:


How is server certificate verification related to the chosen release type?? I'm out of ideas what to try (curl https://pkg.opnsense.org actually works without issues).

I think the user interface can really be improved here, as such exceptions from the rule are really counterintuitive.

Hi
The add P2 button is actually located next to the corresponding P1 entry.

Try to enforce a max. MSS value on the IPSec interface using a normalization rule in Firewall > Advanced > Normalization. See an example attached.

http://cloud.tapatalk.com/s/620558dfc945d/Safari%20-%2010.02.2022%20at%2019%3A24.pdf

Hi,
anyone already accomplished a dual-stack IPv4 and IPv6 route-based IPsec tunnel? I want to use IPv4 and IPv6 (in Phase 2) in a single tunnel, is this possible?
Whenever I add the IPv6 Phase 2 the tunnel removes the IPv4 network endpoints:

Before (IPv4 only):

Code Select Expand


ipsec2000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
        tunnel inet 80.123.123.49 --> 51.21.21.19
        inet6 fe80::222:68ff:fe12:b78b%ipsec2000 prefixlen 64 scopeid 0x9
        inet 172.16.0.4 --> 172.16.0.8 netmask 0xffffffff
        groups: ipsec
        reqid: 2000
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>


After (IPv4 and IPv6 added on P2):

Code Select Expand


ipsec4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
        tunnel inet 80.123.123.49 --> 51.21.21.19
        inet6 fe80::222:68ff:fe12:b78b%ipsec4 prefixlen 64 scopeid 0x9
        inet6 fdfa:8191:4040:2000::4 --> fdfa:8191:4040:2000::8 prefixlen 128
        groups: ipsec
        reqid: 4
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>


Any ideas?

Cannot confirm your experience on an Azure VM:

Code Select Expand

mf@opnsense-dev:~ % speedtest

   Speedtest by Ookla

     Server: Claranet Benelux B.V. - Amsterdam (id = 30847)
        ISP: Microsoft Corporation
    Latency:     2.53 ms   (0.26 ms jitter)
   Download:  3093.84 Mbps (data used: 3.2 GB )                               
     Upload:   956.58 Mbps (data used: 864.6 MB )                               
Packet Loss:     0.0%
Result URL: https://www.speedtest.net/result/c/abd6703b-9231-498c-97b6-98533a3df037
mf@opnsense-dev:~ % uname -r
13.0-STABLE

I run two VMs in Asure. I assume that's also Hyper-V running in the background. Didn't recognize any performance issues so far, but as those are dev. VMs they are not heavily used.

Can you share your VPN configuration? Especially the networks in the tunnel.

Not sure if I understand correctly what you want to achieve, but I assume you want to route HTTP traffic for certain websites via a different site (to connect to the HTTP server using a different public IP).

I assume the VPN tunnel is not foreseen to have other IP addresses than internal ones (local net and remote net are typically private IPs), but the domain.com resolves to a public IP which is not part of the tunnel network.
If so, then extend your VPN tunnel ranges.

If I'd get the task, I'd do it a slightly other way:

• Override the DNS entry of domain.com on the local OPNsense instance to any IP internal address which can traverse the VPN
• On the remote side make sure to have a outbound NAT rule which matches also the local LAN (not only the remote LAN)

I'd say its worth to start a discussion via github

opnsense/core#5464 it is  ;)

Does that even make sense for https? I intentionally only implemented it for http.

You mean because it will most likely be a certificate mismatch to the hostname in all cases? One could use wildcard certificates to overcome this.

You can add that in the Tunables section of System > Settings without manually editing files.

I believe it should be enabled by default anyway (or at least loaded automatically upon enabling of the IPsec service).
It should go to /usr/local/etc/rc.loader.d/20-modules I'd say.