Messages

for me it is not related to ntpd.

it is the same behaivor again as descripted here:
https://github.com/opnsense/core/issues/5788

- Create an alias with only one network in it
- reboot
- pfctl -t $ALIAS_NAME -T show - returns nothing

root@MGMT-FW02:~ # configctl template reload OPNsense/Filter
OK

... but alias still empty

Hi franco,

Applying aliases doesn't fix the issue.
i did run "/usr/local/opnsense/scripts/filter/update_tables.py" which returned {"status": "ok"} - but alias is still empty
here are some screenshots:

Alias defined as:


not showing up under Firewall -> Diagnostics -> Aliases:


Thanks,
BR

Edit: Strange thing is that other aliases with networks working well, also wenn i create a Internal_LAN2 with the same Subnet it is working perfectly...

and if you look at Firewall -> Diagnostics -> Aliases... are your aliases empty as well?

Are you using network-Aliases in the corresponding Firewall-Rule?

For me 23.1.5 seems to have issues with network-aliases again.

When i look at Firewall -> Diagnostics -> Aliases some of me network-aliases are empty. (maybe something like this issue? https://github.com/opnsense/core/issues/5788)

Have you reported this as a bug on GitHub? If not please do - sounds like a bug and that will get resolved earlier if a GitHub report is made.

issue on github already reported:
https://github.com/opnsense/core/issues/5788

Seems to be some kind of bug.
Under Firewall->Diagnostics->Aliases some aliases doesn't show results(see attached screenshots)

I've seen a similar behaivor. After upgrading to 22.1.8 some rules stopped working...
Had no time to troubleshoot this further and revented back to 22.1.7.

Will try to reproduce it later and report here.

Hey Guys,

I want to report some strange behavior which I've seen on different OPNSense-Boxes in the past weeks/month:

Sometimes IPSec-tunnels just simply get stuck somehow....
"stuck" means: tunnel is still established but no packets flow through the IPSec-interface. I still see ESP-packets on the WAN-interface of the partner-box, but nothing is visible in the IPSec-interface. Absolutley nothing in the IPSec-Log.

Currently I'm troubleshooting an IPSec-tunnel between two OPNSense-boxes(both 20.7.4, one physical one virtual):
Tunnel goes up normally without any errormessages in the logs.
Now the strangest thing in this issue: As soon as i start to copy a file(approx. 100MB) from SiteA to SiteB via SMB the tunnel get "stuck". The only solution is to restart the tunnel.

Some other services like RPC aren't working as well without setting MSS to something lower then 1360.

I tried everything came to my mind:
- changed tunnel from policy-based to route-based
- changed MTU/MSS on all involved interfaces - higher<->lower, doesn't make any difference
- tried to fix via normalization-rules
- changed from IKEv1 to v2, completley recreated the tunnels
- setup a completley new virtual opnsense
- ....

I'm out of ideas at the moment...

it must be related to packet-sizes/fragmentation, but i can't find a solution... and i absolutly have no explaination for a tunnel breaking down due to SMB-copy....
at the moment it is working fine with an OpenVPN-S2S-Tunnel, but i really want to find a fix for this IPSec-issues.

I'm working with OPNSense about 3 years now, managing dozends of boxes with dozends of tunnels. There were problems with IPSec since the beginning of my OPNSense-journey :)(mostly packet-size related). Some tunnels just work, others don't do. I couldn't figure out the differences. Many times it was just fixed by lowering the MTU to 1450. (especially with PPPoE involved - anyone can explain why?)

Last week I had a similar-problem with a few tunnels on anther 20.7.4 box. Everytime i restarted the IPSec-service 1-3 ICMP-Pings got trough the tunnel. Then "stuck" as described  above.
Could be the same root-cause, but i didn't troubleshooting that in deep, as i fixed this via a second opnsense, which manages the IPSec-Tunnels now.

Over the last month, especially since 20.1, I think the MTU-problems over IPSec are more freqently.

If anyone has an idea how to troubleshoot this further, please share your thoughts/experieneces.

Thanks in advance!

problem was caused by vmware promiscuous mode  ::)

it is solved now

my idea is now that it has something to do with vmware promiscuous mode...

but why did the behaivor change from 20.1.9 to 20.7(nothing was changed on the VMWare-side)?

Hey Guys,

I've discovered a strange routing-behaivor since the upgrade to 20.7.
To illustrate i've drawn this nice schema  ;) Its kind of complex setup... hopefully I can clarify.



Some OPNSense-Firewalls(running in VMWare, vNICs in differnt VMNetworks(VLANs)) are connected to a transport-net which is used for routing between LANs. Every OPNSense does have its own LAN-network(differnt VLANs as well). Not every firewall knows each LAN-Route.


Routing-tables look like this(static):

OPNSense1:
default via internet-gw
LAN2 via transport.2
LANn via transport.n
and so on....

OPNSense2:
default via internet-gw
LANn via transport.n
and so on....

since the upgrade to 20.7 I've seen excessive traffic (20-40MBit where there was less then 1MBit pre 20.7) on some of these firewalls that doesn't even belong to the firewall. Packets should not get there as there is no route defined.
wrong(misdirected) traffic does appear on the WAN-interface as well as the transport-interface.

traceroute (wrong - public IPs shouldn't appear here)

Code Select Expand


  1    <1 ms    <1 ms    <1 ms  fw01 [LAN1.1]
  2    <1 ms    <1 ms    <1 ms  transport.9
  3    <1 ms     2 ms    <1 ms  internet.87
  4    <1 ms    <1 ms    <1 ms  internet.19
  5     2 ms     3 ms     3 ms  internet.87
  6    <1 ms    <1 ms    <1 ms  internet.87
  7    <1 ms    <1 ms    <1 ms  internet.87
  8    <1 ms     1 ms     1 ms  internet.19
  9     2 ms    <1 ms     1 ms  internet.19
10     1 ms     1 ms     1 ms  internet.87
11     1 ms     3 ms     3 ms  internet.87
12     1 ms     1 ms     1 ms  internet.19
13     1 ms     1 ms     1 ms  internet.87
14     1 ms     2 ms     1 ms  LANn.2


traceroute should look like

Code Select Expand


traceroute:
  1    <1 ms    <1 ms    <1 ms  fw01 [LAN1.1]
  2    <1 ms    <1 ms    <1 ms  transport.28
  3     1 ms     2 ms     1 ms  LANn.2


traceroutes aren't even consistent, changing every time I test...

tcpdump

Code Select Expand


14:03:44.525830 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.525871 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.525900 IP transport.23 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.525927 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526040 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526096 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526206 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526222 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526237 IP transport.23 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526254 IP transport.23 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526264 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526280 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526342 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100


and it is not only ICMP, every protocol appears in tcpdump on wrong firewalls(TCP,UDP,ESP,...)


funny thing about the scenario: everything is working fine currently except the higher bandwith  ???

I'm out of ideas here...
was there a basic routing-change in FreeBSD 12.1 somehow?!

Anyone does have a clue how to troubleshoot this?

thanks in advance!