Topics

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?

[Auto-added VPN rules do not take the global firewall setting "Disable reply-to on WAN rules" into account.]

Dear all,

I have a working IPsec VPN setup with multiple site2site and roadwarrior tunnels. Currently, I only use IPv4 for my IPsec connections. Works like a charm. To make my setup more future-proof I'm a currently testing IPv6 IPsec connections. This is exactly where the problems start...

To make a long story short: IPv6 IPsec connections cannot be established.

A packet capture shows that the OPNsense responds to incoming ISAKMP traffic. However, response packets never reach the IPsec originator. It looks like the IPv6 gateway drops the packets for whatever reason.

Further research in the forum put me on the right track. The problem seems to be related to reply-to which by default is added to every WAN rule.

Hence, I disabled reply-to on WAN rules under Firewall -> Settings -> Advanced. However, that did not bring the desired success. ISAKMP response packets still do not reach the IPsec originator.

I digged a little bit deeper, disabled all auto-added VPN rules and started from scratch with my own firewall rules. And lo and behold... it works!

In the end I could pinpoint the problem. Auto-added VPN rules do not take the global firewall setting "Disable reply-to on WAN rules" into account.

Despite disabling reply-to auto-added VPN rules are still being generated with a reply-to expression:

pass out log on pppoe0 route-to ( pppoe0 fe80::xxxx:xxxx:xxxx:xxxx ) proto udp from {any} to {any} port {500} keep state label "37[...]c7" # IPsec: Mobile Devices

pass in log on pppoe0 reply-to ( pppoe0 fe80::xxxx:xxxx:xxxx:xxxx ) proto udp from {any} to {any} port {500} keep state label "27[...]81" # IPsec: Mobile Devices

Unless someone provides a good reason why that is so, I have to assume that this is a bug.

Hi all,

my OPNsense is not assigned an IPv6 address on the WAN interface after starting, but is only assigned after 10 minutes.

As configuration type I use PPPoE for IPv4 and SLAAC for IPv6.

A packet dump is showing that the OPNsense and the provider successfully exchange and acknowledge their interfaces identifiers via PPP IPV6CP. After about 5 seconds, the provider sends a Router Advertisement with information on DNS servers and IPv6 prefix via ICMPv6 . However, OPNsense does not respond to this Router Advertisement.

Another Router Advertisement from my provider 15 seconds later is once again ignored by OPNsense. Hence, I won't get assigned an IPv6 address on the WAN interface.

There seems to be a race condition as OPNsense is not reacting on Router Advertisements during startup process.

To get an IPv6 address assigned on my WAN interfance, I'll have to wait 10 minutes till my provider sends a new Router Advertisement. This Router Advertisement is now being answered by OPNsense with a Neighbor Solicitation message.

Furthermore, there is an issue with DynDNS. I've noticed that the update script is called during the startup process, however at this point in time there is no IPv6 address on the WAN interface. If the IPv6 address is then assigned later (after 10 minutes), the script does not appear to be called any more.

Does anyone have an idea how to solve these issues.

Regards
glasi

Hi all,

renaming of firewall aliases corrupts existing NAT rules.

While existing firewall rules are being updated correctly, NAT rules won't. The destination address for NAT rules will incorrectly change to Single host or Network instead.

Hence, NAT rules won't work anylonger.

Maybe someone from the DEV team can look into this issue.

Thx and regards,
glasi

[65-68 MB/s]

Hi all,

I am using OPNsense in router-on-a-stick VLAN configuration and experiencing performance issues when routing SMB traffic between different VLANs.

The technical setup looks as follows:

Code Select Expand

                             LACP                                                 
+----------------------+     Trunk         +----------------------+               
| OPNsense 20.7.3      |     VLAN          | Cisco SG250-18       |               
| Intel Atom C3558     |-------------------| Switch               |               
| 8 GB RAM             |     2x 1 Gb/s     |                      |               
+----------------------+                   +----------------------+               
                                                 /          \                     
                                                /            \                   
                                        1 Gb/s /              \ 1 Gb/s           
                                              /                \                 
                                             /                  \                 
                            +----------------------+      +----------------------+
                            | File server          |      | Client               |
                            | VLAN 10              |      | VLAN 70              |
                            |                      |      |                      |
                            +----------------------+      +----------------------+

OPNsense will route all SMB traffic between the two VLANs. Disappointingly, I only get a transfer speed of 65-68 MB/s.

During transfer CPU is idling between 45% and 60%.

Code Select Expand

last pid: 80859;  load averages:  1.12,  0.61,  0.48
48 processes:  1 running, 47 sleeping
CPU:  0.1% user,  0.0% nice, 40.9% system,  0.1% interrupt, 58.9% idle
Mem: 202M Active, 314M Inact, 577M Wired, 175M Buf, 6758M Free
Swap: 8192M Total, 8192M Free


Interestingly, OPNsense is able to route at a speed of 112 MB/s between the two VLANs when performing speed tests via iPerf3.

Furthermore, I achieve full speed (112 MB/s) for my SMB traffic when the file server and the client are member of the same VLAN and traffic does not need to get routed by OPNsense.

Disabling interface scrubbing slightly improves the situation (approx. +8 MB/s). However, then my VoIP does not work anylonger.

For the sake of clarity, I do not use IDS/IPS.

Any ideas how to improve SMB traffic routing?

[Squid does not present any error message to the user.]

Hi all,

my Squid proxy does not show any error messages since I upgraded OPNsense to 20.1 production series.

In the Squid logs I can see that Squid blocks certain requests as expected...

Code Select Expand

2020-02-17T18:14:58.530000 1 192.168.xx.xxx TCP_DENIED/403 3968 CONNECT www.hidemyass.com:443 - HIER_NONE/- text/html

.. however, Squid does not present any error message to the user.

This was working perfectly fine in OPNsense 19.7.

Any ideas?

[non-transparent]

Hi all

I'm running OPNsense 19.1.6-amd64 with Squid 3.5.28_1 with two different subnets (LAN and OPT1).

I've put in rules on my OPNsense firewall to block traffic between the different subnets.

The problem I'm running into is that Squid as a proxy (non-transparent) is allowing traffic between the subnets skipping the firewall rules. Hence, clients in OPT1 subnet are able to access the LAN subnet and vice versa.

I miss a similar option as in pfsense's Squid to not forward traffic to Private Address Space (RFC 1918) destinations. If enabled, destinations in Private Address Space (RFC 1918) would be passed directly through the firewall, not through the proxy server.

Is there a way to configure Squid in OPNsense in a similar way? In case I manually have to include custom options in Squid, can anyone provide an example, please?

Nevertheless, how about implementing the option "Do not forward traffic to Private Address Space (RFC 1918) destinations" in OPNsense?

Hi all!

I am currently running OPNsense 19.1.6-amd64 and today I've experienced some hiccups within the firewall module.

The system assigned incorrect rule labels to the logged packets in the firewall live view. E. g.: Logged packets have been flagged with labels anti-lockout rule or allow access to DHCP server on the pppoe interface while no such rules have been set up on the pppoe interface in the firewall module.

After restart of the packet filter the issue was gone.

As far as I can tell firewall rules nonetheless have been applied correctly. I hope this is just a buggy firewall live view.

Please let me know which internal log files to keep track of if the same problem reoccurs.

Hi all,

I am experiencing some issues with IDS/IPS on OPNsense 18.1.8.

As I am new to IDS/IPS I am currently just using OPNsense/test rules as a very basic setup. In a first step I just have enabled the IDS functionality. The test rules work pretty fine.  E.g. access to the EICAR testfile will generate an alert and will be logged by OPNSense.

As soon as I enable IPS the problems are arising. Once again, I will access the EICAR test file. But now NEITHER an alert is being generated NOR the access to the file is being blocked.

Once I have disabled IPS again, logging works again like expected.

Am I missing something? Or is there a bug in the IPS module?

Is someone having the same issue?

Hello,

I have some issues with cloning my IPSec VPN Tunnel Settings.

Currently, I am using two different phase 1 entries. Cloning of the 2nd phase 1 entry works pretty fine. While during the cloning process of the 2nd phase 1 entry OPNSense offers the option to clone related phase 2 entries as well, this option is completely missing when I want to clone the 1st phase 1 entry.

A short review of the website's html source code shows that eight lines of html code are missing (relating to cloning of phase 2 entries) when I want to clone my 1st phase 1 entry.

Any ideas what is causing this behaviour? Can anyone point me in the right direction, please?

I am currently running OPNsense 18.1.6-amd64, FreeBSD 11.1-RELEASE-p9. But I already have this issue since I have started my OPNSense setup with version 18.1.